Die Box bemerkt aufgrund der veränderten Absender-Adresse der Gegenseite die IP-Änderung.
Das sind zwei unterschiedliche Mechanismen - wäre das nicht NAT-T bei IPSec, würden die Pakete nach der Änderung der Absenderadresse gar nicht erst weiter dekodiert werden. Hier wird lediglich "registriert", daß die Pakete für eine IPSec-Verbindung jetzt eben über einen anderen Weg beim Empfänger eintreffen - das könnte (aber eben nur bei NAT-T) ja auch durch vollkommen andere Umstände als den Wechsel der (externen) IP-Adresse auf der Gegenseite erfolgen, denn die Verbindung besteht hier ja nicht mit dem Router selbst, sondern mit einem "nachgelagerten" Gerät, das selbst gar keine Ahnung hat (und auch keine haben muß), welche externe IP-Adresse gerade (als "Absender") verwendet wird und ob/wann sich diese ändert.
Die turnusmäßige Auflösung über DNS liefert aber noch die alte Adresse
Genau DIESE turnusmäßige Abfrage stelle ich ja meinerseits in Frage im "identity protection mode" (oder auch "main mode" genannt:
https://de.wikipedia.org/wiki/IPsec) ... denn dabei ergibt sie per se ja keinen Sinn. Wenn die Identität der Gegenstelle über eine statische IP-Adresse und/oder andere Mechanismen "festgelegt" ist (und nicht nur auf der "Ansage" der Gegenstelle, welche Identitäten verwendet werden sollen und den Hashes über die jeweils verwendeten PSK, basiert), dann braucht es auch keine regelmäßigen Abfragen mehr, ob sich diese Identität geändert hat.
daraus resultiert diese Meldung
Schaut man genau hin, wird aber danach in der Kommunikation (in der Sicherungsschicht für IPSec, in der auch die "dead peer detection" läuft und das ist NICHT der zu tunnelnde Traffic) mit der Gegenseite aber durchaus ERFOLGREICH die neue Adresse (2.243.irgendwas) verwendet, denn die aufeinanderfolgenden Protokolleinträge:
Rich (BBCode):
2024-05-09 05:57:23 avmike:>r> infomode 4500[93.131.32.132:4500] StrongSwan: V1.0 140 IC 587f67f73de9635f RC 85e932681a81cafe cc5b459 HASH flags=e
2024-05-09 05:57:23 avmike:<<< 4500 infomode[93.131.32.132:4500] StrongSwan: V1.0 140 IC 587f67f73de9635f RC 85e932681a81cafe 8a49a03b HASH flags=e
2024-05-09 05:57:49 avmike:StrongSwan: nat_t_port changed from 2.243.250.254:4500 to 93.131.32.132:4500
2024-05-09 05:59:53 avmike:>r> infomode 4500[2.243.250.254:4500] StrongSwan: V1.0 140 IC 587f67f73de9635f RC 85e932681a81cafe a0638c11 HASH flags=e
2024-05-09 05:59:53 avmike:<<< 4500 infomode[2.243.250.254:4500] StrongSwan: V1.0 140 IC 587f67f73de9635f RC 85e932681a81cafe e81048b7 HASH flags=e
2024-05-09 06:01:14 avmike:>r> infomode 4500[2.243.250.254:4500] StrongSwan: V1.0 140 IC 587f67f73de9635f RC 85e932681a81cafe 1adf8272 HASH flags=e
2024-05-09 06:01:14 avmike:<<< 4500 infomode[2.243.250.254:4500] StrongSwan: V1.0 140 IC 587f67f73de9635f RC 85e932681a81cafe 7fabffd0 HASH flags=e
kennzeichnen jeweils sowohl empfangene (mit "<" als Richtung ) als auch gesendete (mit ">") Pakete - vor dem Wechsel der Adresse mit der "alten" IP (93.131.something) und im Anschluß mit der neuen.
Da fanden/finden gar keine DNS-Auflösungen statt in diesem Moment - auch keine "zusätzlichen", die von AVM da in den Ablauf beim "aggresive mode" eingebaut werden.
Erst als um 06:28:22 dann die SAs erneuert werden sollen, versucht die FRITZ!Box (immer noch ohne erneute DNS-Auflösung und daher auch noch mit der alten IP) wieder, die Gegenseite zu diesem Zweck zu kontaktieren und hat damit aber keinen Erfolg ("timeout" um 06:28:34). Derweil leben die alten SAs aber weiter, denn alles das, was da an Paketen mit den identischen Angaben bei "IC" und "RC" (das könnten die "session keys" für die (symmetrische) Verschlüsselung sein) protokolliert wird, gehört noch zur alten "Verbindung".
Erst um 06:32:36 stellt das FRITZ!OS dann fest (weil jetzt eben DOCH eine erneute DNS-Auflösung erfolgte, nachdem die Identifikation der Gegenstelle beim erneuten Versuch einer Aushandlung für Phase 1 nicht dem entsprach, was erwartet wurde), daß sich die IP-Adresse bei der DNS-Auflösung geändert hat und räumt dann erst mal ALLES ab, damit ein komplett neuer Aufbau der Verbindung erfolgen kann. Nur wird hier offenbar eine "normale" DNS-Auflösung versucht (oder auch hier noch KEINE neue Abfrage bei einem Forwarder gestartet) und daher wird erst einmal wieder die alte IP-Adresse (die aber 30 Minutren nach dem DynDNS-Update wohl eher nicht mehr aus einer AKTUELLEN Abfrage resultiert) verwendet, womit das dann noch einmal in ein Timeout läuft (06:34:39). Erst DANACH erfolgt dann offenbar doch eine neue DNS-Abfrage und JETZT wird auch der Wechsel der IP-Adresse erkannt und mit der neuen Adresse der Gegenstelle gelingt dann auch ein (komplett NEUER) Verbindungsaufbau.
Das alles klappt eben mit dem "aggressive mode" bei AVM deutlich besser, weil dort die Häufigkeit der DNS-Abfragen höher ist (und vermutlich sogar Caches im FRITZ!OS umgangen werden) und somit Wechsel der dynamischen Adressen viel schneller festgestellt werden können. Wenn hier beim DynDNS-Anbieter um 05:58 Uhr die Änderung der IP-Adresse protokolliert wird (was ja auch mit dem Wechsel der IP-Adresse in den "infomode"-Messages korreliert), dann müßte schon ein "authoritative name server" eine für DynDNS vollkommen ungewöhnliche TTL liefern, damit Änderungen erst nach über 34 Minuten (denn um 06:32:36 soll da ja dann noch die alte IP-Adresse genannt worden sein) wirksam werden (hier dann aber plötzlich innerhalb von weniger als zwei Minuten). Überprüfen läßt sich das ja relativ simpel mit einer direkten Abfrage des SOA für ddns.de - dort sollte die (max. mögliche) TTL (denn alle Caches können nur kleinere Werte liefern) zu sehen sein.
Man darf nicht aus den Augen verlieren, daß das alles tatsächlich keine "linearen" Abläufe sind und der Aufbau der Verbindung (ISAKMP) und der "Betrieb" (zusätzliche Kapselung bei NAT-T und "dead peer detection") zwei getrennte Tasks bleiben - die SAs für die Verschlüsselung werden vom
vpnd ausgehandelt und eingerichtet und die aktiven Transformationen verwaltet AVM mittlerweile (seit einigen Versionen, zuvor lief das alles im
kdsld von AVM, also im Kernel-Treiber für den AVM-(WAN-)Stack) direkt mit den vom Linux-Kernel gebotenen Funktionen (nur dann funktioniert das auch mit dem Hardware-Support für die AES-Verschlüsselung im Kernel).
Die permanente (bzw. "schubweise") DNS-Auflösung beim "aggressive mode" dürfte ebenfalls eine solche, parallel laufende Aufgabe sein und wenn dabei dann tatsächlich ein Wechsel der Adresse erkannt wird, wird dann ein neuer Verbindungsaufbau (diesmal eben in Folge dieser Adressänderung und nicht durch den Ablauf einer SA) angestoßen. Wird kein "aggressive mode" verwendet, findet wohl (zumindest würde ich das anhand des Protokolls so lesen) diese zusätzliche Aufgabe nicht statt (zumindest nicht für DIESE Verbindung) und somit wird das Problem eben erst beim Ablauf der SA bemerkt.
