20
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 542916
Url: https://administrator.de/contentid/542916
Printed on: April 20, 2024 at 02:04 o'clock
20 Comments
Latest comment
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 !)
Die PFSense war bisher auch als VPN Server einerichtet, das heisst die Inbound Regeln sind da. Ich habe jetzt den VPN Server deaktiviert, leider bleibt das ausgehende VPN davon unbeeindruckt. Die PFSense hängt an einem reinen Modem, ohne Router Kaskade
Deaktivieren nützt nichts, du musst es vollständig entfernen und danach zwingend die States löschen oder die FW rebooten.
Hast du wenigstens mal ins Firewall Log gesehen WAS denn vom L2TP Protokoll in den Regeln hängen bleibt ? Die FW loggt das doch alles mit !
Hast du wenigstens mal ins Firewall Log gesehen WAS denn vom L2TP Protokoll in den Regeln hängen bleibt ? Die FW loggt das doch alles mit !
Die VPN Tunnel sind gelöscht und die Firewall neu gestartet.
Im Log der Firewall scheinen ausgehend je ein UDP Eintrag auf Port 500 und 4500 auf der durchgeleitet wird.
Eingehend sind keine Einträge von der IP des entfernten Netzwerks vorhanden.
Im Log der Firewall scheinen ausgehend je ein UDP Eintrag auf Port 500 und 4500 auf der durchgeleitet wird.
Eingehend sind keine Einträge von der IP des entfernten Netzwerks vorhanden.
Hallo,
Ist da irgendwo ein NAT aktiv? Oder zwei?
Grüße
lcer
Ist da irgendwo ein NAT aktiv? Oder zwei?
Grüße
lcer
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.
1
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...
1
Unter den VPN Settings sind unter IPsec alle tunnels gelöscht und die PFSense neu gestartet.
NAT outbound steht auf automatisch
Eingehde Regeln sind
- IPV4 UDP / * / * / WAN Address / 4500 / * / nicht gesetzt
- IPV4 UDP / * / * / WAN Address / 500 / * / nicht gesetzt
- IPV4 ESP / * / * / WAN Address / * / * / nicht gesetzt
Im Log der Firewall scheinen ausgehend je ein UDP Eintrag auf Port 500 und 4500 auf, der durchgeleitet wird.
Eingehend sind keine Einträge von der IP des entfernten Netzwerks vorhanden.
NAT outbound steht auf automatisch
Eingehde Regeln sind
- IPV4 UDP / * / * / WAN Address / 4500 / * / nicht gesetzt
- IPV4 UDP / * / * / WAN Address / 500 / * / nicht gesetzt
- IPV4 ESP / * / * / WAN Address / * / * / nicht gesetzt
Im Log der Firewall scheinen ausgehend je ein UDP Eintrag auf Port 500 und 4500 auf, der durchgeleitet wird.
Eingehend sind keine Einträge von der IP des entfernten Netzwerks vorhanden.
Hallo,
blöde Frage vielleicht, aber stimmt Dein Routing? Poste mal die Interface-Adressen von pfsense, Internetrouter und den VPN-Server/Client sowie die Standardgateways. Insbesondere wäre es interessant zu wissen, ob die pfsense das Standardgateway ist.
Grüße
lcer
blöde Frage vielleicht, aber stimmt Dein Routing? Poste mal die Interface-Adressen von pfsense, Internetrouter und den VPN-Server/Client sowie die Standardgateways. Insbesondere wäre es interessant zu wissen, ob die pfsense das Standardgateway ist.
Grüße
lcer
Die PFSense hängt direkt am Modem (Bridge Mode) und stellt die Routerfunktion. Der Rechner auf dem der VPN Client läuft, bezieht seine Konfiguration von der PFSense. Standard Gateway ist der WAN Port der PFSense. Soweit so einfach.
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.
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:*
Am LAN Port ist eine Scheunentor Regel
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:*
Am LAN Port ist eine Scheunentor Regel
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
Das sind die Fehlermeldungen aus dem ShrewSoft Log.
??? Bahnhof, Ägypten ???
Da ist nix mit Fehlermeldung !! Wo sind die ??
Wenn du was postest dann das Shrew Log vorher löschen...und erst dann eine Verbindung neu initiieren. Nicht das noch alte Meldungen uns dann hier verwirren !
Da ist nix mit Fehlermeldung !! Wo sind die ??
Wenn du was postest dann das Shrew Log vorher löschen...und erst dann eine Verbindung neu initiieren. Nicht das noch alte Meldungen uns dann hier verwirren !
20/02/06 17:25:41 ## : IKE Daemon, ver 2.2.2
20/02/06 17:25:41 ## : Copyright 2013 Shrew Soft Inc.
20/02/06 17:25:41 ## : This product linked OpenSSL 1.0.1c 10 May 2012
20/02/06 17:25:59 !! : config packet ignored ( config already mature )
20/02/06 17:26:06 !! : config packet ignored ( config already mature )
20/02/06 17:26:15 !! : config packet ignored ( config already mature )
20/02/06 17:26:23 !! : failed to remove IPSEC policy route for ANY:192.168.0.0/24:*
20/02/06 17:25:41 ## : Copyright 2013 Shrew Soft Inc.
20/02/06 17:25:41 ## : This product linked OpenSSL 1.0.1c 10 May 2012
20/02/06 17:25:59 !! : config packet ignored ( config already mature )
20/02/06 17:26:06 !! : config packet ignored ( config already mature )
20/02/06 17:26:15 !! : config packet ignored ( config already mature )
20/02/06 17:26:23 !! : failed to remove IPSEC policy route for ANY:192.168.0.0/24:*
Ich wollte noch eine abschliessende Rückmeldung zu dieser Frage liefern. Das VPN funktioniert wieder.
In der PFSense sind folgende Regeln aktiv:
Inbound ist alles zu.
Outbound sind 4500 und 500 freigegeben.
Ausschlaggebend war eine fehlerhafte Konfiguration des Shrewsoft Clients (Phase 2). Der Tunnel wurde zwar korrekt aufgebaut aber es war kein Traffic möglich.
Vielen Dank für eure Beteiligung an der Fehlersuche.
In der PFSense sind folgende Regeln aktiv:
Inbound ist alles zu.
Outbound sind 4500 und 500 freigegeben.
Ausschlaggebend war eine fehlerhafte Konfiguration des Shrewsoft Clients (Phase 2). Der Tunnel wurde zwar korrekt aufgebaut aber es war kein Traffic möglich.
Vielen Dank für eure Beteiligung an der Fehlersuche.
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
How can I mark a post as solved?
nicht vergessen !
