IPSEC findet die neue IP des DDNS nicht
-
Hallo,
ich habe an zwei Standorten pfSense vers. 2.1.3 am laufen. Eine Seite mit einer statischen IP, die Gegenstelle über DDNS. Alles läuft super bis auf der dynamischen Anbindung eine neue IP zugewiesen wird. Wenige Augenblicke später ist der DDNS-Wert entsprechend aktualisiert. Wenn ich auf der statischen Seite ein DNS Lookup auf den DDNS mache, wird der aktuelle Wert korrekt angezeigt.
Nur der IPSEC versucht auf der alten DDNS-Adresse die Verbindung wieder herzustellen, erfolglos. Nach einem Neustart der IPSEC-Dienste klappt es wieder sofort mit dem Verbindungsaufbau.
Als mögliche Problemlösung habe ich bereits "IPsec Reload on Failover" aktiviert, jedoch ohne Verbesserung der Situation.Hat jemand eine Idee zu diesem Problem?
-
Ahoi
1. Frage: Wie ist der Tunnel konfiguriert bzw. ist der DNS Name beim Tunnel-Setup auch der identifier, damit auch der entsprechende Helper gestartet wird?
2. Frage: Läuft auf den Sensen ein Prozess "dnswatch"?
3. Frage: Was sagt das IPSec Log (raccoon)?Und zum Tunnel selbst: Gibt es einen Grund, bei 2 Sensen an den Enden, dass es IPSEC sein "muss"? Wäre OpenVPN eine Alternative?
Grüße
-
Hallo,
zu 1. Der identifer ist ein "Distinguished name", was in der Vergangenheit auch immer gut funktionierte.
zu 2. Einen Prozess "dnswatch" habe ich nicht in der Prozessliste gesehen.
zu 3. racoon: INFO: IPsec-SA request for x.x.x.x queued due to no phase1 found.
Wobei x.x.x.x die alte DDNS-Adresse ist.Die Konfiguration ist über die Jahre gewachsen und hat bisher gut funktioniert, vor allem in Verbindung mit anderer Hardware (DrayTek, AVM etc).
Grüße
-
Könntest du zum Fehler ein wenig mehr Zeilen posten? Das Queueing ist nur das Resultat, aber nicht das Problem. Da muss vorher schon dann was stehen. Klar die alte IP ist in dem Zusammenhang doof, aber vorher müsste ein Reconnect / Reload getriggert werden.
-
Das Log gibt leider nicht viel her.
Alles logisch und nachvollziehbar:
Die Verbindung besteht normal.
Die Verbindung wird getrennt (wegen Zwangstrennung).
Verbindung kann nicht wieder hergestellt werden, da alle Versuche auf der kalten IP fehlschlagen müssen.May 6 00:32:42 racoon: INFO: begin Aggressive mode.
May 6 00:33:13 racoon: [XXX.XXX.XXX.XXX] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP XXX.XXX.XXX.XXX[0]->YYY.YYY.YYY.YYY[0]
May 6 00:33:32 racoon: ERROR: phase1 negotiation failed due to time up. 1e216a8f4a7cbd93:0000000000000000
May 6 00:33:32 racoon: INFO: IPsec-SA request for XXX.XXX.XXX.XXX queued due to no phase1 found.
May 6 00:33:32 racoon: [Self]: INFO: initiate new phase 1 negotiation: YYY.YYY.YYY.YYY[500]<=>XXX.XXX.XXX.XXX[500]Um es vielleicht noch einmal hervorzuheben, die Probleme finden auf dem Anschluss mit der statischen IP statt.
Dann ein manueller Neustart des racoon Service und alles läuft wieder super, da dann die DDNS-Adresse korrekt aufgelöst wird.
-
Ein ähnliches Problem hatte ich sporadisch auf einem beidseitig dynamischen IPsec Tunnel. Mit openVPN ist der Aufbau nach IP-Wechsel wesentlich schneller und stabiler.
-
Servus,
hatte das Problem auch, dass pfS trotz einem IP-Wechsel noch die alte IP gecached hatte und diese an den DynDNS weitergegeben hat. Somit hat der Host an der Gegenstelle falsch aufgelöst.
Mit dieser Lösung hatte ich dann Erfolg: https://forum.pfsense.org/index.php?topic=58034.0Viel Glück!
Harry -
" Alles läuft super bis auf der dynamischen Anbindung eine neue IP zugewiesen wird. Wenige Augenblicke später ist der DDNS-Wert entsprechend aktualisiert. Wenn ich auf der statischen Seite ein DNS Lookup auf den DDNS mache, wird der aktuelle Wert korrekt angezeigt."
Der DynDNS IST aktuell, aber die pfSense auf der anderen Seite des Tunnels fragt ihn nicht ab, sondern versucht weiter die alte IP. Mittlerweile habe ich das selbe Verhalten auch bei openVPN beobachtet…
-
…und hier erklärt bekommen:
https://forum.pfsense.org/index.php?topic=76735.msg421427#msg421427
Es ist die Cache-Lebensdauer (TTL), die der DynDNS Anbieter vorgibt.
Anbieter gewechselt nachdem DynDNS.com nicht mehr kostenlos ist? ;)
-
Ah hat Chris etwas Licht ins Dunkel bringen können. Sehr gut :)
Wenn du die Möglichkeit hast, deine DNS Zonen selbst zu verwalten, ist DynDNS nach RFC2136 sehr angenehm zu handeln, ansonsten gibt es ja inzwischen auch noch einige neue DynDNS Anbieter. Auch wenn deren Modalitäten teils etwas … frech sind.
Grüße
-
…unter Zeitdruck halt schnell einen Serviceanbieter ausgesucht, da DynDNS.com kostenpflichtig wurde und bei SPDNS.de gelandet.
Da ist scheinbar einen TTL von 5 min angesetzt, der "Support" dort reagierte in den letzten Tagen nicht auf meine Anfrage, ob das korrekt ist. Wenn die Zwangstrennung der Verbindung nachts ist, ist das ja eigentlich auch kein großes Problem, aber manchmal will die Telekom das am hellichten Tag durchziehen und dann nerven die verschwundenen Tunnel doch arg...
-
@chemlud: Kannst du nicht die Zwangstrennung über die pfSense machen lassen (also DSL direkt dort auflegen)? Also pfS die DSL Verbindung aufbauen lassen und als Trennung 5h morgens auswählen? ;)
-
uuups, gerade erst gesehen! Ja, tatsächlich, da ist ja eine Option für eine frei definierte Unterbrechung der Verbindung auf der pfSense GUI Seite für das WAN Interface, wenn man PPPoE wählt. Hab ich jetzt gleich eingerichtet… ;)
