FritzBox VPN wird plötzlich nicht mehr aufgebaut - IKE 0x2027

[Cheater]

Hallo zusammen,
seit heute Nacht kommt meine VPN Verbindungen zwischen meinen 2 Fritzboxen nicht mehr zustande. Fehler IKE-Error 0x2027.

Ich glaube zu meinen, dass die 7490 ein Update von 7.56 auf 7.6 gemacht hat.

Hauptbox: 5530 Fiber

zweite Box: 7490 mit Internetzugang über Mobilfunk --> Handy am USB Anschluss (Congstar)


Hat bereits alles einige Monate einwandfrei funtktioniert.

Die 5590 kann aber ein zweites VPN zu einer anderen Fritz!Box weiterhin ohne Probleme herstellen.

DynDns der 7490 funktioniert und wird auch aktualisiert.

Die 7490 zeigt im Online Monitor als Mobilfunk IP an: 192.168.42.48

Wieistmeineip.de sagt: 80.187.71.168

APN Zugangspunkt des Handys ist internet.telekom

Meine Vermutung liegt darin, dass der Fehler irgendwo beim Mobilfunkzugang liegt, aber ich komme einfach nicht weiter. Ich habe bereits den VPN Zugang in beiden Boxen neu eingerichtet.

Vielleicht kann mir jemand noch einen Tipp geben, wie ich weiter nach der Lösung suchen kann.

Grüße, Dominic

 

[stoney]

Meine Vermutung liegt darin, dass der Fehler irgendwo beim Mobilfunkzugang lieg

genau, denn

Die 7490 zeigt im Online Monitor als Mobilfunk IP an: 192.168.42.48

Wieistmeineip.de sagt: 80.187.71.168

zeigt dies.

Verwende mal als APN internet.t-d1.de - Benutzer und Kennwort können leer bleiben.

 

[Cheater]

Servus,
mit diesem APN hatte ich vorhin schon einmal experimentiert. Jetzt habe ich ihn nochmal eingetragen und auch die 7490 neu gestartet.

IP in der Box ist jetzt 192.168.42.145 (Genutzte DNS-Server 192.168.42.129 (aktuell genutzt für Standardanfragen))
Wieistmeineip.de sagt. 37.85.121.51

 

[KunterBunter]

Ich glaube zu meinen, dass die 7490 ein Update von 7.56 auf 7.6 gemacht hat.

Ich glaube auch, ich weiß nur nicht wann. Wann glaubst du denn zu meinen, wann es war?

 

[Cheater]

Ich weiss, dass das nicht sehr präzise formuliert ist. Ich habe keine Mail bekommen, meine aber, dass ich auf der 7490 was diesbezüglich gelesen habe, bin mir aber nicht so sicher, da ich mittlerweile seit 11 Uhr an dem Problem sitze.

Edit: Ich nehme alles zurück:
Installiert am: 02.03.2025 2:46

Also ist das Update definitiv nicht das Problem.

 

[stoney]

Okay, das mit dem USB-Tethering hatte ich glatt überlesen.

So konnte es doch eigentlich noch nie funktioniert haben, außer die 7490 hat die VPN-Verbindung zur 5530 aufgebaut - hat sich hier etwas an der IPv4 Anbindung geändert?

 

[Cheater]

Ich habe definitiv nichts geändert.

Bisher war die 7490 bei der 5530 unter den VPN Freigaben eingetragen und umgekehrt und alles hat monatelang funktioniert.

 

[Erforderlich]

Wenn das Timing mal richtig blöd ist, funktioniert auch mal die VPN-IPv4only-Verbindungsaufnahme nicht, trotz einer aktivierten "VPN-Verbindung dauerhaft halten"-Option.
Deswegen hatte ich in der Vergangenheit immer zwei Dinge eingestellt:
1) 4G mit IPv4 per APN internet.t-d1.de und
2) eine SIP-Verbindung über VPN in Richtung xDSL/Glas-Box als meine "VPN-Verbindung wirklich dauerhaft halten"-Option.

 

[Cheater]

Die Frage ist doch wieso ich trotz internet.t-d1.de keine öffentliche IP bekomme.

 

[Erforderlich]

War nicht bei USB-Tethering die Box immer im lokalen Netz des Sticks?
So war es damals jedenfalls mal, als ich so einen Stick am Router hatte. Da war der APN für die Box auch schnurz.

 

[PeterPawn]

In der 5530 sollte kein Hostname für die 7490 eingetragen sein in der Konfiguration (geht m.W. nur mit "handgemachter" Konfigurationsdatei), damit die 7490 in jedem Fall der Initiator der IPSec-Verbindung ist - die 7490 ist ja für ihre Gegenstelle ohnehin nicht erreichbar, wenn sie über Tethering angebunden ist.

 

[Erforderlich]

Letztens habe ich auf meiner 7560 ein IPsec-VPN hinter einem Huawei-Glasfaser-Router erfolgreich eingerichtet.
Es funktionierte bestens mit einem "echten" aber nicht wirklich verwendeten DynDNS-Hostnamen auf der 7560-Seite und einer MyFRITZ!-Adresse auf der 5590-Seite. "handgemacht" ist zumindest beim FRITZ!OS: 07.30 der 7560 nicht mehr nötig.

 

[Cheater]

Nur nochmal als Info. Ich nutze keinen Stick sondern ein Handy als Modem und das VPN konfiguriere ich über die Weboberfläche, da ich von der Konfigurationsdatei keine Ahnung habe.

 

[Erforderlich]

Du benutzt USB-Tethering und mein Notebook bekommt dabei eine lokale IPv4 vom Smartphone. Deiner 7490 dürfte es dabei nicht anders gehen, wie die 192.168.42.48 schon klarstellt.

 

[Cheater]

Okay und wie kann ich das ganze denn nun wieder zum funktionieren bringen?

Edit: Habe gerade die 5530 von OS 8.0 auf 8.02 gebracht jetzt funktioniert das VPN zur Firma (beides Festnetzanschlüsse mit IP Festnetzanschluss auch nicht mehr.

 

[PeterPawn]

"handgemacht" ist zumindest beim FRITZ!OS: 07.30 der 7560 nicht mehr nötig.

Ich rate mal, daß dabei der "unechte" DynDNS-Eintrag aber immer auf die IP-Adresse zeigt, von der auch die IPSec-Pakete des Anschlusses mit der nicht-öffentlichen IPv4-Adresse kommen?

Dann ist das wirklich kein Problem - aber wenn die IPSec-Pakete von einer anderen Adresse kommen oder diese gar gewechselt wird, wird es sicherlich eines werden (kannst Du ja leicht probieren, wobei dann auch der richtige Initiator forciert werden muß, damit die Verbindung nicht aus der (ohnehin funktionierenden) Gegenrichtung aufgebaut wird).

Ich wüsste nicht, daß AVM an der IPSec-Implementierung (mit IPv4 als Transport) weiter geändert hätte - da eben eine IPSec-Verbindung im "aggressive mode" die Kenntnis der IP-Adresse der Gegenstelle erfordert (und die eigentlich sogar statisch sein müsste), macht AVM in regelmäßigen Abständen eine DNS-Abfrage für die Adresse des Peers, sofern in der Konfiguration ein DNS-Name für die Gegenstelle (als Hostname, nicht als Kennung für P1) eingetragen ist, um auch mit dynamischen Adressen eine VPN-Verbindung zu ermöglichen (was nirgendwo standardisiert ist).

Meines Wissens kann der GUI-Assistent für eine IPSec-Verbindung immer noch nicht zwischen diesen beiden Daten (Mehrzahl von "Datum" als einzelner Datenwert) trennen und verwendet dieselbe Eingabe für beide Werte. Genau das kann man mit einer handgemachten Konfigurationsdatei unterbinden (wie, ist hier oft genug dokumentiert und diskutiert - einfach mal nach "Initiator responder ipsec" suchen) und bei fehlender Hostangabe werden erst gar keine Abfragen für die DNS-Auflösung ausgeführt und auch keine (aktiven) Verbindungsversuche gestartet (diese Seite ist dann also nur ein "responder").

Jedenfalls wäre das MEIN Tipp, um eine "einseitige" IPSec-Verbindung zu konfigurieren, die sicher aufgebaut werden kann - sollte diese 10.irgendwas-Adresse am Ende Ergebnis der Nutzung eines AFTR und nicht nur eines CGNAT sein (also es sich eigentlich um einen "DS lite"-Anschluß handeln), können zumindest erst mal die SA eingerichtet werden, auch wenn später u.U. die MTU nicht passt.

Außerdem werden m.W. auch heute noch die IPSec-Protokolle in der Support-Datei ausgegeben (sogar mit deutlich mehr Informationen als früher) - alles das, was ich in der Vergangenheit zu deren Notwendigkeit (auf beiden Seiten) und dem "HowTo" des (richtigen) Generierens hinsichtlich Neustarts und Zeitpunkt des Auslesen geschrieben habe, gilt auch weiterhin.

 

[Cheater]

Nach dem Update auf 8.02 geht auch meine anderes VPN nicht mehr. Ich werden mal versuchen auf 7.9 zu recovern.

Edit: jetzt geht das VPN plötzlich wieder. Die Kiste treibt mich in den Wahnsinn.

 

[Cheater]

Ich rate mal, daß dabei der "unechte" DynDNS-Eintrag aber immer auf die IP-Adresse zeigt, von der auch die IPSec-Pakete des Anschlusses mit der nicht-öffentlichen IPv4-Adresse kommen?

.......

Ich habe mir das jetzt mal durchgelesen, muss aber ehrlich sagen dass ich davon nichtmal die Hälfte so richtig verstehe.

Was soll ich denn jetzt noch versuchen, damit ich das wieder ans Laufen bekomme?

 

[PeterPawn]

In der Box mit der öffentlichen IPv4-Adresse die Einstellungen sichern, aus der Sicherungsdatei die vpn.cfg extrahieren (und die verschlüsselten Einträge decodieren), dann darin alles löschen, was nicht zur fraglichen Verbindung gehört und in der verbleibenden Verbindung die Angabe bei remotehostname (Schreibweise rein aus dem Gedächtnis und ohne jede Gewähr) entfernen. Anschließend die so entstandene Datei als neue VPN-Verbindung importieren (dabei wird die bestehende gleichen Namens überschrieben, ansonsten die alte vorher löschen). Ist das erfolgreich, sollte in der VPN-Übersicht für die Gegenstelle 0.0.0.0 oder 255.255.255.255 stehen, solange die sich nicht "gemeldet" hat.

Damit "verliert" man auch nichts wirklich, denn die Verbindung kann aus dieser Richtung (also in Richtung des Peers mit der nicht-öffentlichen IPv4-Adresse) ja ohnehin nicht aufgebaut werden. Ach so - 0x2027 bedeutet nebenbei bemerkt "timeout" (https://fritzhelp.avm.de/help/de/FRITZ-Box-6690-Cable/avm/024p1/hilfe_syslog_122) und solange sich an der Firmware der beteiligten Boxen nichts geändert hat (irgendwelche Versionen für Fiber-Boxen hat AVM wohl derzeit zerwürgt), antwortet wohl die Gegenstelle nicht, was i.d.R. daran liegt, daß sie die Pakete gar nicht erst erreichen oder dort als "vom falschen Absender" angesehen und (oft kommentarlos, wobei ein Blick ins VPN-Protokoll da eben Klarheit schafft) verworfen werden.

Das ist aber hier ALLES wirklich lang und breit ausdiskutiert - und VOR irgendwelchen Aktionen sollte man vermutlich erst mal in die (frisch erstellten) Supportdaten schauen (lassen). Daß das Ganze nur dann sinnvoll zu konfigurieren ist, wenn man auf BEIDE Boxen zugreifen kann (auf die mit der öffentlichen IP per Fernzugriff auf das GUI und auf die andere halt direkt, solange keine VPN-Verbindung etabliert werden kann), versteht sich aber hoffentlich von selbst.

VPN war aber noch nie etwas, was sich "per (allgemeingültigem) Rezept" einrichten ließ - erst recht nicht bei doch sehr speziellen Umständen wie hier. Also erwarte auch keine "step by step"-Anleitungen, die das auch jemandem ermöglichen, der sich damit nicht wenigstens etwas auskennt bzw. bereit ist, sich damit (eingehender) zu befassen. So jemand muß dann eben Verzicht üben oder sich andere Wege suchen …

Und wenn es dann "plötzlich" irgendwann doch wieder funktioniert (Deiner Ergänzung zufolge), ist das in aller Regel ein Zeichen dafür, daß die Verbindung jetzt wieder von der "richtigen" Seite aus aufgebaut wurde - das hängt dann allerdings auch künftig weiterhin vom Zufall ab, solange man die Rollen der Peers in der Verbindung nicht explizit festschreibt.

 

[Cheater]

Hallo PeterPawn,
vielen Dank für deine ausführliche Antwort.

Mittlerweile funktioniert wieder alles. Mein Provider hatte tatsächlich ohne Information an die Kunden auf CGNAT umgestellt. Nach einem Anruf beim Support hatte ich nach 15 Minuten wieder eine öffentliche IP.

Wieso dann aber die beiden Fritz!Boxen mit Glasfaseranschluss trotzdem noch ein VPN zustande gebracht haben trotz nicht öffentlicher IP ist mir ein Rätsel.

Jedenfalls funktioniert alles wieder.

Vielen Dank an alle, die mir hier Tipps gegeben haben.