Pfsense IPsec VPN - Windows 11 Verbindungsabbruch
Habe die Anleitung von aqui genutzt (IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten), um externe Kollegen via Windows onboard IPsec > Internet > PFsese mit dem Netzwerk zu verbinden.
Alles klappt auch wunderbar. Aber nach ein paar Stunden funktioniert dann plötzlich ohne Fehlermeldung der VPN nicht mehr und die Kommunikation durch das VPN ist dann nicht mehr möglich. Ich leite den gesamten Netzwerkverkehr über den VPN um. Daher fällt es sofort auf, wenn plötzlich zb. Zoom abbricht.
Nach dem Trennen und Neuverbinden des VPN geht es wieder?
Habe da gleiche Verhalten auch bei einem anderen Windows 10 Gerät?
Haben Sie eine Idee, wo hier der Fehler sein könnte?
PfSense 2.5.2 (AMD64)
Kann es an den Lifetime Einstellungen liegen?:
- IPsec Tunnel Phase 1: (siehe Bild Phase1)
- Phase 2: (siehe Bild Phase 2
- DPD ist auch aktiviert
Lieben Dank für die Hilfe
Alles klappt auch wunderbar. Aber nach ein paar Stunden funktioniert dann plötzlich ohne Fehlermeldung der VPN nicht mehr und die Kommunikation durch das VPN ist dann nicht mehr möglich. Ich leite den gesamten Netzwerkverkehr über den VPN um. Daher fällt es sofort auf, wenn plötzlich zb. Zoom abbricht.
Nach dem Trennen und Neuverbinden des VPN geht es wieder?
Habe da gleiche Verhalten auch bei einem anderen Windows 10 Gerät?
Haben Sie eine Idee, wo hier der Fehler sein könnte?
PfSense 2.5.2 (AMD64)
Kann es an den Lifetime Einstellungen liegen?:
- IPsec Tunnel Phase 1: (siehe Bild Phase1)
- Phase 2: (siehe Bild Phase 2
- DPD ist auch aktiviert
Lieben Dank für die Hilfe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1544195630
Url: https://administrator.de/contentid/1544195630
Ausgedruckt am: 23.11.2024 um 16:11 Uhr
18 Kommentare
Neuester Kommentar
nur das Routing geht nicht mehr.
Wie hast du das gesehen ?? route print ??Also Inet geht dann nicht mehr
Mmmhhh kann nicht sein wenn du mit Split Tunneling arbeitest ! Internet wird dann lokal geroutet und nur relevanter Traffic geht in den VPN Tunnel.Oder arbeitest du mit einem Gateway Redirect Setup also alles in den Tunnel. Leider fehlen diese Infos oben.
Die evtx Dateien kann man nicht lesen..
Nur das dann der Client keine Verbindung mehr zum Internet (lokalen) hatte.
Dann machst du auch kein Split Tunneling !!Logisch, denn dann geht nur der Traffic der relevant ist (remote Netze) in den Tunnel nicht aber der lokale Internet Traffic.
Vermutlich hast du da dann einen VPN Konfig Fehler gemacht. Der tiefere Sinn von Split Tunneling ist ja gerade das man effizient lokalen Internet Traffic lokal abfackelt und nur das in den Tunnel schickt was man auf VPN Seite erreichen will.
Wie gesagt zu 98% Konfig Fehler...vermutlich DNS hast du das mal geprüft ??
Wenn du nackte Internet IPs wie z.B. 8.8.8.8 bei Split Tunneling pingen kannst rennt das aber dein DNS ist dann falsch konfiguriert wenn ein Ping an Hostnamen scheitert.
route print und nslookup sind hier dann deine besten Freunde.
Uuuhhh ein Nord VPN Opfer..
Da sollte man sehr vorsichtig sein. Besonders wenn man deren Clients nutzt. Sie auch hier.
Selbst die ct' rät in ihrem letzten Test von öffentlichen VPN Anbietern ab. Aus guten Gründen...
Ein Test mit Win 10 (21H1) in einer Standard Installation ohne fremde, exteren VPN Clients verlief hier mit einem nächtlichen Dauerping (ca. 9 Stunden) völlig fehlerlos sowohl in einer Gateway Redirect Konfig als auch in einer Split Tunneling Konfig.
Und das sowohl auf einer pfSense 2.5.2 als auch auf einer latest OPNsense mit identischer VPN Konfig.
Parallel Quercheck mit einem MacBook Pro (Big Sur) Und Raspberry Pi (Strongswan) zeigte in der Zeit auch keinen Ping Ausfall.
Mit anderen Worten: Dein Verhalten lässt sich zumindestens mit der o.a. Windows Version nicht reproduzieren. Möglich das das also duch irgendwie eine Wechselwirkung mit anderer SW ist.
Hast du ggf. einen zweiten Rechner oder Smartphone usw. mit dem du das checken kannst ?
Da sollte man sehr vorsichtig sein. Besonders wenn man deren Clients nutzt. Sie auch hier.
Selbst die ct' rät in ihrem letzten Test von öffentlichen VPN Anbietern ab. Aus guten Gründen...
Ein Test mit Win 10 (21H1) in einer Standard Installation ohne fremde, exteren VPN Clients verlief hier mit einem nächtlichen Dauerping (ca. 9 Stunden) völlig fehlerlos sowohl in einer Gateway Redirect Konfig als auch in einer Split Tunneling Konfig.
Und das sowohl auf einer pfSense 2.5.2 als auch auf einer latest OPNsense mit identischer VPN Konfig.
Parallel Quercheck mit einem MacBook Pro (Big Sur) Und Raspberry Pi (Strongswan) zeigte in der Zeit auch keinen Ping Ausfall.
Mit anderen Worten: Dein Verhalten lässt sich zumindestens mit der o.a. Windows Version nicht reproduzieren. Möglich das das also duch irgendwie eine Wechselwirkung mit anderer SW ist.
Hast du ggf. einen zweiten Rechner oder Smartphone usw. mit dem du das checken kannst ?
Weiß schon langsam nicht mehr, was ich noch versuchen soll.
Kannst du das mal mit anderem OS wie Ubuntu Live System oder Smartphones iPhone oder Android testen ?Nur um sicherzugehen obs an deiner spezifischen Windows Installation liegt oder nicht.
Wie gesagt hier auf einem 10er (21H1), Mac und iPhone nicht zu reproduzieren.
Dort muss ich dann nur einen statische Windows Route eintragen
Nein, das ist Unsinn und sollte man auch nie machen. Die Route sollte IMMER besser auf den Router, denn routen sollen Router und keine Endgeräte !Guckst du auch hier:
Merkzettel: VPN Installation mit OpenVPN
Das erklärt dir auch die großen Sicherheitsprobleme bei internen VPN Servern. VPNs gehören bekanntlich immer aus guten Gründen in die Peripherie !
Vermutlich vergleichst du nun auch Äpfel mit Birnen, denn die Synology wird mit an Sicherheit grenzender Wahrscheinlichkeit keine native IPsec VPNs mit IKEv2 supporten.
Sehr wahrscheinlich ist das ein VPN auf Basis von L2TP, richtig ?! Also Äpfel mit Birnen...
Aber L2TP bekommst du auch problemlos und erheblich sicherer mit der pfSense hin. Guckst du hier:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Auch da:
KEIN Timeout bei einer L2TP Client Session !