IPSEC findet die neue IP des DDNS nicht

JeGr

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.

rj45

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.

eSpezi

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.0

Viel 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? ;)

JeGr

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...

JeGr

@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… ;)