Hmm ... sieht irgendwie immer noch komisch aus.
Die 6490 "sieht" die 7490 (die ja schon lange ihre DynDNS-Adresse aktualisiert haben sollte) zuerst auf der 84.135.142.106 ... und versucht halt die erste Verbindung dorthin aufzubauen. Erst später schlägt dann das DynDNS-Update der 7490 auf die nunmehr neue Adresse 84.135.152.120 durch (nachdem die 6490 auf der alten Adresse keine Antwort erhält und ins Timeout rennt) und die 6490 versucht es dann mit dieser Adresse.
Allerdings sieht das danach doch eher so aus, als ob da irgendetwas durcheinander geht (und so ad hoc erklärt eine falsche MTU das Problem auch nicht wirklich) ... die Reihenfolge (erst werden auf der 6490 die SAs eingerichtet und dann direkt wieder gelöscht) der Nachrichten ist trotzdem komisch, weil das "malformed packet" (0x1b) erst nach dem Löschen der SA auftaucht - das ist nun wieder gemeinhin ein Zeichen dafür, daß der bei der Entschlüsselung verwendete Key nicht stimmt (bzw. keiner der in dieser Richtung gerade eingerichteten, weil die Software wohl mit jedem Kandidaten die Dechiffrierung versucht, weil sie ja nicht wissen kann, welchen Key der Sender tatsächlich verwendet hat) und dann in der Folge im entschlüsselten Paket nur Garbage steht, was natürlich keine Software interpretieren kann.
Insofern deuten die Zeilen in der 6490:
Code:
2018-05-28 20:13:17 avmike:FreeIPsecSA: spi=2db1d8e7 protocol=3 iotype=1
2018-05-28 20:13:17 avmike:FreeIPsecSA: spi=2331 protocol=4 iotype=1
2018-05-28 20:13:17 avmike:FreeIPsecSA: spi=92597f9a protocol=3 iotype=2
2018-05-28 20:13:17 avmike:FreeIPsecSA: spi=8742 protocol=4 iotype=2
2018-05-28 20:13:17 avmike:payloads.cpp:43: IKE-Error 0x1b
2018-05-28 20:13:19 avmike:payloads.cpp:43: IKE-Error 0x1b
2018-05-28 20:13:23 avmike:payloads.cpp:43: IKE-Error 0x1b
2018-05-28 20:13:27 avmike:>>>4500 nat-t-keepalive[84.135.152.120:4500]
2018-05-28 20:13:31 avmike:payloads.cpp:43: IKE-Error 0x1b
für mich eigentlich darauf hin, daß die in den ersten Zeilen gelöschten SAs für das Entschlüsseln der Pakete von der 7490 nötig wären.
Die Gretchen-Frage ist es hier also, warum die 6490 schon zu diesem Zeitpunkt die SAs wieder abräumt ... ein Timeout kann es ja in der Kürze der Zeit eigentlich noch nicht sein und so würde ich (neben den bekannten VPN-Problemen der 6490 bei DS-Lite) auch weiterhin ein etwas unglückliches Timing für einen Teil der Probleme verantwortlich machen.
Eigentlich sollte die 6490 ja gleich beim Start die korrekte IPv4 der 7490 erhalten ... dann startet sie gar nicht erst mit der falschen Adresse und es gibt in der Folge auch kein Erfordernis, die "alten" Keys für die falsche Adresse irgendwie abzuräumen, was dann vielleicht doch die falschen SPIs (oder schlicht zuviele) trifft.
Witzig ist es aber auch, daß die 7490 schon der Ansicht ist, die Verbindung wäre bereits aufgebaut (das heißt dann, daß P2 auch schon durch ist aus Sicht der 7490) ... und dann in derselben Sekunde auch ihrerseits die SAs wieder abräumt ... und das ohne einen Anhaltspunkt, was sie dazu veranlaßt hat (ein Rückfall auf P1 ist ja auch nicht im Log verzeichnet).
Irgendwelche Pakete müssen die Peers aber auch
erfolgreich austauschen können, sonst würden sie niemals bis P2 kommen ... ich würde hier mal auf beiden Seiten einen Paketmitschnitt machen, einfach um zu sehen, ob es von der Gegenseite irgendein Paket gibt (dessen Inhalt sollte man mit dem korrekten SPI auch entschlüsseln können), das eine Erklärung für das umgehende Verwerfen der gerade erst eingerichteten SAs liefert.
Ansonsten könnte man (um die Probleme mit der MTU zu verifizieren) auch noch auf ein Set mit deutlich weniger Auswahlmöglichkeiten als "all/all/all" für P1 und "esp-all-all/ah-none/comp-all/pfs" für P2 setzen (abgesehen davon, daß "no-pfs" eben auch für das Tracen von Problemen sinnvoller ist, mit PFS kann man auch nichts entschlüsseln im Dump) - damit sollten zumindest die Pakete für P1 und P2 (und auch die Keepalive-Pings) nicht an die MTU heranreichen ... obwohl das natürlich nur als Diagnose taugt (i.V.m. einem Mitschnitt, aus dem zumindest die Payload-Größe in den UDP-Paketen ersichtlich ist) und nicht als Dauerlösung, wenn da wirklich mal ein "full-size packet" zu übertragen ist.
Ich weiß nicht genau, wie die Protokolle beim berühmt-berüchtigten MTU-Problem bei UM aussehen (bei VF/KD mag das Problem auch existieren, aber hier kriegen Kunden mit eigener 6490 m.W. eine "echte" IPv4 und haben damit die kleinere MTU durch den DS-Lite-Tunnel nicht) ... vielleicht findet sich ja irgendwo jemand mit einer 6490 (ob Provider- oder Retail-Version sollte am Ende sogar egal sein, solange es eine Version ist, bei der das VPN auf dem ATOM-Core läuft) am DS-Lite-Anschluß von UM, der mal ein zweites Protokoll zum Vergleich zur Verfügung stellen kann.
