aubanan
Goto Top

Zugriff vom LAN zu OpenVPN Server

Hallo zusammen,

Im Internet habe ich einen Windows Root-Server, auf den ich von meinen Clients im LAN zugreifen möchte.
Zu diesem Zweck habe ich auf dem Server OpenVPN installiert und konfiguriert.

Der Server ist nicht in einem LAN sondern hat nur eine NIC mit öffentlicher IP und einen TUN Adapter für das VPN.
NIC ist öffentliches Netzwerk und TUN auf privates Netzwerk eingestellt.

Per OpenVPN Software lässt sich mit den konfig Dateien (ca.cert, client.cert, client.key und client.ovpn) ein Tunnel aufbauen.
Der Server ist dann durch den Tunnel über seine VPN IP (10.8.0.1) erreichbar. Ping, RDP ... läuft.

Nun möchte ich den Tunnel auf den Clients nicht immer manuell aufbauen sondern der im LAN befindliche Internet-Router soll das machen.
Hierzu habe ich auf dem Router (pfsense) einen neuen VPN Tunnel eingerichtet und die CA, Cert und Key Daten aus den o.g. Files in die pfsense eingefügt.

Der Tunnel zwischen Server und pfsense steht. Die pfsense kann den Server auf 10.8.0.1 anpingen (von source "open vpn client" aus).
Vom Server lässt sich durch den Tunnel auf die ssh von der pfsense zugreifen. Auch gut.

Aber: die Clients im LAN können den Server nicht erreichen.
Da der Sever in keinem LAN ist, kann ich nur die IP des TUN-Adapters (10.8.0.1) anpingen - keine Antwort.

Fehlt hier in der pfsense noch eine Route oder wo ist das Problem?
Wie gesagt, wenn der Tunnel auf dem Client per OpenVPN Software aufgebaut wird, dann kann der Client den Server unter seiner VPN Adresse erreichen.
Von daher gehe ich eigtl davon aus, dass der Server korrekt konfiguriert ist und das Problem in der pfsense liegt.
Oder?

Ich bin nicht ganz so fit in der Materie aber würde mich freuen, wenn das zum Laufen zu bekommen wäre.

Vielen Dank schonmal
Aubanan

Content-Key: 329388

Url: https://administrator.de/contentid/329388

Ausgedruckt am: 19.03.2024 um 04:03 Uhr

Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.02.2017 aktualisiert um 20:23:04 Uhr
Goto Top
Moin,

baut die PfSense denn eine Verbindung zum OpenVPN Server auf? Würde ja eine Fehlkonfig ausschließen.
Alles andere wäre dann hinfällig, zumindest in den Standardeinstellungen.

Also im Prinzip wird dir der aktive Tunnel angezeigt. Ohne weiteres bekommst das dortige Gateway?
Dann ist es ein Problem beim OpenVPN Server.

Kommt der Server denn bis zum Client (PfSense)?

Gruß Spirit
Mitglied: Aubanan
Aubanan 14.02.2017 aktualisiert um 20:28:18 Uhr
Goto Top
Hi,
ja, die pfsense baut einen Tunnel zum OpenVPN Server auf und ein Ping von der pfsense (von source "open vpn client") auf 10.8.0.1 wird beantwortet.
Andersrum gehen auch Daten durch den Tunnel, wenn ich vom Server (==OpenVPN Server) auf die ssh von der pfsense (10.8.0.8) zugreife.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.02.2017 um 20:30:13 Uhr
Goto Top
Deine PfSense im Client Modes bekommt ne IP vom OpenVPN Server. Kannst du diese aus dem LAN pingen?
Mitglied: Aubanan
Aubanan 14.02.2017 um 20:33:45 Uhr
Goto Top
Ja, die pfsense bekommt (immer die selbe, wegen ipp.txt wimre) die 10.8.0.8 und die ist aus dem LAN anpingbar und antwortet.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.02.2017 aktualisiert um 20:43:32 Uhr
Goto Top
Die Seite beim OpenVPN Server kennt dein Internes LAN nicht. Dort ne Static-Route mit GW auf die Client Adresse bei der PfSense und dann läuft das.

Du machst dazwischen kein NAT. Umgekehrt wäre dies kein Thema da das Routing (gemäß der Server würde durch die FW gestellt) durch die FW laufen würde, und somit würde eben die FW alle Routen kennen. Dein Server tut dies nicht. Somit muss du dies per Hand ergänzen.
Wenn du dies auf Windows Basis betreibst, bekommst du möglicherweise noch Probleme wenn du mit verschiedenen Subnetzen Arbeits.
Dann eben noch Firewall-Regeln am Server erstellen und zulassen.

Achtung: Die IP der Pfsense im OpenVPN Netz darf sich somit nicht ändern!

Anschließen würde ich überprüfen ob nicht doch noch etwas FW Seitig geblockt wird, das ist ja dann nun eine Kleinigkeit.
Und sicher deinen Roote-Server ab!
Mitglied: Aubanan
Aubanan 14.02.2017 um 21:08:39 Uhr
Goto Top
Hi, verstehe ich das recht: auf dem Server eine statische Route eintragen
route add 192.168.2.0 MASK 255.255.255.0 10.8.0.8
          LAN der pfsense                VPN IP der pfsense
Dieses erzeugt dann folgenden Eintrag:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
[...]
192.168.2.0  255.255.255.0 10.8.0.8  10.8.0.1   21
                                     VPN IP des Servers
Es funktioniert öeode rnocjt. Vom LAN-Client antwortet der Server (10.8.0.1) nicht auf Ping. Auch die LAN-IP der pfsense antwortet dem Server nicht.

Eigentlich hätte ich eher erwartet, eine Route auf der pfsense einzufügen
Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.02.2017 aktualisiert um 21:36:13 Uhr
Goto Top
Hast du die FW am Server überprüft?
Wird das 192.168.2.0/24 dort geblockt da es nicht bekannt ist?

Und die 10.8.0.8 ist auch wirklich die IP der PfSense im OpenVPN Netz?
Die PfSense kennt ja schließlich beide Netze.
In der PfSense ist bsp. ne LAN zu Any Rule vorhanden?

Wenn die Route auf 10.8.0.1 (deinen Server) zeigt wird das nix.
Mitglied: the-buccaneer
the-buccaneer 14.02.2017 um 23:16:46 Uhr
Goto Top
Hi!

Wenn der Traffic vom OpenVPNClient der PfSense zu deinem Internetserver flutscht, ist diese funktional eingerichtet.
Der Ping von der Gegenseite belegt das ebenfalls.

Wenn Du von den Clients ein tracert ausführst, wirst du wahrscheinlich sehen, dass der Traffic bei deiner PfSense endet. Richtig?
Auch die PfSense bietet dir da übrigens Diagnosemöglichkeiten unter "Diagnostics"

Damit bleibt als wahrscheinlichste Ursache, dass die PfSense Firewall deinen Traffic auf dem OpenVPN Interface blockiert.
Unter: Firewall --> Rules --> OpenVPN muss eine Regel gesetzt sein, die den Traffic auch erlaubt.
Ist das der Fall? Mache mindestens testweise eine "Scheunentorregel" die von dort alles erlaubt. Wenn es dann geht, kannst du es einschränken.

Die PfSense routet wie andere Router auch automatisch zwischen ihren Interfaces. Die Firewallkomponente blockiert aber sicherheitshalber erstmal alles.

Du kannst dir auch mal die Firewall-Logs ansehen. Da sollte der blockierte Traffic auftauchen.
Natürlich kannst du sicherheitshalber auch mal auf dem Server route -print ausführen. https://technet.microsoft.com/en-us/library/bb490991.aspx
Da muss eine Route zu deinem LAN stehen.

Um das Szenario zu testen musst du auf PfSense Seite natürlich immer das LAN Interface für den Ping wählen. Wenn das durchkommt, gehts auch bei den Clients. (Wenn die die PfSense als Gateway nutzen)

LG
Buc
Mitglied: Aubanan
Aubanan 15.02.2017 um 00:10:25 Uhr
Goto Top
Hallo,
vom Server kann ich die VPN IP der pfsense (10.8.0.8) anpingen. Auch mit aktiver FW auf dem Server.
Vom Server gibt es keine Antwort von der LAN IP der pfsense (192.168.2.240) auch nicht mit deaktivierter FW auf dem Server.

Von der pfsense gibt es Antwort vom VPN Interface auf die VPN IP des Servers (10.8.0.1)
Von der pfsense gibt es keine Antwort vom LAN Interface auf die VPN IP des Servers (10.8.0.1)

In der pfsense gibt es eine FW rule für LAN: allow any to any
In der pfsense gibt es eine FW rule für Interface "OpenVPN": allow any to any

Die pfsense baut noch eine 2. VPN Verbindung zu einem Router auf. Es gibt in der FW aber nur ein "OpenVPN" Interface.
Ist das ok?

In der FW der pfsense sehe beim Ping vom LAN zur VPN IP des Servers keine Meldungen, dass etwas geblockt wird.

In den Logs unter VPN wiederholen sich aber alle paar Sekunden diese Meldungen:
Feb 14 23:40:18 	openvpn 	83222 	MANAGEMENT: Client disconnected
Feb 14 23:40:18 	openvpn 	83222 	MANAGEMENT: CMD 'status 2'  
Feb 14 23:40:18 	openvpn 	83222 	MANAGEMENT: CMD 'state 1'  
Feb 14 23:40:18 	openvpn 	83222 	MANAGEMENT: Client connected from /var/etc/openvpn/client2.sock 
Auf dem Server habe ich nach Hinweis von Spirit eine Route eingetragen s.o.

Mir scheint als ist hier eine Besonderheit, dass die pfsense eine VPN Verbindung nicht zu einem LAN aufbaut sondern zu einem einzelnen Rechner, der als IP nur die IP des VPN Transfernetzes hat. Ich habe schon überlegt ob ich dem Server nicht eine (virtuelle/loopback) LAN Karte "einbauen" kann, damit er eine eigene, private IP hat, die ich der pfsense in der VPN konfig dann als Remote Network mitgeben kann.

Bei dem anderen Tunnel (der funktioniert) wird zu einem LAN getunnelt und dort antwortet auch die VPN IP des entfernten Routers nicht sondern nur die lokalen IPs (192.168.1.x) im LAN
Mitglied: the-buccaneer
the-buccaneer 15.02.2017 um 01:02:39 Uhr
Goto Top
Puh, bin völlig vergrippt mit 4 Bier in der Birne...
Mal sehen...

Mein Problem ist: Ich habe fast Null Erfahrung mit Open VPN. Mache alles mit IPSec, bis auf einen Kunden. Bei dem hakt das aber auch mit Opnen VPN. (Wegen dieser dämlichen Server/Client-Sachen bei OpenVPN, die ein Site2Site erschweren, grundsätzlich lief das aber mal...Ist aber in dem Fall nur ein "Nice-to-have")
Es scheint mir bei dir aber prinzipieller zu sein.

"Von der pfsense gibt es Antwort vom VPN Interface auf die VPN IP des Servers (10.8.0.1)
Von der pfsense gibt es keine Antwort vom LAN Interface auf die VPN IP des Servers (10.8.0.1) "

Wo kann das Problem dann noch liegen?
Setze doch mal eine Rule für ICMP auf dem VPN Interface und testweise auch auf dem LAN Interface. Auch wenn das nicht sein sollte, habe ich mit der PfSense solche Sachen schon gehabt.
Schau dir nochmal in der PfSense OpenVPN Konfiguration das Local Network und das Tunnel Network an...

Die PfSense blockt das aus irgendeinem Grund.

LG
Buc
Mitglied: aqui
aqui 15.02.2017 aktualisiert um 09:19:42 Uhr
Goto Top
Aber: die Clients im LAN können den Server nicht erreichen.
Das liegt vermutlich daran das du die Firewall Regeln auf dem OVPN Adapter nicht oder falsch eingestellt hast.
Das Firewall Log ist hier immer die erste Anlaufstelle !!
Fehlt hier in der pfsense noch eine Route oder wo ist das Problem?
Nein, ganz sicher nicht, denn alle IP Netze sind ja direkt an der pfSense darn. Sie "kennt" also alle IPs.
Es ist vermutlich das Regelset, denn der virtuelle OVPN Adapter hat per Default die Regel ALLES verboten wie es bei FWs ja üblich ist.
Hier musst du also das 10.8.0.0 /24 Segment auf dein lokales LAN Segment öffnen, dann sollte es auch klappen.
Traceroute und Pathping sind hier immer deine Freunde. Da wo es nicht mehr weitergeht liegt auch der Fehler.
verstehe ich das recht: auf dem Server eine statische Route eintragen
Das kann man so machen. Jedenfalls muss der Server ja das lokale LAN kennen und wissen das Traffic dafür in den Tunnel bzw. Tunneladapter geroutet werden muss.
Er kennt ja sonst nur seine öffentliche IP und das OVPN Netz und würe alles was er nicht kennt logischerweise an sein Default Gateway senden. Auch dein lokales LAN wenn eine entsprechende Route fehlt.
Ein route print auf dem Winblows Server zeigt dir immer die aktuelle Routing Tabelle an ! Damit kannst du das überprüfen wenn der VPN Tunnel online ist !

Die Route kannst das aber auch über einen ip route... Befehl in der OVPN Konfig machen. Letztlich besser, denn dann wird die Route automatisch nur injiziert wenn der VPN Tunnel steht. Bei einer Systemroute ist die permanent.
Hier zeigt sich das es kontraproduktiv ist den Win Server als OVPN Server einzurichten. Besser wäre es er würde der Client sein, denn dann könntest du die pfSense als Server laufen lassen und dort mit dem push route... Kommando das lokale LAN IP Netz als Route automatisch an den Client übertragen.
Aber wie gesagt...es geht auch mit dem ip route... Kommando im Openvpn Setup des Servers...beides ist möglich.

Gut möglich auch das die Winblows Firewall der böse Bube ist sollten die FW Regeln der pfSense passen und ide Rozten für das lokale LAN korrekt konfiguriert sein..
Durch die fehlende Netzwerk Profil Erkennung des TUN Adapters bei OVPN unter Winblows deklariert die Win Firewall das Netz als Öffentlich (Public) und macht damit dann alle Schotten zu.
Ab Win 7 u. Server 2008 ist zudem ICMP (Ping) vollständig geblockt:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Hier musst du also auch zwingend Hand anlegen und den Netzwerktyp und Win Firewall mit erweiterten Einstellungen auf Private setzen und ggf. ICMP passieren lassen wenn du pingen willst von Fremdadressen.
Deine Absender IP die beim OVPN Server ankommt ist ja nun keine 10.8.0er Client IP mehr sondern eine deines lokalen LANs. Das Blockt die Win Firewall dann sofort.
Fazit: Vermutlich ein Firewall oder auch Routing Problem. Entweder Regel pfSense oder Winblows Firewall Setup !!
Routen auf dem Win Server checken bei aktivem Tunnel !
Mitglied: Aubanan
Aubanan 15.02.2017 um 17:14:58 Uhr
Goto Top
Hallo und Danke für die Antworten.

was die Windows Server FW angeht würde ich diese ausschließen, da auf Anfragen aus dem LAN bzw. vom LAN Interface der pfsense keine Antwort vom Server (VPN IP) kommt, selbst wenn die Firewall auf dem Windows Server aus ist.

In den FW Regeln der pfsense gibt es:
- für Interface LAN: Source LAN-Net, Port * , Dest * , Port * , GW *
- für Interface OpenVPN: Source * , Port * , Dest * , Port * , GW *

Log auf der OpenVPN Rule ist aktiviert aber ich sehe dazu nichts im Log.

Wenn sich hier jemand finden würde, der sich das anschauen würde - gegen Bezahlung in gewissem Rahmen - wäre ich nicht abgeneigt.
Mir scheint als komme ich nicht weiter.
Mitglied: aqui
aqui 15.02.2017 um 17:32:36 Uhr
Goto Top
Hast du dir mal die Routing Tabelle auf pfSense und Server angesehen ?? Stimmen die für deine IP Netze ?
Wo bleibt ein Traceroute hängen ?

Hast du die OpenVPN Roles (Client und Server) spaßeshalber mal umgedreht ? Wäre ja auch mal einen Test wert.
Ich hab das Setup hier mal im Labor testaufbau auf einen RasPi OVPN Server getestet und das klappt fehlerlos von der pfSense und den Clients dahinter.
Generell ist dein Setup also richtig ! Da ist irgendwo noch was Firewall mässiges dazwischen...
Mitglied: Aubanan
Aubanan 15.02.2017 aktualisiert um 23:21:22 Uhr
Goto Top
Die Routing Tabelle auf dem Server sieht so aus
 
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      xxx.yy.32.1    xxx.yy.33.179    266
         10.8.0.0    255.255.255.0   Auf Verbindung          10.8.0.1    276
         10.8.0.1  255.255.255.255   Auf Verbindung          10.8.0.1    276
       10.8.0.255  255.255.255.255   Auf Verbindung          10.8.0.1    276
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      xxx.yy.32.0    255.255.252.0   Auf Verbindung     xxx.yy.33.179    266
    xxx.yy.33.179  255.255.255.255   Auf Verbindung     xxx.yy.33.179    266
    xxx.yy.35.255  255.255.255.255   Auf Verbindung     xxx.yy.33.179    266
      192.168.2.0    255.255.255.0         10.8.0.8         10.8.0.1     21
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung     xxx.yy.33.179    266
        224.0.0.0        240.0.0.0   Auf Verbindung          10.8.0.1    276
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung     xxx.yy.33.179    266
  255.255.255.255  255.255.255.255   Auf Verbindung          10.8.0.1    276
===========================================================================
Die Zeile 14 ist manuell hinzugefügt per: route add 192.168.2.0 MASK 255.255.255.0 10.8.0.8

Routen auf der pfsense sind diese:
Destination        Gateway            Flags      Netif Expire
default            195.14.226.6       UGS      pppoe0
10.8.0.0/24        10.8.0.8           UGS      ovpnc2
10.8.0.1           link#11            UH       ovpnc2
10.8.0.8           link#11            UHS         lo0
81.173.194.77      195.14.226.6       UGHS     pppoe0
127.0.0.1          link#8             UH          lo0
192.168.1.0/24     192.168.251.1      UGS      ovpnc1
192.168.2.0/24     link#2             U           em1
192.168.2.240      link#2             UHS         lo0
192.168.251.0/24   192.168.251.2      UGS      ovpnc1
192.168.251.1      link#10            UH       ovpnc1
192.168.251.2      link#10            UHS         lo0
194.8.194.60       195.14.226.6       UGHS     pppoe0
195.14.226.6       link#9             UH       pppoe0
xxx.zzz.94.88      link#9             UHS         lo0
Zeile 03 ist evtl. nicht ganz korrekt. Diese kommt daher, weil ich in der openvpn-client konfig der pfsense Remote Network(2): 10.8.0.0/24 eingetragen habe. Wobei das ja eigtl. das Transfernetz ist aber die .1 auch mein Ziel Host ist. Versucht habe ich dort auch 10.8.0.1/31.

Ping aus dem LAN auf 10.8.0.1 bekommt keine Antwort und tracert endet am LAN IF der pfsense (192.168.2.240)
Ping aus dem LAN auf 10.8.0.8 bekommt Antwort und tracert macht einen hop zu 10.8.0.8 - fertig
Mitglied: Spirit-of-Eli
Spirit-of-Eli 15.02.2017 um 23:16:48 Uhr
Goto Top
Sieht doch nach Serverseitigem Problem aus. Du kommst aus dem 192.168.2.0 nicht rüber.

Ich bin immer noch der Meinung, dass dein Server mit dem Netz nix anfangen kann..
Mitglied: Aubanan
Aubanan 15.02.2017 um 23:32:30 Uhr
Goto Top
Wie sollte ich dem Server das 192.168.2er Netz noch bekannt geben, außer die Route wie in Zeile 14 einzufügen?

Wenn das Problem beim Server liegt würde mich zudem wundern, weshalb ein Tracert aus dem LAN zur VPN-IP des Servers nicht mal ins Transfernetz kommt.
Mitglied: Aubanan
Aubanan 17.02.2017 um 00:17:16 Uhr
Goto Top
Hallo nochmal,

irgendwie werde ich das gefühl nichtr los, dass es ungünstig ist, dass der Server nur die WAN IP und die VPN-IP hat, die vom LAN aus durch den Tunnel nicht erreichbar ist.

Von daher kam mir die Frage, ob ich dem Server noch eine Lokale IP (z.B. 192.168.99.1) zuteilen kann.
Dann könnte ich in der pfsense unter OpenVPN-Client das 192.168.99.0/24 als Remote-Netz angeben.

Was haltet ihr davon? Wie ließe sich das bewerkstelligen, dem Server eine private IP zu geben?
Eine MS-Loopback NIC habeich mal hinzugefügt und dieser eine private IP gegeben aber ich wusste nichts bei DNS und GW einzutragen und erreichbar war die IP durch den Tunnel auch nicht.
Mitglied: aqui
aqui 17.02.2017 um 15:00:51 Uhr
Goto Top
irgendwie werde ich das gefühl nichtr los, dass es ungünstig ist, dass der Server nur die WAN IP und die VPN-IP hat, die vom LAN aus durch den Tunnel nicht erreichbar ist.
Nein, das ist vollkommen unbegründet !
Einzig und allein relevant für das VPN (bei Open VPN) ist das interne Tunnel IP Netz. Da spielt es keinerlei Rolle ob die physische IP einen WAN IP oder was auch immer ist. Da musst du dir keine Sorgen machen.
Von daher kam mir die Frage, ob ich dem Server noch eine Lokale IP (z.B. 192.168.99.1) zuteilen kann.
Das dürfte bei einem gehosteten Server ja unmöflich sein. RFC 1918 IPs geht sicher in einem Provider Umfeld gar nicht. Außerdem hast du ja schon eine "Lokale IP" !!
Das ist doch immer die lokale IP des VPN Tunnels. Warum also doppelt moppeln ??
Was haltet ihr davon?
Sinnfrei und bringt nix...
Wie ließe sich das bewerkstelligen, dem Server eine private IP zu geben?
Ganz einfach mit einem Loopback Interface, wenn du es denn unbedingt testen willst. Aber wie gesagt...das ist eigentlich Quatsch !
und erreichbar war die IP durch den Tunnel auch nicht.
Klar, denn du hast mit 99,9%iger Sicherheit vergessen diese Loopback IP bzw. das netzwerk ins OVPN Routing einzutragen !!! Der klassische Fehler !
Die Loopback IP ist einen Hostroute also mit einer 32 Bit Maske 255.255.255.255 muss aber logischerweise wie alle IP Netze auch dem Route Prozess bekannt gemacht werden.
Ein route print auf dem VPN Client sagt dir doch immer ob das Loopback Netz propagiert wird. Wenn du das in der Routing Tabelle nicht siehst wird es logischerweise nicht propagiert (weil du das Routing dafür nicht eingetragen hast !) und damit schlägt dann auch jede Connectivity fehl.
Eigentlich vollkommen logisch wenn man nur mal ein bischen drüber nachdenkt und troubleshootet face-wink
Mitglied: Aubanan
Aubanan 17.02.2017 um 21:36:04 Uhr
Goto Top
Das VPN Netz ist ja nur ein Transfernetz, von daher kam mir der Gedanke, dass es die Sache einfacher machen würde, wenn der Server eine LAN IP hätte. Gehosteter Server - ok - aber kann der nicht rotzdem eine LAN IP zusätzlich bekommen?

Nun gut das Loopback IF hatte ich hinzugefügt und im VPN Client (pfsense) als Remote-Network den IP-Adressbereich des Loopback-Adapters eingetragen. Demnach gehöre ich zu Deinen 0,1 % die das nicht vergessen haben - oder face-wink

VPN Client ist die pfsense, da gibt es imho kein Route Print, aber netstat -rn macht ähnliches und da stand die IP des Loopback Adapters drin ... als 192.168.99.0/24 auch wenn dieses Netzwerk nur ein Mitglied hat: der Loopback-Adapter des Servers.

Da gemäß Deiner Aussage die zusätzliche IP im Server nicht erforderlich ist, weil der Server ja bereits seine VPN-IP (10.8.0.1) hat, lohnt sich hier wohl auch kein troubleshooting für den Loopback, was ja bei meinem Versuch auch nicht geholfen hat.

Vielmehr würde mich interessieren wo das Problem liegt, dass die VPN-IP des Servers aus dem entfernten LAN durch den Tunnel nicht erreichbar ist.

Wenn Sich jemand melden würde und mal persönlich danach gucken, würde ich mich riesig freuen und würde das auch gerne im Rahmen meiner Möglichkeiten entlohnen. Ich hoffe meine Anfrage verstößt nicht gegen die Etikette des Forums,
Mitglied: aqui
aqui 18.02.2017 aktualisiert um 00:07:17 Uhr
Goto Top
Ein Transfernetz ist es nicht. Nicht jedenfalls wenn man mit einem Client zugreift. Bei einem Lan2Lan VPN magst du recht haben.
Du hast zu 100% einen Fehler in deiner server.conf Datei ! Die müsstest du mal posten um das zu troubleshooten.
Dort fehlt ein push route... Kommando.
Dieses Tutorial erklärt die ToDos dazu:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Mitglied: the-buccaneer
the-buccaneer 18.02.2017 um 00:35:09 Uhr
Goto Top
Kannst du mal einen Screenshot deiner OpenVPN Konfiguration auf der PfSense posten?

Mein Eindruck ist auch, dass es an dem etwas ungewöhnlichen Szenario ohne entferntes IP-Netz liegt und daher deine Einstellungen für diesen Fall nicht stimmen.

Beim IPv4 Remote Network sollte z.B. in deinem Fall nichts stehen:

"IPv4 Remote Network/s
These are the IPv4 networks that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here. You may leave this blank to only communicate with other clients. "

Die Hints in der PfSense Konfiguration sind mittlerweile wirklich brauchbar... face-wink

LG
Buc
Mitglied: Aubanan
Aubanan 18.02.2017, aktualisiert am 19.02.2017 um 22:45:07 Uhr
Goto Top
Hallo nochmal,

der Zugriff vom LAN durch den Tunnel zum Server klappt jetzt.

Die Konstellation ist wohl an mehreren Stellen etwas seltsam.
Der OpenVPN Server ist gedacht, dass sich Clients als Roadwarrior mit ihm verbinden und das LAN hinter diesen Clients interessiert den Server i.d.R. nicht.
Die pfsense sieht es garnicht vor, als Roadwarrior eine Verbindung zu einem VPN-Server aufzubauen sondern geht von einer Peer2Peer Verbindung aus.

Das führt vermtulich zu ein paar ungewöhnlichen Phänomenen.
Die vorhandene Route auf der pfsense: für 10.8.0.0/24 auf GW 10.8.0.8 müsste wohl eher GW 10.8.0.1 haben.
Dem Server ist das LAN hinter der pfsense nicht bekannt und es wird beim Tunnelaufbau auch keine Route dorthin gesetzt.

So klappt es jetzt:
Neues Opt. Interface dem Network Port OpenVPN zugewiesen. Das erzeugt unter Routing ein neues Gateway.
In der Firewall einen neuen NAT Outbound Eintrag für das neue OptIF anlegen mit Source 192.168.2.0/24 (LAN IP-Range)