9
IPSEC VPN mit pfSense und Lancom - keine verbindung wenn Client offline
Hallo,
ich habe folgendes Phänomen.
Ich habe 2 Standorte nach Anleitung hier im Forum mit IPSEC VPN verbunden. Standort A mit Lancom Business R800+ und Standort B mit einer pfSense hinter so 'nem TPLink ADSL Modemrouter.
Ich sitze am Standort A, am Standort B ist nur ein Client hinter der pfSense. Wenn dieser Client offline geht, dann erreiche ich nach einiger Zeit die pfSense auch nicht mehr. Aus Tracelog vom LANCOM geht nur hervor, dass die Gegenstelle nicht antwortet. Sobald ich einen Mitarbeiter am Standort B bitte, den PC zu starten, damit ich z.B. per Teamviewer nachsehen kann, läuft der Tunnel sofort wieder. Wird der PC ausgeschaltet, bleibt der Tunnel noch eine ganze Zeit bestehen, irgendwann ist der Tunnel wieder weg. Die pfSense ist defintiv an und hängt auch nicht an einer abschaltbaren Steckerleiste oder ähnlichen. Hat jemand eine Idee? Grundsätzlich reicht es mir ja aus, dass der Tunnel steht, sobald der Client online ist, ich versteh es nur nicht, warum das so ist.
Viele Grüße
Danycode
ich habe folgendes Phänomen.
Ich habe 2 Standorte nach Anleitung hier im Forum mit IPSEC VPN verbunden. Standort A mit Lancom Business R800+ und Standort B mit einer pfSense hinter so 'nem TPLink ADSL Modemrouter.
Ich sitze am Standort A, am Standort B ist nur ein Client hinter der pfSense. Wenn dieser Client offline geht, dann erreiche ich nach einiger Zeit die pfSense auch nicht mehr. Aus Tracelog vom LANCOM geht nur hervor, dass die Gegenstelle nicht antwortet. Sobald ich einen Mitarbeiter am Standort B bitte, den PC zu starten, damit ich z.B. per Teamviewer nachsehen kann, läuft der Tunnel sofort wieder. Wird der PC ausgeschaltet, bleibt der Tunnel noch eine ganze Zeit bestehen, irgendwann ist der Tunnel wieder weg. Die pfSense ist defintiv an und hängt auch nicht an einer abschaltbaren Steckerleiste oder ähnlichen. Hat jemand eine Idee? Grundsätzlich reicht es mir ja aus, dass der Tunnel steht, sobald der Client online ist, ich versteh es nur nicht, warum das so ist.
Viele Grüße
Danycode
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: 333411
Url: https://administrator.de/contentid/333411
Printed on: April 26, 2024 at 19:04 o'clock
9 Comments
Latest comment
Hallo,
klingt nach einem Timeout.
Eines der beiden Gateways erkennt, dass seit n Minuten keine Daten übertragen wurden und beendet den Tunnel.
Kann auch der Lancom sein.
Oder (geraten) durch die fehlende Datenübertragung läuft einer der vielen kleinen Schlüssel der Übertragung ab die sonst regelmäßig erneuert werden.
Dadurch wird die Verbindung ungültig.
Viele Grüße
Stefan
klingt nach einem Timeout.
Eines der beiden Gateways erkennt, dass seit n Minuten keine Daten übertragen wurden und beendet den Tunnel.
Kann auch der Lancom sein.
Oder (geraten) durch die fehlende Datenübertragung läuft einer der vielen kleinen Schlüssel der Übertragung ab die sonst regelmäßig erneuert werden.
Dadurch wird die Verbindung ungültig.
Viele Grüße
Stefan
Das ist ein normales Verhalten. Vermutlich hast du auf der LANCOM-Seite die Short Hold-Time nicht auf 0 oder 9999 stehen, wobei 9999 in Verbindung mit bestimmten Gegenstellen Probleme macht. 0 bedeutet, dass der Tunnel unbegrenzt aktiv ist, aber nicht automatisch aufgebaut wird, wenn ein Abbau erfolgt ist, bei 9999 wird der Tunnel dauerhaft aktiv gehalten und bei einem Abbau auch wieder aufgebaut.
Ob pfSense was in der Form hat, kann ich nicht sagen.
Ob pfSense was in der Form hat, kann ich nicht sagen.
Hallo zusammen,
What should I ping for IPsec Keep Alive erklärt eventuell warum sich die pfSense so verhält.
Gruß
Dobby
What should I ping for IPsec Keep Alive erklärt eventuell warum sich die pfSense so verhält.
Gruß
Dobby
Guten Morgen,
erstmal danke für eure Tipps! *Daumenhoch*
@Stefan - Der Tunnel wird aber auch beendet, obwohl Daten übertragen werden, zwar nicht mehr zischen dem mittlerweile offline gegangenen Client am Standort B und dem Netz in Standort A, - aber immerhin ja durch mein Klicken vom Standort A aus, auf der WebGui der pfSense am Standort B. Von daher ist ja traffic vorhanden.
Ich habe die Lifetimes der Phase 1 auf beiden Seiten auf 9999 seconds stehen und die Optionen für automatische reconnects sind auch gesetzt.
Die Lifetime der Phase 2 auf beiden Seiten bei 2000 seconds.
Wenn ich dem Link von Dobby folge, verstehe ich das so, dass meine pfSense eine IP Adresse aus dem lokalen Netz, haben soll, das ist der Fall.
Standort A: LANCOM 192.168.0.250 (192.168.0.0 /24 ist das Netz)
Standort B: TPLink Modem 192.168.178.10 -> pfSense WAN 192.168.178.250 ->pfSense LAN 10.1.1.1 (10.1.1.0 /24 ist das Netz)
Von 192.168.0.0 komme ich auf 10.1.1.0 und umgekehrt.
Übrigens kann ich den WAN Port der pfSense (192.168.178.250) von Standort A aus nicht erreichen, aber das ist auch eine andere Baustelle.
Viele Grüße
Danycode
erstmal danke für eure Tipps! *Daumenhoch*
@Stefan - Der Tunnel wird aber auch beendet, obwohl Daten übertragen werden, zwar nicht mehr zischen dem mittlerweile offline gegangenen Client am Standort B und dem Netz in Standort A, - aber immerhin ja durch mein Klicken vom Standort A aus, auf der WebGui der pfSense am Standort B. Von daher ist ja traffic vorhanden.
Ich habe die Lifetimes der Phase 1 auf beiden Seiten auf 9999 seconds stehen und die Optionen für automatische reconnects sind auch gesetzt.
Die Lifetime der Phase 2 auf beiden Seiten bei 2000 seconds.
Wenn ich dem Link von Dobby folge, verstehe ich das so, dass meine pfSense eine IP Adresse aus dem lokalen Netz, haben soll, das ist der Fall.
Standort A: LANCOM 192.168.0.250 (192.168.0.0 /24 ist das Netz)
Standort B: TPLink Modem 192.168.178.10 -> pfSense WAN 192.168.178.250 ->pfSense LAN 10.1.1.1 (10.1.1.0 /24 ist das Netz)
Von 192.168.0.0 komme ich auf 10.1.1.0 und umgekehrt.
Übrigens kann ich den WAN Port der pfSense (192.168.178.250) von Standort A aus nicht erreichen, aber das ist auch eine andere Baustelle.
Viele Grüße
Danycode
Das passende Tutorial zu dem Thema hast du gelesen ??
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Ein Blick ins Firewall Log sollte Licht ins Dunkel bringen...
Siehe dazu hier:
Kopplung von 2 Routern am DSL Port (Kaskade)
oder
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät (reines Modem, wie auch im Kapitel "VDSL")
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Übrigens kann ich den WAN Port der pfSense (192.168.178.250) von Standort A aus nicht erreichen,
Das ist normal weil du, wie leider so oft hier, zu 98% vergessen hast eine entsprechende Firewall Regel dafür zu erstellen Ein Blick ins Firewall Log sollte Licht ins Dunkel bringen...
Standort B: TPLink Modem 192.168.178.10 -> pfSense WAN
Ist das wirklich ein reines Modem oder verwechselst du hier wieder laienhaft Modem und Router und in Wahrheit ist das eine Routerkaskade ??Siehe dazu hier:
Kopplung von 2 Routern am DSL Port (Kaskade)
oder
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät (reines Modem, wie auch im Kapitel "VDSL")
Übrigens kann ich den WAN Port der pfSense (192.168.178.250) von Standort A aus nicht erreichen,
Das ist normal weil du, wie leider so oft hier, zu 98% vergessen hast eine entsprechende Firewall Regel dafür zu erstellen Ein Blick ins Firewall Log sollte Licht ins Dunkel bringen...
Das Ping Paket verlässt den Standort A laut LANCOM Trace auch auf dem richtigen Weg.
Im Firewall Log der pfSense (Standort B) sehe ich lediglich hin und wieder geblockte ICMP von der Source 192.168.178.10 (TP Link Modem) als Destination ist 224.0.0.1 angegeben.
Das PacketCapture der pfSense, zeigt mir nur die Pakete die durchgelassen wurden, oder?!
Standort B: TPLink Modem 192.168.178.10 -> pfSense WAN
Ist das wirklich ein reines Modem oder verwechselst du hier wieder laienhaft Modem und Router und in Wahrheit ist das eine Routerkaskadewas aus Standort A kommt (feste öffentl. IP) auf dem WAN Interface durch.
Dann sollte auch der Zugriff aufs GUI der pfSense möglich sein wenn du wirklich ALLES von dieser festen IP zulässt.Da hast du aber ganz sicher einen Fehler im Regelwerk, vermutlich in der Reihenfolge (first match wins Regel) die das dann verhindert.
Um das genauer zu checken müsstest du deine Regel mal posten hier als Screenshot. Feste IP natürlich geschwärzt.
Ja, das muss ich noch besser machen
In der Tat !! Das solltest du auf die Dienste (TCP UDP Ports) die von dieser festen IP kommen strikt einschränken.Das Ping Paket verlässt den Standort A laut LANCOM Trace auch auf dem richtigen Weg.
Fraglich was du auf dem virtuellen pfSense VPN Interface für Regeln hast. Die bestimmen was im Tunnel durch die FW darf und was nicht.Hier hast du unter Garantie einen Fehler und / oder ICMP (Ping, Traceroute) vergessen.
von der Source 192.168.178.10 (TP Link Modem)
Also de facto KEIN Modem sehe ich lediglich hin und wieder geblockte ICMP von der Source 192.168.178.10
Das ist normal und nicht schlimm, denn das IP Netz ist irrelevant und kommt gar nicht durch das Regelwerk da wie du zu Recht sagst "Durchlauferhitzer" 
Am VPN Interface müsste sowas wie:
PASS, Source=<ip_lan_netz_lancom>, Destination=<ip_lan_netz_pfSense>
stehen.
Guckst du auch hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Kapitel Überschrift: "Wichtig: Firewall Regeln auf dem VPN Interface die den VPN Zugang erlauben !:" !
Das PacketCapture der pfSense, zeigt mir nur die Pakete die durchgelassen wurden, oder?!
Ja die über ein Interface der pfSense fliessen.Sofern du Endgeräte pingst im lokalen LAN bedenke hier immer die lokale Firewall und ICMP Block per Default bei Windows.
Wenn du von remote pingst, dann pinge immer die lokale LAN IP der Firewall. Und achte darauf das du vom pingenden System die korrekte Absender IP zum Pingen nimmst. Wenn das die des WAN oder eines anderen Interfaces ist was die VPN Kriterien nicht erfüllt geht das auch ins Nirwana.
Was noch wichtig ist: Hast du einen "Peer Keepalive" aktiviert für den Tunnel ??
Das solltest du machen denn der Keepalive hält den VPN Tunnel immer offen und etabliert ihn auch neu sollte die Internet Verbindung mal abbrechen oder zwangsgetrennt werden.
Das solltest du machen denn der Keepalive hält den VPN Tunnel immer offen und etabliert ihn auch neu sollte die Internet Verbindung mal abbrechen oder zwangsgetrennt werden.
Hi,
ja, Enable DPD ist aktiv.
ja, Enable DPD ist aktiv.