[Problem] Wireguard bleibt down mit FW7.56 bei DSL Unterbrechnung

[Radio2]

Beteiligt ist eine FB 7590 (DSL) und eine FB 6690 (Cable) jeweils mit FW 7.56. Zwischen beiden besteht eine Site-2-Site Verbindung mit Wireguard über myFritz Adressen. Funktioniert gut. Wird auf der Seite der 7590 aber das DSL Unterbrochen, was manchmal passieren kann (Arcor) wird die Wireguard Verbindung nach der Wiederherstellung der DSL und Internetverbindung nicht richtig aufgebaut. Der Status in der VPN Übersicht bleibt grau, kein Ping möglich. Das Logfile sagt aber das nach dem herstellen der DSL Verbindung und Internet Online Einwahl die Wireguard Verbindung wieder ok ist. Erst wenn ich die Verbindung in 7590 inaktiv setze und wieder reaktiviere wird sie grün und die Gegenseite ist wieder erreichbar. Alternativ hilft auch ein Neustart der Box.

Für mich scheint es so zu sein, das Wireguard nicht wirklich erkennt ob das Trägermedium bereits komplett funktioniert und dann irgendwie voreilig ins blaue schießt ohne irgendwelche Checks zu machen. Eine DeadPeerDetection scheint nicht zu existieren. Beim letzten mal habe ich 5h abgewartet aber die Verbindung blieb grau. Hat jemand ähnlich Beobachtungen machen können oder geht das bei euch problemlos? Da wir bei Vodafone DSL keine Zwangstrennung mehr haben fällt das immer nur dann auf wenn die Leitung aufgrund Bastelarbeiten seitens Vodafone mal down geht.

 

[frank_m24]

Hat die 6660 Cable eine öffentliche IP Adresse für die VPN Verbindung? Sonst liegt das Problem eher auf der Cable und weniger auf der DSL Seite. Es ist ein bekanntes Problem bei Wireguard, dass die Tunnel erneuert werden müssen, wenn sich auf einer Seite die IP ändert.

 

[Radio2]

Das ist Cable Business mit fester IPv4. MyFritz ist aktiv.
Das liegt meiner Meinung nach aber nicht an der 6690 weil ich ja zum wiederherstellen der Verbindung ausschließlich an der 7590 arbeite und die 6690 überhaupt nicht anfasse.

 

[frank_m24]

Jain.

Richtig ist, dass die Fritzbox nach der Trennung offenbar die Verbindung nicht neu initiiert. Das ist im Wireguard Protokoll aber eigentlich auch nicht vorgesehen. Sobald Daten für die gleiche Verbindung von einer neuen IP ankommen, aktualisiert ein Wireguard Knoten die Informationen lokal und kann wieder mit der Gegenstelle kommunizieren. Genau das macht die Kabelbox offenbar nicht.

Jetzt kannst du diskutieren: Liegt der Fehler in der DSL Box, weil sie die Verbindung nicht neu initiiert? Oder liegt der Fehler in der Kabelbox, weil sie die IP nicht aktualisiert, wenn sie das erste Paket nach der Trennung von der DSL Box erhält? Ich überlasse dir die Wahl, aber die DSL Box verhält sich gemäß des Wireguard Protokolls korrekt. Wobei es nach einer Trennung der Kabelverbindung mit neuer IP prinzipiell genau so ausgehen könnte - mit umgekehrten Vorzeichen. Könnte ein Problem in der AVM Implementierung sein. Wobei ich davon noch nie gelesen habe. Wir sollten das im Auge behalten. Zwangstrennungen an DSL Anschlüssen gibt es ja noch öfter. Vielleicht ist da auch jemand dabei, der eine Wireguard Verbindung betreibt. Der müsste ja sehr schnell auf das gleiche Problem treffen.

 

[erik]

Bei einer einseitig initiierten Verbindung (wenn die Box, die die Verbindung aufbaut, selber keine öffentlich erreichbare IP bekommt) war es zuletzt immer noch so, dass die Verbindung bei Wechsel der IP der Gegenstelle inaktiv blieb. Da ich für Wireguard u.a. deshalb openWRT-Clients verwende kann ich berichten, dass es dort ein Script gibt, welches die Verbindung überwacht und die erneute Namensauflösung im Fehlerfall veranlasst, weil diese Funktion im Wireguard-Protokoll nicht vorgesehen ist. AVM hat eine solche Überwachung der Verbindung offenbar nicht eingebaut.

Hat denn die Box auf der DSL-Seite eine erreichbare IP? Im Zweifel könnte man die Verbindung auch komplett auf IPv6 umstellen (nur die Verbindung, im Tunnel spricht AVM trotzdem nur IPv4), dazu müsste man aber einen anderen Dyndns-Provider als myfritz verwenden, damit eine ggf. auch nur auf einer Seite vorhandene IPv4 gar nicht erst aufgelöst wird.

 

[Radio2]

Noch einmal:
Auf der Seite der Kabel Box existiert ein Business Anschluss mit statischer public IPv4. Kein Carrier Nat Grande oder DSlite wie bei privaten Anschlüssen.
Auf Seite der DSL Box ist normales dynamisches IPv4 von Arcor/Vodafone.
Beide Boxen sind bei myFritz registriert da dies durch den Wizzard bei Site-2-Site Kopplung benutzt wird. Die Verbindung wird über die myFritz Adressen hergestellt.
Die Kabelbox ist durchgängig unter ihrer IPv4 erreichbar wenn das DSL auf der anderen Seite mal kurz down geht. Die Wireguards Verbindung kann bei Site-2-Site von beiden Seiten aufgebaut werden. Es ist keine einseitige Client Einwahl. Auf der DSL Seite gibt es kein IPv6 (Arcor/Vodafone). Das gibt es nur auf der Kabel-Seite (Vodafone).
Es gab bei der DSL Seite eine Änderung der public IP bei Neueinwahl von 92.216.x.x auf 94.222.x.x
Abhilfe würde ein Ping Generator in der GUI der FritzBox sein, die bei nicht-Erreichbarkeit der Gegenseite das betroffene Interfache kurz down nimmt. Sowas gibt es bei Funkwerk/Bintec im Router. Das für den Fall, das Wireguard an dieser Stelle tatsächlich nicht klar kommt. Offenbar 'merkt' Wireguard in der Fritzbox nicht, das sich irgendwo etwas geändert hat und hält intern an seiner alten, nun nicht mehr gültigen, IP fest. Vermutlich würde das Problem nicht mehr auftreten wenn auf der DSL Seite auch eine statische IPv4 existieren würde.

 

[erik]

Dann kann ich mich nur @frank_m24 anschließen.

 

[Master SaMMy]

Das isst doch schon lange bekannt, dass der AVM-DSLD nicht startet

[Problem] - Nach Update auf FOS 7.50 startet der AVM-DSLD nicht und ein root-login per telnet ist nicht möglich

Hallo liebes Forum, ich habe nun meine FritzBox 7590ax von FOS 07.31 rev94867 mit Freetz ng-21399-c60751263 auf das nagelneue FOS 07.50 rev104313 mit Freetz ng-21444-c555c980a per Freetz-WebIf geupdatet. Nach dem Update und dem automatischen Neustart der Box startet der AVM-DSLD nicht. Es...

www.ip-phone-forum.de

 

[erik]

Hier geht es nicht um Freetz sondern um die Firmware 7.56, wo Wireguard enthalten ist. Der dsld startet dort.

 

[Master SaMMy]

auf der 5590 config laden wird keine verbindung wieder aufgebau Ohne freetz.

 

[Radio2]

@Master SaMMy was hat das jetzt mit meinem Problem zu tun? Bei mir geht ja nur DSL seitens des Providers down, dan kommt ein neuer Sync, DSL ist wieder da und Internet geht. FunFact: eine weitere VPN Verbindung via IPsec, die auch noch in der Box konfiguriert ist, geht ganz brav wieder Online. Die Box ist auch nicht irgendwie modifiziert, ganz normale Firmware. Oder habe ich in dem von Dir erwähnten Thread etwas übersehen?

Ich will ja erst mal Fakten sammeln ehe ich das 'Problem' bei AVM melde.

 

[Master SaMMy]

Bei mir nicht da er den treiber nicht mehr richt läd

-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney

Aber ich werde Wireguard so auch nicht mehr in der FB nutzen denn Die Telefoni geht nur noch rein aber nicht raus so rum sorry

 

[frank_m24]

Ich will ja erst mal Fakten sammeln ehe ich das 'Problem' bei AVM melde.

Das Problem ist im Grunde das, was alle anderen Wireguard Installationen mit dynamischen IPs auch haben, und das nicht von Wireguard selbst, sondern immer durch externe Zusatzscripte gelöst wird. Aber ja, AVM kann im Zweifel was dagegen tun, als Workaround.

 

[Radio2]

Heute Nacht gegen 3Uhr gab es wieder eine Unterbrechung im DSL. Ob das jetzt eine Zwangstrennung war oder an dem heftigen Gewitter lag, was zu der Zeit tobte, kann ich nicht sagen. Ich habe jedenfalls fürs Internet dauerhaft halten an und den Haken bei der Zwangstrennung raus. Der Witz an der Sache ist , dass diesmal die Wireguard Verbindung wieder aufgebaut wurde als DSL und Internet wieder da waren. Es ist also nicht so, das dieses Problem genau an einem Vorgang festzumachen ist sondern da noch andere Umstände rein spielen müssen, die nicht im Log der Box zu sehen sind. Auch diesmal habe ich wieder eine ganz andere IP bekommen als sich die Box wieder eingewählt hat. Der einzige Unterschied liegt an einem Neustart gestern Abend als mir der Stromstecker rausgeflutscht ist als ich nach der Produktnummer für das Ticket gesucht habe. Vielleicht tritt dieses Problem erst nach einer gewissen Betriebszeit auf (hängender Daemon/Task?)

Ich habe das mal als Ticket aufgemacht. Mal sehen, was da kommt. Ich beobachte das ganze weiter. Ich sehe an meinem Telefon sehr schnell wenn die außen liegende Nebenstelle nicht erreichbar ist. Dann weiß ich sofort das die Wireguard Verbindung down ist. Ich muss also nicht ständig in die FB rein sehen.

 

[KunterBunter]

Heute Nacht gegen 3Uhr gab es wieder eine Unterbrechung im DSL. Ob das jetzt eine Zwangstrennung war oder an dem heftigen Gewitter lag, was zu der Zeit tobte, kann ich nicht sagen.

Bei einer Zwangstrennung gibt es keine Unterbrechung bei der DSL, das ist nur eine Trennung der PPPoE-Verbindung.

 

[Peter_Lehmann]

Hallo!

Wie ich hier schon mehrfach gepostet habe, kann und will ich hier nichts zur "AVM-Variante" von WireGuard sagen, weil ich meine ggw. 9 WireGuard-Knoten bewusst auf mit OpenWrt geflashten externen Geräten (FB 4040 und 7412) betreibe. Also "Original-WireGuard" benutze.

Aber trotzdem einige Gedanken zu diesem Problem mit dem Wechsel einer IP:
Es ist eine Tatsache, dass sich bei Trennung des "Träger-Kanals" und Änderung der beiden IP der Tunnel mitunter nicht sofort wieder aufbauen kann. Allein schon geschuldet der Tatsache, dass auch der DDNS-Anbieter einige Sekunden benötigt, bis er die aktuelle IP erhält und diese dann veröffentlicht und die Geräte gezielt danach suchen.

Ich habe das Problem dahin gehend gelöst, dass ich die Zeiten der sinnfreien Zwangstrennung bewusst gestaffelt habe. Also von 02:00 bis 05:00 gleichmäßig verteilt. Es kommt also in meinem WG-Netz nie vor, dass beide Endpunkte zeitgleich eine neue IP zugeteilt bekommen. Eine der beiden (bzw., da überall IPv6 und das uralte IPv4 genutzt werden: eine der vier IP) ist also zumindest einem der Endpunkte bekannt. Und es sieht so aus, dass eine bekannte IP (der Gegenstelle) bereits ausreicht, um den Tunnel wieder aufzubauen und der Gegenstelle auch seine eigene geänderte IP mitzuteilen. Auch im GUI der beteiligten Geräte ist das sehr gut zu erkennen, dass überall die aktuellen IP verwendet werden.
Und dann nutze ich auch bewusst auf jedem der WG-Endpunkte (und auch DSL-Router) einen eigenen DDNS-Client und nicht den des Internet-Routers. Der von mir favorisierte DDNS-Provider dynv6.com ist bekannt dafür, dass er sehr zügig eine neu erhaltene IP verteilt (bei mir natürlich je eine aus beiden Protokollen).

Ergebnis:
Die von mir betriebene "Dauerüberwachung" meines WireGuard-Netzes zeigt mir deutlich an, welche der Internetverbindungen (in Deutschland und Ungarn: DSL, in Dänemark selbstverständlich GB-FTTH) gerade mal eine Zwangstrennung und eine andere IP verpasst bekam. Aber selbst bei uns in "Schland" steht der Tunnel nach wenigen Sekunden wieder - zumal das in der Nacht außer meinem Überwachungstool niemand bemerkt.
BTW: Und das ganze seit Mitte 2019 …

Noch einen Satz zu den bekannten Problemen mit einer geänderten IP:
Wie ich schon geschrieben habe, hat dieses Problem so gut wie keine Auswirkungen bei einem VPN zwischen zwei aktiven WireGuard-Endpunkten (LAN-to-LAN, oder wie auch immer genannt), also zwei Geräten unter OpenWrt.
Das Problem, dass eine bestehende Verbindung nicht mehr automatisch aufgebaut wird, tritt bei mir nur auf, wenn wir bei einem der (mittlerweile ca. 50) an den jeweiligen Endpunkten angeschlossenen "aushäusig" betriebenen Clients (Laptops und Smartphones o.ä.) den Tunnel dauerhaft betreiben.
(JA, da ich unterwegs im "Städtchen" fast überall Freifunk habe, oder auch mal im Zug fahre oder sonst irgendwo ein ungesichertes WLAN benutze, habe ich den WG-Tunnel dauerhaft aktiv - selbst zu Hause.)
Auf unseren Linux-Rechnern habe ich ein (selbstgeschriebenes) Script als Dienst zu laufen, welche aller 10 Sekunden die aktuelle per DDNS verbreitete IP der WireGuard-Gegenstelle mit der letzten bekannten vergleicht und bei einer Abweichung sofort den WG-Dienst neu startet. Meist bemerke ich auch davon überhaupt nichts!
Auf den Androiden funktioniert das allerdings nicht so geschmeidig, weil ich keine Lösung habe, dort ein entsprechendes Script zu implementieren. Nun, den Tunnel in der WG-App einmal aus/ein, ist auch akzeptabel, zumal ja mittlerweile selbst mein Provider die IP nicht mehr sinnlos jede Nacht ändert.

vy 73 de Peter

 

[Radio2]

Danke Peter für deine Ausführungen. Hilft mir bei meinem Problem aber nicht wirklich weiter. Das Problem liegt offenbar bei AVM und deren Implementierung. Wenn die FB wieder DSL hat und Online kommt, wird die myFritz Adresse sehr schnell aktualisiert. Das nützt aber nichts weil die nicht neu abgefragt wird sondern in diesem Fall einfach die alte IP weiter verwendet wird. Das kann natürlich nicht klappen. Erst bei einem Interface down/up oder Reboot bekommt Wireguard die in der FB die Änderung mit, prüft die Adresse und baut neu auf. Aber auch das nicht immer, denn wie gesagt hatte ich heute Nacht den Fall, das die Verbindung nach einem Abbruch von selbst wieder hoch kam. Wenn sie nicht von alleine hochkommt hilft auch kein warten. Anpingen der Gegenstelle bringt auch nichts.

Leider komme ich auf der Gegenstelle nur auf die FB selber drauf. Ich würde gerne von der Gegenstelle mal einen Ping machen um zu sehen ob das hilft. Wobei dort ein IP Phone steht, was mit unserer TK kommuniziert und eigentlich reichen sollte um Traffic in unsere Richtung zu machen um dann die Verbindung anzustupsen.

Ich vermute, das nach längeren Laufzeit der 7590 der Prüf-Mechanismus von der Wiregard Implementation irgenwann nicht mehr richtig läuft und sich dann die Verbindung fest frisst. Irgendwas in der Art. Ich werde das weiter beobachten.

 

[frank_m24]

Auf unseren Linux-Rechnern habe ich ein (selbstgeschriebenes) Script als Dienst zu laufen, welche aller 10 Sekunden die aktuelle per DDNS verbreitete IP der WireGuard-Gegenstelle mit der letzten bekannten vergleicht und bei einer Abweichung sofort den WG-Dienst neu startet.

Genau dieses Script fehlt den Fritzboxen.

Anpingen der Gegenstelle bringt auch nichts.

Von wo nach wo hast du da gepingt? Ich könnte mir vorstellen, dass ein Ping von der DSL Seite zur Kabelseite dazu führt, dass die Kabel-Box die IP ihres Kommunikationspartners aktualisiert. Ich könnte mir aber vorstellen, dass das zügig nach dem IP-Wechsel stattfinden muss. Vielleicht hilft ein Dauer-Ping mit einem Intervall von 10 Sekunden.

 

[Peter_Lehmann]

Hallo @Radio2!

Selbstverständlich war mir völlig klar, dass dir das bei deinem Problem nicht unmittelbar weiter hilft. Ich wollte nur klarmachen, was das originale WireGuard kann, und wo eben die Grenzen des "AVM-Nachbaus" liegen.

Ich kann auch sehr gut verstehen, dass selbst bei sehr viel gutem Willen seitens AVM es niemals gelingen wird,

• auf den begrenzten Ressourcen eines Gerätes, welches vorrangig ein Internet-Router ist
• und vor allem auch mit den begrenzten Ressourcen von "Otto-Normal-User" hinsichtlich der sachgerechten Konfiguration eines VPN-Gateways

eine vollständige Implementation des originalen WireGuard mit allen Einstellmöglichkeiten vorzunehmen.

Selbst ich, der sich schließlich beruflich etliche Jahre mit der Konfiguration eines riesigen (IPsec-)Netzes befasst hat, saß einige Tage, bis ich sämtliche IPs (alles im Dualstack!) für die internen Tunnelendpunkte, aller zu erreichenden Netze, alle DynDNS-Namen, alle zu verwendenden Schlüsselpaare + PSK, das Routing usw. auf meinem Zettel hatte. Das kann man von ONU einfach nicht erwarten.
IMHO ist es eine tolle Gratwanderung, was da AVM hingelegt hat, dass immerhin ein VPN ohne große Vorkenntnisse eingerichtet werden kann. Und es ist auch völlig klar, dass es hier einfach Abstriche geben muss.
(Dass ich für kommerzielle Anwendungen ein VPN niemals auf einem Internetrouter installieren würde, erwähne ich nur am Rande.)

@frank_m24:
Ich habe auf meinen WireGuard-"Servern" dieses, mir wohlbekannte Script nicht aktiviert.
So, wie ich beschrieben habe, scheint es, dass der Endpunkt mit der noch nicht geänderten IP (wo also die Zwangsabtrennung später erfolgt) sofort von dem Endpunkt mit der geänderten IP über seine ihm ja noch bekannte IP wieder angesprochen wird, sobald dieser wieder seine Internetverbindung hat. Und WG baut ja den Tunnel blitzschnell (~1 Sekunde) auf. Und ebenso schnell überträgt er seine (neue) IP wieder an den anderen Endpunkt. Und dieser hat selbige dann, wenn seine Zwangstrennung mit evtl. neuer IP stattfindet. Diese IP der Gegenstelle wird ja auch sofort wieder im GUI angezeigt.
Meinen eigenen "Nachbau" dieses Scriptes (*) nutze ich nur, wenn sich ein reiner Client mit dem WG-"Server" verbinden soll. Der Client hat ja keinen eigenen DDNS-Namen, ist also selbst nicht initial erreichbar, und muss die Verbindung zum "Server" immer zuerst herstellen. Und dazu muss er, falls diese Verbindung eine andere IP hat, sich diese IP beschaffen und die Verbindung neu aufbauen. Also, genau so, wie beim allerersten Verbinden. Und all das starte ich mit meinem Script.
(*)Irgendeine für die Namensauflösung benötigte Funktion hatte ich nicht zur Verfügung. Musste es deshalb etwas anders machen. Und wollte auch keinesfalls eine Datei mit der gespeicherten IP anlegen, wegen der unnützen Schreibzugriffe.

Aber (unabhängig vom eigentlichen Thema), am meisten begeistert mich, wie blitzschnell WireGuard den Tunnel beim mehrfachen Wechsel des "Trägerkanals" aufbaut.
Mehrfach getestet: Ich telefoniere aus dem heimischen WLAN mit der AVM-Fone-App mit jemand über "Festnetz". Vor dem Haus wird automatisch die Verbindung auf Mobilfunk umgeschaltet. 10 Minuten später im "Städtchen" wo ich sofort im Freifunk-Netz eingebucht bin. Und im Büro (wo der Rentner den ehrenamtl. Admin gibt) bin ich dann wieder im gesicherten Büronetz. Und: mein Gesprächspartner - mein Sohn - bestätigt mir eine dauerhafte Verbindung ohne Abbrüche! Welches andere VPN kann das bieten?


vy 73 de Peter