VPN Client hinter PFSense, Verbindung nicht möglich
Hallo,
ich habe ein Problem mit meinem VPN Client L2TP/IPsec (Shrew Soft/Windows 10) hinter einer PF Sense Firewall.
- Ohne PFSense funktioniert der Verbindungsaufbau.
- mit PF Sense funktioniert der Aufbau des Tunnesl aber es ist kein Datentransfer möglich. Ping läuft ins Leere. Verbindung bricht ab.
- Die Einstellung der Firewall sind ausgehend:
IPV4* / LAN Net / * / * / * / * / nicht gesetzt
IPV6* / LAN Net / * / * / * / * / nicht gesetzt
NAT ausgehend ist auf automatisch
Hat jemand eine Idee?
Viele Grüsse
Stephan
ich habe ein Problem mit meinem VPN Client L2TP/IPsec (Shrew Soft/Windows 10) hinter einer PF Sense Firewall.
- Ohne PFSense funktioniert der Verbindungsaufbau.
- mit PF Sense funktioniert der Aufbau des Tunnesl aber es ist kein Datentransfer möglich. Ping läuft ins Leere. Verbindung bricht ab.
- Die Einstellung der Firewall sind ausgehend:
IPV4* / LAN Net / * / * / * / * / nicht gesetzt
IPV6* / LAN Net / * / * / * / * / nicht gesetzt
NAT ausgehend ist auf automatisch
Hat jemand eine Idee?
Viele Grüsse
Stephan
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 542916
Url: https://administrator.de/forum/vpn-client-hinter-pfsense-verbindung-nicht-moeglich-542916.html
Ausgedruckt am: 17.04.2025 um 17:04 Uhr
20 Kommentare
Neuester Kommentar
Das ist auch klar, denn vermutlich hast du keinerlei Inbound Regeln am WAN Port der Firewall dafür definiert ?!
Die ausgehenden Regeln sind dafür nicht relevant. Außerdem hast du da ja eh nur "Scheunentor" Regeln definiert.
Inbound am WAN solltest du zumindest das ESP Protokoll (IP Nummer 60) und NAT Traversal (UDP 4500) auf die WAN IP der Firewall erlauben. Das sollte das Problem schon sofort lösen.
Die pfSense darf dabei dann natürlich nicht selber VPN Server sein für IPsec und L2TP da sie diese Ports sonst nicht forwardet.
Rennt die pfSense direkt am Internet mit einem reinen Modem oder in einer Router Kaskade ?
In einer Kaskade musst du ggf. auch Port Forwarding im Router davor beachten.
Infos zu Kaskaden Setups findest du, wie immer hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
(Kapitel: Firewall hinter NAT Router !)
Die ausgehenden Regeln sind dafür nicht relevant. Außerdem hast du da ja eh nur "Scheunentor" Regeln definiert.
Inbound am WAN solltest du zumindest das ESP Protokoll (IP Nummer 60) und NAT Traversal (UDP 4500) auf die WAN IP der Firewall erlauben. Das sollte das Problem schon sofort lösen.
Die pfSense darf dabei dann natürlich nicht selber VPN Server sein für IPsec und L2TP da sie diese Ports sonst nicht forwardet.
Rennt die pfSense direkt am Internet mit einem reinen Modem oder in einer Router Kaskade ?
In einer Kaskade musst du ggf. auch Port Forwarding im Router davor beachten.
Infos zu Kaskaden Setups findest du, wie immer hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
(Kapitel: Firewall hinter NAT Router !)
Zitat von @aqui:
Das ist auch klar, denn vermutlich hast du keinerlei Inbound Regeln am WAN Port der Firewall dafür definiert ?!
Das ist auch klar, denn vermutlich hast du keinerlei Inbound Regeln am WAN Port der Firewall dafür definiert ?!
Verständnisfrage:
Wieso benötigt er eingehende Regeln, wenn es doch um die Nutzung eines VPN-Clients geht, der hinter der pfsense liegt? Sollten da nicht die ausgehenden Regeln genügen?
Wenn das Problem noch ungelöst ist: Könnte es vielleicht hiermit zusammen hängen? Source Port Rewriting. Dort steht dann auch, wie man es löst.
However, rewriting the source port breaks some applications which require the source port to remain unmodified. Notably, there are a handful of protocols, including IPsec and some games, which suffer from this limitation.
Wieso benötigt er eingehende Regeln,
Der Client nutzt L2TP mit IPsec und triggert am VPN Server dann den Aufbau eines eines ESP Tunnels den der Server dann initiiert. Die FW "sieht" also zumindestens eine eingehende ESP Session oder wenn NAT dazwischen ist ein NAT Traversal. Da der Verbindungsaufbau vom Server kommt besteht kein Eintrag in der NAT Translation Tabelle und zudem ist ESP verbindungslos so das keine SPI Beziehung besteht.Folglich sollte zumindestens UDP 4500 und ESP eingehend am WAN erlaubt sein.
Normal reicht es vollkommen aus in der Standard default Konfig die L2TP Ports bzw. IPsec ESP Ports am WAN Port auf die WAN IP per Rewgel zu erlauben.
Funktioniert hier jedenfalls mit native IPsec vollkommen fehlerlos.
OK, Danke. Immer wieder klasse, wie Du die Sachen hier erklärst!
Am Rande:
OpenVPN initialisiert die Session offenbar anders. Mein Client läuft da jedenfalls sauber durch die vor ihm liegende pfsense ohne weitere Einstellungen.
Die Hintergründe sind auch hier zu IPSEC (Abschnitt "Probleme mit einer Firewall bei NAT-Traversal") und hier zu OpenVPN (ex. für Site to Site) anschaulich erklärt (Habe ich aber erst nach Deiner Erläuterung gelesen).
Am Rande:
OpenVPN initialisiert die Session offenbar anders. Mein Client läuft da jedenfalls sauber durch die vor ihm liegende pfsense ohne weitere Einstellungen.
Die Hintergründe sind auch hier zu IPSEC (Abschnitt "Probleme mit einer Firewall bei NAT-Traversal") und hier zu OpenVPN (ex. für Site to Site) anschaulich erklärt (Habe ich aber erst nach Deiner Erläuterung gelesen).
OpenVPN initialisiert die Session offenbar anders.
Ja, das ist logisch, denn OVPN ist ein SSL basierendes VPN. Nutzt also im Gegensatz zu IPsec nur einen einzigen Port.L2TP nutzt derer mehrere wie UDP 1701, und dann die IPsec Suite für den eigentlichen Crypto Tunnel. Siehe RFC_3193
https://de.wikipedia.org/wiki/Layer_2_Tunneling_Protocol
Grundsätzlich ist L2TP nicht an IPsec gebunden wird aber heute aus Sicherheitsgründen fast nur noch mit der IPsec Verschlüsselung genutzt.
Im Grunde ist es ein schlechtes VPN Protokoll weil es nur einzelne Tunnel zulässt und rein nur L2 ist. Deshalb wird es fast nicht mehr genutzt.
Native IPsec oder SSL basierende Protokolle sind da erheblich besser da flexibler.
Aber nun ist der TO wieder dran...
Befürchte ich auch. Irgendwas stimmt da generell am Client nicht. Es sieht so aus als ob die lokale Windows Firewall den Client bzw. dessen virtuelles VPN Interface komplett blockt.
Sehr hilfreich wäre hier mal das Log des Shrew Clients !!
Ob dieser überhaupt eingehenden Traffic "sieht" von seinem VPN Server !
Ist am lokalen LAN Port der pfSense eine "Scheuentor" Regel, sprich also alles erlaubt oder filterst du dort ggf. auch nach Protokollen oder Ports ? Auch das könnte ein möglicher Grund sein.
Sehr hilfreich wäre hier mal das Log des Shrew Clients !!
Ob dieser überhaupt eingehenden Traffic "sieht" von seinem VPN Server !
Ist am lokalen LAN Port der pfSense eine "Scheuentor" Regel, sprich also alles erlaubt oder filterst du dort ggf. auch nach Protokollen oder Ports ? Auch das könnte ein möglicher Grund sein.
Zitat von @ss140207:
Die Windows Firewall ist ausgeschaltet
Hier das Log der Fehlermeldungen:
20/02/06 15:40:58 !! : config packet ignored ( config already mature )
20/02/06 15:41:06 !! : config packet ignored ( config already mature )
20/02/06 15:41:14 !! : config packet ignored ( config already mature )
20/02/06 15:41:22 !! : failed to remove IPSEC policy route for ANY:192.168.0.0/24
Die Windows Firewall ist ausgeschaltet
Hier das Log der Fehlermeldungen:
20/02/06 15:40:58 !! : config packet ignored ( config already mature )
20/02/06 15:41:06 !! : config packet ignored ( config already mature )
20/02/06 15:41:14 !! : config packet ignored ( config already mature )
20/02/06 15:41:22 !! : failed to remove IPSEC policy route for ANY:192.168.0.0/24
ist das log der pfsense? In Deinem Szenario dürfte die von ipsec nix wissen! Ist das eigene ipsec der pfsense komplett deaktiviert?
Grüße
lcer
Outbound sind 4500 und 500 freigegeben.
Das ist aber nur die halbe Miete ! IPsec besteht zudem noch aus dem ESP Protokoll (IP Nummer 50). Das ist essentiell, denn der ESP Tunnel transportiert die gesamten Produktivdaten.Nur UDP 500 und 4500 freizugeben reicht also keinesfalls.
So oder so hat man outbound ja am LAN Port meist mit einer Schrotschussregel alles freigegeben. Interface basierte Outbound Regeln supportet die pfSense ja gar nicht !
Ist also etwas verwirrend was du hier wirklich meinst.
Aber wenn der böse Buhmann der Shrew Client war ist die FW ja so oder so außen vor....
Case closed und danke fürs Feedback !
Bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !