[Gelöst] Kein VPN mehr mit Fritzbox 7272 und 6.83 - wie beheben?

Box schon stromlos gemacht? wenn nein, dann durchführen und testen
die Konfig. wurde immer von Box zu Box usw. übernommen, evtl. liegt ein KKK vor

Schau erst einmal in der FRITZ!Box in die Support-Daten (die avmike.log dürfte eher die vom Client sein, in der Box sollte die schon etwas "geschwätziger" ausfallen) und versuche, in der dortigen "avmike.log" etwas zur Ursache zu finden. Wenn da gar kein Verbindungsversuch verzeichnet sein sollte vom Client, dann würde ich am ehesten auf ein Problem mit der (internen) Portweiterleitung tippen (also ein Problem für UDP 500 bzw. 4500 für den IKE). Derartige Probleme mit der Weiterleitung sind ja für die neuen Versionen mit PCP durchaus von mehreren Leuten festgestellt worden und so eine Neueinrichtung mag zwar auch dagegen helfen, aber ich würde vor so einem Berg an Arbeit eher mal versuchen, der Ursache nachzuspüren - zumal ich bei der "Esoterik" so mancher PoR-Anleitung auch immer wieder überrascht werde.

---

-Es gibt zwar tatsächlich in der Box einen hinterlegten Grund für ein Reboot (aber nur im flüchtigen RAM) und vielleicht im (nicht veröffentlichten) AVM-Teil auch Code, der dann unterschiedliche Pfade nimmt, aber das sollte eben auch nach einem einfachen "Steckerziehen" relativ schnell erledigt sein. Die anderen möglichen Quellen einer "Betriebsspannung" ((aktiver) ISDN-Bus o.ä.) mag man auch noch entfernen ... aber bereits ein angeschlossenes (passives) ISDN-Gerät sollte selbst soviel Energiebedarf am internen S0 haben (wenn da nicht wirklich die Speisung auch abgeschaltet wird, was allerdings nur schwer zu testen ist), daß auch die Stütz-Elkos innerhalb kürzester Zeit leer sind. Die an einigen Stellen zu lesenden 5 bis 10 Minuten "Wartezeit" erscheinen mir auch eher etwas merkwürdig bzw. sind vielleicht dem Alter so mancher Anleitung geschuldet, wo dann RAM noch anders arbeitete und irgendwelche "Restladungen" zu zufälligen Speicherinhalten führten oder zumindest führen konnten.

Heutzutage würde ich eher erwarten, daß entweder der Speicher wirklich selbst mit einem RST-Signal auf einen definierten Zustand gebracht werden kann (beim "ersten Einschalten" bzw. beim "power good" schon durch den Memory-Controller des Prozessors/Chipsatzes) oder das zu ladende Betriebssystem diese Aufgabe übernimmt (im Rahmen des "setup"). Das mag früher anders gewesen sein und vielleicht spielte bei solchen PoR-Anleitungen dann auch die Erfahrung eine Rolle, daß so eine FRITZ!Box eben nur wenige Möglichkeiten bot, ihren eigenen "Energiespeicher" wirklich "leerzusaugen".

Doch so viel, ja?

Wie soll man anhand dieses kurzen Auszugs jetzt etwas erkennen können, gar irgendwelche "Regelmäßigkeiten"?

Offenbar kommt der Client bis zur Box durch ... das ist dann aber auch schon alles, was man sieht.

Warum wird da nun die SA Nr. 6 hinzugefügt, während die SA 4 noch vorhanden ist (die wird erst danach gelöscht) und was mit der SA 5 wohl passiert sein mag in der Zwischenzeit?

Maximal kann man noch "raten", daß das Löschen der SA 6 nach 30 Sekunden darauf zurückzuführen sein könnte, daß in diesen 30 Sekunden keine weitere Reaktion von der Gegenseite kommt. Ob das für SA 4 und SA5 ebenso gilt (die 5 gibt es entweder immer noch oder die war schon vor der 4 wieder weg), weil der Client einfach alle 30 Sekunden einen neuen Versuch unternimmt (und dann ältere SAs für denselben Client ohnehin invalidiert werden müssen), dürfte man aber auch noch sehen können, wenn man die vollständigen (und sinnvoll maskierten) Protokolle hat.

Wenn ich (so wie hier) maskierte IP-Adressen sehe, fällt mir nur noch "facepalm" ein ... wollen wir mal nachrechnen, wie groß die Gefahr des "Wiedererkennens" wird, wenn man die ersten zwei Tupel so einer Adresse einfach so läßt, wie sie sind? Das ist auch nicht nur irgendeine Marotte oder übergroße Neugierde meinerseits ... so, wie sich die Nachricht "current=1xx.xxx.xxx.xxx new=1xx.xxx.xxx.xxx" jetzt dankenswerterweise liest, kann man nur noch raten, ob sich diese Adressen nun unterscheiden oder nicht (beides wäre hier denkbar). Wenn man also irgendetwas "maskieren" will, dann bitte so, daß Unterschiede und Gemeinsamkeiten erkennbar bleiben und ich kann hier zwischen den "x" einfach keinen Unterschied feststellen (nicht einmal ein "u" ist dabei).

Außerdem gehören nun einmal zu einer VPN-Verbindung mindestens zwei Partner und man kann es offenbar nicht oft genug betonen, daß zu einer (sinnvollen) Fehlersuche auch die (zeitgleichen) Protokolle beider Seiten gehören (wobei auch beide Seiten eine sekundengenaue und korrekte Uhrzeit verwenden). Wie soll man ansonsten bitte sehen können, ob die Antworten der Box beim Client ankommen oder nicht? Und zwar genau die für diesen "Verbindungsversuch" und nicht für irgendeinen anderen ... deshalb gehört eigentlich auch zu jedem Protokoll noch die passende VPN-Konfigurationsdatei dazu, weil die meisten Leute beim wilden Probieren irgendwelche Einstellungen hin und her ändern, den Überblick verlieren und dann trotzdem darauf beharren, daß sie doch "gar nichts gemacht" haben - häufig ist ihnen das vielleicht gar nicht bewußt. Außerdem erspart es dem Hilfewilligen, sich erst mühsam über mehrere Beiträge zusammenreimen zu müssen, wie die Konfiguration mal aussah und wie sie sich nun im Ergebnis irgendwelcher Tipps verändert haben mag.

mfd schrieb:

Der Ausschnitt entspricht exakt dem Teil, der einen Verbindungsversuch zugeordnet werden kann.

Zum Vergrößern anklicken....

Da sind aber mindestens zwei "Verbindungsversuche" im Protokoll zu sehen ... ich kann mir vieles vorstellen, aber nicht, daß der AVM-Client exakt zwei solcher "Verbindungsversuche" startet, wenn man ihn einmal zum Herstellen der Verbindung auffordert und nach dem zweiten dann direkt aufgibt.

Entweder der Client probiert es mehrfach (und dann vermutlich(!) auch mehr als zweimal) und bringt dann eine entsprechende Fehlernachricht oder genau einmal - einen Versuch mit einer einzigen Wiederholung kann ich mir beim besten Willen nicht erklären (was allerdings noch lange nichts heißen muß).

Nach dem Bild in #1 dauert es ja auch exakt 35 Sekunden, bis der Client sein Versagen eingesteht. Warum sollte der nun für eine einzelne Aufforderung zum Verbinden so eine "krumme" Zeit als Timeout verwenden? Bei 35 Sekunden und zwei Versuchen lt. Deinen Auszug aus der Box (die ja dann sicherlich auch beide in ein Timeout laufen müssen, bevor der Abbruch kommt), wären das ~17 Sekunden Timeout für einen einzelnen Versuch und das klingt zumindest sehr komisch. Auch sieht der Auszug aus der Box eher danach aus, daß der Client da ein Timeout von 30 Sekunden verwendet, denn der zweite Verbindungsversuch kommt um 14:25:04 und das ist ziemlich exakt 30 Sekunden nach dem Zeitpunkt, wo der Server (die Box) ihrerseits P1 für "progressing" hält und auf weitere Pakete vom Client wartet. Die kommen aber wohl nicht an, weil die Antwort der Box den Client gar nicht erreicht.

Sollte ich mich da tatsächlich in einem so schweren Irrtum hinsichtlich des Verhaltens des AVM-Clients befinden, lasse ich mich gerne mit einem Mitschnitt der Kommunikation auf dem PC eines Besseren belehren, wo der Client zwei Versuche im Abstand von 17 Sekunden startet. Aber dann stellt sich halt wieder die Frage, was denn mit den SAs 1-5 nun genau passiert ist und welche VPN-Verbindung diese Indizes "benutzt" haben soll, wenn es nicht die vom getesteten Client war.

Meine Bemerkung bzgl. des Protokolls galt ohnehin auch für die "Client-Seite" ... ich mag auch nicht glauben, daß sich das Protokoll des Clients auf die drei Zeilen in #1 beschränkt. Da wird für P2 ein Timeout protokolliert und alle drei Zeilen aus derselben Sekunde enthalten gar keine Informationen zur (zwangsweise davor liegenden oder ich halte mich lieber raus, weil ich dann doch nicht weiß, wovon ich schreibe) "Phase1" des IKE.

Wenn ich mir andererseits den Rest des Textes in #1 so durchlese, solltest Du vielleicht erst noch einmal den verwendeten PC überprüfen und mit dem meinetwegen eine Verbindung zu irgendeiner anderen Box aufbauen. So, wie sich das liest, hast Du FRITZ!Fernzugang auf dem PC neu installiert nach mehreren Jahren und mit ein wenig Pech ist da nur die Firewall oder irgendeine ggf. verwendete AV-Suite jetzt eingeschnappt. Das wäre jedenfalls die Stelle in einer Windows-Installation, wo ich zuerst suchen würde, wenn irgendwelche Pakete nicht auf dem Windows-Rechner ankommen, wie es hier (nach den bisher verfügbaren Informationen) wohl der Fall ist.

Nun habe ich allerdings auch keine 7272 ... aber für die 7490 mit der 06.83 kann ich festhalten, daß VPN-Verbindungen prinzipiell funktionieren (aber auch wieder nicht, ob das mit FRITZ!Fernzugang klappt, denn mich könnte man nicht mit Geld und guten Worten dazu bringen, das als VPN-Client zu verwenden - das liegt aber nur an der Art, wie das sich ins System einbringt).

Wenn Du tatsächlich schon mit einem Android-Gerät (was vorher hoffentlich auch nachweislich funktionierte?) Probleme hast (wobei da ja der Verbindungsaufbau wohl klappen soll?), dann könnte es eventuell ja wirklich am neuen FRITZ!OS (dann aber bei der 7272 und nicht generell) liegen. Ich bin da trotzdem immer erst einmal skeptisch, wenn mir jemand solche Erkenntnisse "unterjubeln" will ("Irgendwie scheint es bei der Box zu hakeln.") und das nicht mit ausreichenden Informationen unterlegt ist.

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

Ein letztes Mal von mir der Hinweis, daß auch ein (kundiger) Blick in die Konfiguration helfen kann.

Ich weiß nicht mehr, wie "FRITZ!Fernzugang konfigurieren" nun genau arbeitete (und werde es nur für diese Frage auch definitiv nicht selbst installieren), aber gerade beim "Mischen" verschiedener Konfigurationswege kann es eben schnell mal Späne geben. Jeder Client kriegt für eine VPN-Verbindung vom Typ "conntype_user" eine IP-Adresse aus dem LAN der FRITZ!Box zugewiesen ... bei der Konfiguration über das GUI (und Standardeinstellungen beim DHCP-Server der FRITZ!Box, auch wenn dieser ggf. ausgeschaltet wird) starten diese Adressen bei der ".200".

Wenn man das bei "FRITZ!Fernzugang konfigurieren" explizit vorgeben muß (bzw. kann) und es nicht die ".200" ist, die da verwendet wird, dann wäre alles gut ... ansonsten passen die beschriebenen Symptome auch problemlos zu einer Konfiguration, wo es mehr als einen Client mit der ".200" in den VPN-Einstellungen gibt.

Und damit bin ich hier dann auch raus ... viel Erfolg.

Füge mal auf der Serverbox in der accesslist any ein


LG