Das Ergebnis ist noch genau dasselbe ... ein erstes Paket kommt an vom Client, die Box startet ihrerseits die Vorbereitungen für den IKE (das zu lesende "mainmode" taucht m.W. auch dann im Protokoll auf, wenn das in Wirklichkeit "aggressive mode" ist) und antwortet mit einiger Wahrscheinlichkeit auch entsprechend, aber danach kommt offenbar nichts mehr vom Client. Wenn der seinerseits schreibt "Phase 2 failed", sollte man vermutlich unterstellen, daß er Phase 1 für beendet hält ... wie er angesichts der Protokollierung in der Box auf diese Idee kommt, kann ich nicht nachvollziehen.
Eine (auf beiden Seiten) abgeschlossene Phase 1 hätte dann eigentlich nach einer entsprechenden Anzahl von Paketen (7 beim "main mode" und 4 beim "aggressive mode") eine eingerichtete SA für Phase 2 zur Folge (dieser Zustand wird häufig mit "QM_IDLE" bezeichnet in der Diskussion, kommt m.W. aus der Cisco-Ecke und ist der Zustand nach erfolgreichem Einrichten der SA für P2, egal in welchem Modus P1 erfolgte) - das würde ich hier für die FRITZ!Box verneinen, weil (nach meiner Ansicht) diese "Phase X ready"-Nachricht nicht den Abschluß der jeweiligen Phase dokumentiert, sondern ihren Beginn und dieses "Phase 2 ready" fehlt auf der FRITZ!Box-Seite. Das mit dem "Beginn" der Phase leite ich daraus ab, daß da im Anschluß normalerweise Zeilen in dieser Form im Protokoll auftauchen:
Code:
avmike:< cb_sa_created(name=<connection>,id=99,...,flags=0x00002003)
und wenn man das als "callback for SA created" interpretiert, werden diese SA eben erst dann eingerichtet, wenn "Phase 2 ready" bereits "durch" ist, was m.E. dafür spricht (an asynchrone Callbacks mit entsprechender Verzögerung glaube ich an dieser Stelle nicht wirklich), daß P2 eben da erst beginnt. Das korreliert auch ganz gut mit dem, was ich bei früheren Mitschnitten selbst erlebt habe (auch wenn das ältere Versionen waren), wenn mal eine solche Verbindung nicht richtig aufgebaut wurde.
Wobei das tatsächlich für mich hier auch absolut merkwürdig aussieht beim Timing und eher wie zwei unabhängig ablaufende Prozesse (auf dem Client). Der erste Versuch richtet eine SA ein (die 1, für ISAKMP) und wartet dann auf weitere Kommunikation ... nach 30 Sekunden wird diese SA 1 dann wieder entsorgt. Das geschieht aber nach meiner Interpretation nicht aus eigenem Antrieb, sondern weil ein weiterer Verbindungsversuch eintrifft (für den dann SA 2 eingerichtet wird, aber immer noch für ISAKMP) und der invalidiert dann (vermutlich, ist halt "confidential" bei AVM) die SA 1. Bei einer Verbindung vom Type "conntype_user" dürfte jedenfalls die Box nicht ihrerseits den zweiten Versuch starten, weil sie irgendwie "ungeduldig" wird, daß es nicht vorwärts geht.
Man sieht es auch an der "remoteip" im Protokoll (beim "add"). Wenn die beim Hinzufügen "0.0.0.0" ist, verhält sich die Box (nach allem, was ich bisher gesehen habe) rein passiv und arbeitet nur als Responder, bei einer konkreten IP-Adresse ist das dann das Ergebnis einer "remoteip"-Zeile in der Konfiguration und bei "255.255.255.255" wird die IP-Adresse (regelmäßig) durch DNS-Abfragen ermittelt und damit auch der Wechsel der IP-Adresse bei einem DynDNS-Namen realisiert und entsprechend behandelt.
Also wird auch der zweite Versuch wohl vom Client kommen. Warum der nun aber bereits nach drei Sekunden wieder abgebrochen wird (die SA 2 lebt ja nur diese drei Sekunden), kann man ja fast nur noch damit erklären, daß da die Gegenseite ihrerseits "Reset" macht, z.B. mit einem letzten "delete payload" (s. RFC), obwohl das in der Regel beim nächsten Versuch mit einem "initial contact" ohnehin gemacht wird, was dann alle bisherigen SA auch abräumt, damit beide Seiten "sauber" starten können - z.B. nach einem Crash auf einer Seite, wo es dann ohnehin keine alten SAs mehr gibt.
Warum der Client dann überhaupt noch den zweiten Versuch startet, ist (mir zumindest) eher unklar und vielleicht am ehesten mit zwei unabhängigen Prozessen (oder Threads) erklärt. Der eine startet den Verbindungsversuch und wartet seine 30 Sekunden (+- eine oder zwei) und ein anderer sendet die IKE-Messages und wiederholt seinerseits den Versuch des Schlüsselaustauschs nach einer Timeout-Spanne. Der zweite Thread hat dann gerade einen neuen Versuch gestartet, wenn der erste sich dazu entschließt, nun die Verbindung doch lieber wieder zu deaktivieren und daraufhin wird der IKE dann abgebrochen und irgendwie die Gegenseite noch darüber informiert.
Anders als bei der Verwendung von dynamischen IP-Adressen wäre es hier ja tatsächlich denkbar, daß ein Client mit einer statischen (IPv4-)Adresse auch wirklich den "main mode" beim IKE verwendet ... keine Ahnung, ob und wann das vom AVM-Programm "FRITZ!Fernzugang konfigurieren" auch unterstützt wird und erst recht habe ich keine Idee, wie das hier konfiguriert wurde - die Konfigurationsdateien sind ja offensichtlich (jedenfalls schließe ich das aus ihrem Fehlen trotz meiner expliziten Nachfrage) geheim.
Ich würde immer noch auf dem Client prüfen, ob die Antwort ankommt und ggf. auch, wieviele Pakete (wenn man sich auskennt, kann man sogar den Inhalt noch untersuchen) im IKE nun überhaupt ausgetauscht werden (die Anzahl der Pakete gibt indirekt auch wieder einen Hinweis, ob das nun "aggressive mode" oder "main mode" sein soll). Kommt die Antwort nicht an, wird sie wohl irgendwo unterwegs blockiert oder es ist eben doch eine Firewall auf dem Zielgerät (das muß ja nicht die Windows-eigene sein, auch die Reaktion/Antwort auf meine (zugegebenermaßen nicht explizit gestellte) "Frage" in dieser Richtung habe ich nicht gefunden).
Das wird sich hier ausschließlich anhand des VPN-Logs der Box aber nicht diagnostizieren lassen (das Log des Clients kann man ja in der Pfeife rauchen und der oben erwähnte Widerspruch in den Zuständen auf beiden Seiten irritiert mich ohnehin - vielleicht bietet ja auch der Client die Möglichkeit, da etwas mehr als diese eine Zeile mit dem Timeout zu erzeugen im Protokoll, aber das weiß ich nicht) und so kann man anhand der hier zu sehenden Protokolle (m.E.) nur konstatieren, daß dort eben Pakete vom Client bei der Box ankommen. Welche das genau sind, kann man ja durchaus auch in einem Mitschnitt auf der Box selbst ermitteln (1. Internetverbindung) und dann kann man auch wieder (selbst ohne genauere Kenntnisse über die Abläufe beim IKE) die Mitschnitte auf beiden Seiten vergleichen, ob gesendete Pakete tatsächlich beim Empfänger eintreffen.
Machen sie das und kommen sie trotzdem nicht in der jeweiligen Anwendung an (auch die Windows-Anwendung "FRITZ!Fernzugang" dürfte den IKE selbst durchführen und nicht nur "Anweisungen" an irgendwelche Netzwerk-Schichten senden - der AVM-Treiber ist ja als Netzwerk-Filter implementiert ... damit würde ich erwarten, daß die Anwendung in der Firewall-Konfiguration explizit "erwähnt" wird und nicht bei den Windows-Services unter dem Radar fliegt), dann ist es wohl eine Firewall, die da etwas blockiert.
Ist es definitiv keine Blockade irgendwelcher Pakete, würde ich trotzdem noch einmal mit einem anderen VPN-Client (Shrewsoft drängt sich hier für einen PC förmlich auf und der kann dann (das weiß ich nun wieder) auch seinerseits ordentlich protokollieren, was da im Netzwerk so passiert beim Schlüsselaustausch) überprüfen, ob es tatsächlich an der FRITZ!Box liegt.
Kriegt ein Android-Gerät mit einem "VPN-Konto" per GUI eine Verbindung auf die Reihe (egal, ob da jetzt irgendwelche Pings funktionieren oder nicht, P2 sollte aber definitiv abgeschlossen sein oder zumindest stattfinden und das sieht man dann auch im "ike.log" der Box an der oben erwähnten Protokollierung von "cb_sa_create"), käme ich jetzt nicht als erstes auf die Idee, das Problem auf der Box zu verorten und würde eher auf dem PC weitersuchen.
Wobei ich noch nicht so richtig oder "definitiv und eindeutig" verstanden (bzw. gelesen) habe, welche der mit "FRITZ!Fernzugang konfigurieren" erzeugten Dateien nun wo importiert wurde ... dem Augenschein nach würde ich die Verbindung mit der Mail-Adresse im Namen für importiert halten und da steht zumindest mit "p1mode=4" dann auch ein "mode = phase1_mode_aggressive;" in der Konfiguration - man kann also "schlußfolgern", daß die Datei importiert wurde (im GUI werden die neuen Proposal-Sets mit 8 Stunden Life-Time verwendet) und der "aggressive mode" verwendet wird (zumindest erwartet das die Box dann so, aber die parallel erzeugte Datei für den Client (die sicherlich auch da importiert wurde) sollte ja da keinen Unterschied aufweisen).
Die entscheidende Frage ist es hier halt, ob die beiden "Partner" sich nicht erreichen (zumindest in der Richtung FRITZ!Box -> PC, die andere scheint zu funktionieren, wie man im "ike.log" der Box sieht) oder ob sie sich in Phase 1 nicht einigen können (das gibt normalerweise aber entsprechende Fehlercodes) oder ob sie sich (wegen unterschiedlicher Einstellungen für P1) nicht verstehen und der PC daher die Antwort der FRITZ!Box zwar erhält, sie aber falsch versteht oder gar nicht interpretieren/entschlüsseln kann (was er aber dann auch wieder "vergißt" zu protokollieren und insofern halte ich es immer noch für wahrscheinlicher, daß diese Antworten ihn gar nicht erst erreichen).
Nächster Schritt wäre für mich der Paketmitschnitt auf beiden Seiten oder eine Gegenprobe mit anderem Client bei gleichzeitiger Prüfung des Protokolls in der FRITZ!Box - erst einmal die wahrscheinliche Quelle des Fehlers weiter eingrenzen.
Das war auch der letzte so lange Beitrag meinerseits in diesem Thread ... es war der Versuch, mögliche Punkte zum Testen zu zeigen und ein paar "Schlußfolgerungen" meinerseits zu begründen. Gibt es hier weiteres "Material" zu sehen, wo man mal einen Blick hineinwerfen kann, wird es trotzdem nur noch "buzzwords" von mir geben, solange ich nicht irgendeine - auf den ersten Blick vollkommen abwegige - Vermutung begründen muß.
Ob die bisher von mir geäußerten Vermutungen (z.B. bzgl. des "Auftauchens" des AVM-Programms in der Regelliste der (Windows-)Firewall) stimmen, sollte man ggf. auch selbst prüfen ... deshalb habe ich jeweils dazu geschrieben (jedenfalls habe ich es versucht), was ich meinerseits für ausreichend belegt halte auf der Basis eigener (i.d.R. allerdings früherer) Versuche und anderer - auch hier im IPPF - erfolgreich gelöster Probleme und wo ich das nicht gut genug kenne. Wobei auch diese Erfahrungen/Vermutungen definitiv nicht für die (neue) 06.83 bei der 7272 gelten müssen - und da fällt mir dann auch noch die Frage ein, ob diese 7272 regelmäßige Updates gekriegt hat (dann ist der "irgendwo in der Gegend der 06.20" vollzogene Wechsel (iirc) bei den "proposal sets" nichts Neues - auch wenn das passende Fehlermeldungen erzeugen sollte, wenn es da keine Überschneidungen gibt) oder ob das ein größerer Sprung war und zuvor eine Version <= 06.20 installiert war.