Pfsense als VPN Client zu OpenVPN Windows-Server
-
Hallo zusammen,
von meinem (Windows) PC aus kann ich eine OpenVPN Verbindung zu einem Windows Server herstellen.
Hierzu habe ich die entsprechenden Files (ca.cert, client.crt, client.key und client.ovpn) in den config Ordner des OpenVPN-Clients gepackt.
Tunnel kann aufgebaut werden und eine RDP-Verbindung dadurch betrieben werden.Als Router nutze ich eine pfsense und möchte gerne, dass der Router den Tunnel aufbaut.
Hierzu habe ich:- System->Cert.Manager: Mit den Daten aus ca.cert ein neues CA eingefügt.
- System->Cert.Manager: Mit den Daten aus client.cert & client.key ein Certificat eingefügt. (jeweils von –-BEGIN bis END CERTIFICATE-----)
- VPN->Clients: Einen neuen VPN-Client hinzugefügt
Die Statusseite der pfsense zeigt an, der Tunmel ist up (grüner Pfeil nach oben IP: 10.8.0.10)
Eine RDP Verbindug zu 10.8.0.1 kann ich aber nicht aufbauen.Unsicher bin ich vor allem bei den "Cryptographic Settings".
TLS auth. ist deaktiviert.
Peer Cert. Authority und Client Certificate: die oben angelegt wurden
Was ist bei Encryption algorithm zu wählen? Getestet habe ich: None & BF-CBC (128)
Was ist bei Auth digest algorithm zu wählen? Getestet habe ich: None & SHA1 (160)
Hardware Crypto: NoKann der Tunnel aufgebaut werden, wenn falsche Crypto settings ausgewählt sind?
Außerdem habe ich bei Tunnel Settings:
IPv4 Remote Network(s): 10.8.0.0/24 eingetragenUnter Diagnistics->Routes steht für Dest 10.8.0.0/24 und 10.8.0.1/32 Gateway10.8.0.9 und ovpnc2 als Netif
Eigentlich sollten doch alle notwendigen Daten in den o.g. Files (ca.cert, client.crt, client.key und client.ovpn) drin stehen.
Der OpenVPN Software Client bekommt ja auch keine anderen Daten.Würde mich freuen, wenn mir jemand weiterhelfen könnte.
Gruß jeco -
Hallo nochmal,
nach weiteren Versuchen sieht die Situation so aus:
- pfsense zeigt an, dass der Tunnel aufgebaut ist. IP ist 10.8.0.10
- Unter Status -> SystemLogs -> OpenVPN sehe ich keine ernsthaften Probleme bzgl. VPN
- PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.10 10.8.0.9'
- unter Diagnostics -> Ping bekomme ich eine Antwort von 10.8.0.1
- von einem Client PC im LAN der pfsense bekomme ich keine Antwort auf Ping 10.8.0.1
- Der Tunnel scheint auch vom VPN-Server zur pfsense zu funktionieren. Ich kann durch den Tunnel per putty auf die ssh der pfsense zugreifen
Mir scheint als liegt das Problem nicht beim Tunnel selber sondern beim Routing.
Die Routing Einträge die durch die VPN Verbindung angelegt wurden sehen so aus:
10.8.0.1/32 10.8.0.9 UGS 0 1500 ovpnc2
10.8.0.9 link#11 UH 0 1500 ovpnc2
10.8.0.10 link#11 UHS 0 16384 lo0Warum bekommt der Client PC keine Verbindung zum VPN-Server (10.8.0.1)? Kein Ping, nichts!
10.8.0.1/32 finde ich etwaxs seltsam - hinter einer IP (VPN IP vom Server) noch ein /32.
Der Server ist nicht in einem LAN. Er hat nur eine öffentliuche IP-Adresse und eben den TUN-Adapter.Per VPN-Software Client funktioniert die Verbindung (Ping, RDP etc) vom Client PC zum VPN-Server.
Ein bereits vorhandener VPN-Tunnel verbindet die pfsense zu einem Router und dessen LAN dahinter.
Hier funktioniert der Zugriff auf das LAN (192.168.1.x) problemlos.
Gibt es evtl. Probleme, weil noch ein zweiter VPN-Tunnel aktiv ist?Würde mich freuen, wenn jemand helfen könnte.
Gruß jeco -
Kann dein Client die .9 anpingen? Aus der Routing Tabelle liest es sich, als wäre der Server auf net30 Topologie eingestellt, somit wird immer ein /30 Netz pro Verbindung erstellt und dein Server hat die IP deines Clients -1 -> ergo die .9. Die .1 oben ist ja auf die .9 geroutet und nur die .9 wiederum auf link#11 gelistet.
Zudem sehe ich bei deinen Infos kein Remote Netz. In welches Netz auf Serverseite soll der Client denn kommen? Momemtan wird da ja gar nichts hingeroutet.
-
Hi und Danke für die Antwort,
bei der Konfiguration des OpenVPN Servers bin ich zunächst von den Voreinstellungen in der Beispiel server.ovpn ausgegangen.
Dort ist offenbar net30 topologie als default wegen kompaitilität zu alten clients.
Dieses habe ich nun geändert und die Routen auf der pfsense sehen für mich jetzt geläufiger aus.Clients aus dem LAN der pfsense können aber unverändert nicht zum Server (10.8.0.1) pingen
Clients aus dem LAN der pfsense können auf die VPN-IP der pfsense (10.8.0.8 ) pingen.Auf der pfsense sind 2 VPN Tunnel eingerichtet.
1. Tunnel (alt) verbindet zu einem entfernten Router und dem LAN (192.168.1.x) dahinter.
Tunnel 1 funktioniert und das entfernte LAN ist aus dem LAN der pfsense erreichbar.
Zur Info: Die pfsense bekommt keine Antwort auf Ping des entfernten Tunnel-endes (192.168.251.1)2. Tunnel verbindet zu einem Windows-Server im Internet. Dieser hat nur eine öffentliche IP, kein LAN dahinter.
Tunnel 2 funktioniert soweit:- pfsense kann den Server auf der ovpn Adresse (10.8.0.1) anpingen mit source 10.8.0.8
- Ein Client der per ovpn Software einen Tunnel aufbaut, kann die pfsense (10.8.0.8 ) pingen und auch umgekehrt.
(client2client ist im ovpn-server derzeit aktiviert.)
Irgendwo scheint mir, als würde in der pfsense das Routing zwischen LAN und VPN bzw. entferntem LAN bzw. Server fehlen
-
Irgendwo scheint mir, als würde in der pfsense das Routing zwischen LAN und VPN bzw. entferntem LAN bzw. Server fehlen
Warum? Alles was du beschreibst was geht ist korrekt. Was soll denn nun noch gehen? Vielleicht hab ich es übersehen, aber ich lese nirgends was die pfSense, die jetzt an den Windows Server angedockt ist überhaupt tun soll!? Da du kein LAN dort hast -> was willst du mit der Verbindung überhaupt erreichen? Der Server selbst ist ja pingbar laut deiner Aussage, also "Ziel erreicht"?
-
Hallo!
Die pfsense ist Internet-Router für ein LAN.
Die Clients im dem LAN sollen Zugriff auf einen Windows-Root-Server im Internet haben - per Tunnel.
Dazu baut die pfsense einen OpenVPN-Tunnel zu dem Server im Internet auf.
Der Tunnel scheint zu funktioneiren und die pfsense kann den Server durch den Tunnel anpingen und retour.
Die Clients im LAN können den Server im Internet durch den Tunnel NICHT erreichen - das ist das Problem. -
und wie sollen sie ihn erreichen!?
Firewall Regeln geprüft?
Auf Windows Server die eigene Firewall geprüft (die normal auch alles blockt!)?
Logging auf den Regeln angemacht um zu sehen, dass die Pakete überhaupt hingehen? -
Die Client-Anfragen zum Server sollen von der pfsense in den Tunnel geroutet werden - zum Server.
Die pfsense bekommt Antwort vom Server durch den Tunnel.
Die Windows Firewall des Servers sollte demnach passen.
Ob ein Client anfragt oder die pfsense sollte imho für den Server bzw. dessen Firewall keinen Unterschied machen.Das Problem scheint mir in der pfsense zu liegen, dass diese die Anfragen der Clients auf die (VPN) IP Adresse des Servers nicht weiterleitet.
Anders als bei der 2. (für die Clients funktionierende) VPN Verbindung, gibt es hier kein Remote-Network, dass ich in der VPN-Konfig angeben könnte. Es ist nur ein einzelner Rechner der eine WAN IP hat und eben die VPN IP (10.8.0.1) auf dem TUN Adatpter, die von den Clients nicht erreichbar ist.
-
Die Windows Firewall des Servers sollte damnach passen.
Nope, dein Ping von pfSense zu Server läuft lediglich übers Transfernetz, nicht vom LAN deiner pfSense zur IP des Servers. Das ist ein Unterschied.
Ob ein Cleint anfragt oder die pfsense sollte imho für den Server bzw. dessen Firewall keinen Unterschied machen.
Siehe oben. Wenn du beim Ping auf der pfSense nicht explizit das LAN auswählst, geht der Ping vom VPN Interface ab, nicht vom LAN. Anderes Netz und damit für den Windwos Server KEIN lokales Netz. Die Windows Firewall ist da strikt, wenn es kein lokales Netz ist, wird gern gesperrt. Hat schon mehr als einem Kollegen den Nerv geraubt beim Zugriff auf Kisten via VPN.
Das Problem scheint mir in der pfsense zu liegen, dass diese die Anfragen der Clients auf die (VPN) IP Adresse des Servers nicht weiterleitet.
Sagst du oder weißt du? Darum: auf LAN entsprechende Regel mit Ziel Server-IP und Logging an und sehen, ob die Pakete gepasst werden. Geht auch mittels tcpdump auf der pfSense wenn man es genau wissen will. Packet Capture anwerfen und mitloggen lassen.
, die von den Clients nicht erreichbar ist.
a) Windows Firewall
b) Outbound NAT auf der pfSense konfigurieren für Ziel VPN und Ziel IP ServerIP NATten auf die Transfernetz Adresse. Ausprobieren ob es dann geht.
c) Dann lags entweder an a) oder an fehlernder Rückroute -> dass DU keine Route gepusht bekommst heißt nicht, dass der Server sich für deine Verbindung nicht eine holen sollte. Bzw. du ihm deine LAN Route pushen müsstest (iroute perhaps?). Wenn der Windows Server von 192.168.123.0 bspw. Pakete bekommt via VPN aber keine Rückroute dahin hat -> wo soll er es hinschicken? Ergo entweder workaround mit NAT aufs VPN Interface oder Route von Deinem LAN an den Windows Server pushen.Gruß
Grüße
-
dein Ping von pfSense zu Server läuft lediglich übers Transfernetz, nicht vom LAN deiner pfSense zur IP des Servers.
Der Server hat ja sonst keine andere IP :'( … außer die WAN IPWenn du beim Ping auf der pfSense nicht explizit das LAN auswählst, geht der Ping vom VPN Interface ab
Genau, dass ist mir auch aufgefallen - Ping vom LAN Interface ist, als würde ein Client im LAN Pingen: nicht erreichbar.
Mein "RemoteLAN" ist doch sozusagen der TUN Adapter (bzw. dessen IP) des Servers ???Das VPN (TUN Adapter) auf dem Server ist auf "privates Netzwerk" eingestellt und in der Firewall entsprechend berechtigt.
Auch wenn die Firewall auf dem Server komplett deaktivert ist, verhält es sich unverändert.Besonderheit scheint wirklich zu sein, dass der Server in keinem LAN ist sondern alleine und nur eine WAN und die VPN Schnittstelle hat.
Wenn ich von einem PC per openVPN-Software einen Tunnel aufbaue, dann kann dieser problemlos auf den Server (10.8.0.1) zugreifen.
Von daher sehe ich nicht, weshalb das Problem Serverseitig liegen sollte, sondern würde es eher auf der pfsense vermuten - und zwar, dass diese die Daten vom LAN nicht in das Transfernetz routet. -
Hallo nochmal.
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 mit GW 10.8.0.8 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 10.8.0.0/24 ist evtl. nicht ganz korrekt. Diese kommt daher, weil ich in der openvpn-client konfig der pfsense Remote Network(s): 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 - fertigVielleicht gibt es ja doch etwas auffälliges.
-
Die Zeile mit GW 10.8.0.8 ist manuell hinzugefügt per: route add 192.168.2.0 MASK 255.255.255.0 10.8.0.8
Das ist unnötig und sollte raus. Wenn sollte das beim Verbindungsaufbau gesetzt werden, wenn nicht, stimmt was mit der Konfig nicht und erklärt vielleicht dein Problem. :)
Vor allem kannst du nicht selbst irgendwas routen, was dynamisch ist - der Client verbindet sich nicht immer als 10.8.0.8 und dann passt deine Route nicht mehr.Zeile 10.8.0.0/24 ist evtl. nicht ganz korrekt. Diese kommt daher, weil ich in der openvpn-client konfig der pfsense Remote Network(s): 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.Dann ist es kein Wunder dass deine Konfiguration total verbogen ist. Wenn es kein Remote Netz gibt, gibt es keines. Punkt. Es muss auch keines zwangsweise eingetragen sein. Wenn du es dann als Remote UND Tunnelnetz einträgst, kann das natürlich Probleme geben, weil das Routing dann buggy läuft. Bitte sauber einstellen wie es in Doku etc. vorgeschlagen wird.
Grüße
-
Das manuelle Hinzfügen der Route auf demn Server und das Angeben des Remote-LANS in der pfsense ovpn config waren nur versuche.
Natürlich habe ich es zunächste ohne diese versucht.Der Client (die pfsense) bekommt immer die selbe IP (10.8.0.8). Das ist in der ipp.txt angegeben.
Die fpsense ist ja sozusagen ein Roadwarrior und baut die Verbindung ähnlich auf, wie das ein VPN Software Client auf einem PC tut.
Das LAN, in dem sich so ein PC befindet, ist vom Server aus auch nicht zu erreichen.