WireGuard VPN Fritzbox und iOS

[swcomputer]

Hallo,

Ich habe eine erfolgreiche Verbindung zwischen der Fritzbox mit WireGuard und iOS. Der Tunnel wird immer offen gehalten. Allerdings habe ich jede Nacht das Problem, dass die Verbindung verloren geht. Die Zeit des letzten Handshakes zählt immer weiter nach oben. Sobald man den Tunnel kurz deaktiviert und aktiviert geht es wieder.

Habt ihr eine Idee wie man das behandeln kann?

Gruß
Steve

 

[Peter_Lehmann]

Hallo Steve,

Beglückt dich dein Internetprovider mit der (IMHO sinnfreien) täglichen Zwangstrennung?
Bei einer reinen Clientverbindung zum WireGuard-Server startet die Verbindung nach dem IP-Wechsel nicht automatisch neu.
Ja, es gibt Lösungen...

vy 73 de Peter

 

[B612]

Bei einer reinen Clientverbindung zum WireGuard-Server startet die Verbindung nach dem IP-Wechsel nicht automatisch neu.

Wie sieht das bei einer Verbindung von FB zu FB aus? Bei IPsec geht das.

 

[kleinkariert]

War das nicht eine der hervorragenden Eigenschaften von Wireguard, verbunden zu bleiben, selbst "wenn das Internet aus ist".

 

[swcomputer]

Das mit der Zwangstrennung weiß ich ehrlich gesagt gar nicht. Ich bin bei 1&1 und habe in der Fritzbox die automatische Trennung aktiv. Kann ich die abschalten?

FB zu FB mit IPsec funktioniert, das habe ich schon lange aktiv.

Laut Google scheint der Wireguard Client nur initial DNS / IP aufzulösen. Ändert sich diese, geht die Verbindung verloren

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat gemäß Boardregeln entfernt by stoney

Du schreibst es gibt Lösungen
Welche gibt es dabei? Ich habe schon geschaut ob man am iPhone automatisch die VPN Verbindung resetten kann, aber das scheint nicht so einfach möglich zu sein

 

[B612]

scheint der Wireguard Client nur initial DNS / IP aufzulösen.

Dann liegt es ja aber nicht an der FB.

 

[frank_m24]

Ist PersistentKeepalive gesetzt?

 

[Peter_Lehmann]

Ich muss an dieser Stelle einschränkend sagen, dass ich zwar schon mehrere Jahre Erfahrung mit meinem schon recht großen WireGuard-Netz habe, ich aber immer externe Geräte (mit OpenWrt geflashte FB 4040 und 7412) als reine WG- Server (*) betreibe. Ich weiß also nicht, was das "AVM-WireGuard" so kann.
(*) Der Begriff "Server" ist nicht ganz korrekt. Ich benutze ihn aber für die genutzten aktiven Geräte zum Unterscheiden zu den externen Clients wie Notebooks und Smartphones.

Meine 8 WG-Server finden sich nach der (bei unserem Provider 1&1 leider immer noch durchgeführten) täglichen Zwangstrennung sofort wieder, da die Zwangstrennung nie gleichzeitig bei beiden Endpunkten erfolgt. Der eine betreffende Tunnel ist also immer nur wenige Sekunden down - ich selbst habe das noch nie bemerkt. Ich gehe davon aus, dass "in der Gegenrichtung", wo der Tunnel ja noch steht, die IP der anderen Gegenstelle übertragen wird. Meine Netzwerküberwachung (NAGIOS) zeigt über mehrere Monate keinerlei Ausfall des VPN.

> Ist PersistentKeepalive gesetzt?
Damit wird lediglich in einem festzulegenden Zeitabstand eine ganz kurze Datenübertragung angestoßen. Das bringt aber nichts, wenn der Tunnel wegen einer geänderten IP nicht mehr steht.

Das Problem mit dem Ausfallen des Tunnels bei Änderung der IP ist auch auf der Webseite (oder Wiki?) von WireGuard beschrieben, falls jemand nachlesen möchte.

> War das nicht eine der hervorragenden Eigenschaften von Wireguard, verbunden zu bleiben, selbst "wenn das Internet aus ist".
Ja, das ist fast so. Aber einen IP-Wechsel des WG-Servers kann man auch mit udp nicht so einfach wegstecken. Das VPN bleibt wirklich verbunden, wenn das Übertragungsnetz für den Tunnel bei laufendem Betrieb (bspw. bei einer Autofahrt vom heimischen WLAN über das Mobilnetz, dann wieder ein WLAN wie Freifunk im Städtchen und dann meinetwegen das WLAN im Büro usw.) ständig gewechselt wird. Solange ein geeignetes Netz vorhanden ist, bricht nicht einmal eine Telefonverbindung mit der heimischen VOIP-Nummer über die FRITZ-APP Fon zusammen.

Noch eine Antwort zum eigentlichen Problem:
Wenn ein reiner Client (Notebook usw.) am WG-Server betrieben wird, dann bricht der Tunnel bei Wechsel der IP des "Servers" zusammen. Die einzige Möglichkeit ist dann der Neustart des Tunnels (WGx).
Heute stört mich das weniger (in der Zeit der Zwangstrennung pflege ich zu schlafen). Aber ich habe es so gelöst, wenn es doch mal einen ungeplanten IP-Wechsel tagsüber geben sollte:
Auf meinen Linux-Rechnern wird aller 5 Sekunden durch einen Chronjob ein kleines Script gestartet, welches die bisherige IP des WG-Servers mit der aktuellen, per DynDNS festgestellten IP vergleicht. Stimmen beide IP nicht überein, erfolgt ein Neustart von WGx. Und schon steht der Tunnel wieder. Der einzige spürbare Zeitabstand kommt durch die Mitteilung der neuen IP durch den DynDNS-Provider, das dauert eben ein paar Sekunden.
Für den Androiden könnte man das mit einer selbst geschriebenen App ähnlich machen (ich favorisiere aber einen händischen Neustart - Aufwand vs. Nutzen). Aber wie es mit einem i-Dingens funktioniert, weiß wohl nur ein Mensch, der dieses Betriebssystem in- und auswändig kennt.

vy 73 de Peter

 

[frank_m24]

> Ist PersistentKeepalive gesetzt?
Damit wird lediglich in einem festzulegenden Zeitabstand eine ganz kurze Datenübertragung angestoßen. Das bringt aber nichts, wenn der Tunnel wegen einer geänderten IP nicht mehr steht.

Es gibt ja in dem Sinne keinen Tunnel bei Wireguard. Das Protokoll arbeitet komplett verbindungslos. Beide Seiten merken sich die letzte bekannte IP-Adresse des Gegenübers und schicken bei Bedarf die Pakete hin. Wenn sich die Adresse auf einer der beiden Seiten ändert, dann kann die jeweils andere Seite diesen Teilnehmer nicht mehr erreichen, da sie die Pakete an eine falsche Adresse schickt. Erst wenn der Teilnehmer, dessen Adresse sich geändert hat, wieder ein Paket an das Gegenüber sendet, ist diesem die neue Adresse wieder bekannt, und die Kommunikation flutscht wieder.
Und hier kommt PersistentKeepalive ins Spiel. Damit kann man einem Teilnehmer mit wechselnder Adresse sagen, dass er sich regelmäßig bei seinem Gegenüber meldet, und so bleibt die Adresse aktuell.

In diesem Fall könnte aber noch eine Besonderheit zutage treten. Wenn das iPhone im WLAN der Wireguard Server Box hängt, dann haben sich durch das Update die Adressen beider Kommunikationspartner gleichzeitig geändert. Solange die Verbindung dauerhaft an bleibt, wird das zum Problem, selbst wenn im iPhone eine dyndns Adresse hinterlegt ist. Denn Wiregaurd arbeitet bei einer aktiven Verbindung immer nur mit den bekannten IP-Adresse und ruft niemals ggf. hinterlegte Hostnamen neu per DNS ab. Für Linux gibt es dafür Scripte, fürs iPhone vermutlich keine Lösung - außer Neustart der VPN Verbindung. Dabei wird nämlich ein DNS Resolve gemacht und die Adresse aktualisiert.

Solange das iPhone nicht im WLAN der Server Box hängt, müsste durch ein PersistentKeepalive auf beiden Seiten die Verbindung stabil bleiben.

 

[swcomputer]

Vollzitat gemäß Boardregeln entfernt by stoney

PersistentKeepAlive ist in der App auf 25 Sekunden gesetzt. Befindet sich das iPhone im gleichen WLAN wie der WG Server, ist kein VPN aktiv.

Das Problem tritt auf, wenn ich im Mobilfunknetz bin oder in einem anderen WLAN.

Nach der Zwangstrennung kann man in der App erkennen, dass die Zeit des letzten Handshakes immer größer wird und keine Verbindung mehr besteht

Update: das KeepAlive müsste an der Fritzbox gesetzt sein, um das Handy wieder zu erreichen, oder?
Kann man das konfigurieren?

 

[frank_m24]

Update: das KeepAlive müsste an der Fritzbox gesetzt sein, um das Handy wieder zu erreichen, oder?

Es muss in deinem Fall auf beiden Seiten aktiv sein. Die Adresse des Handys kann sich ja auch durchaus mal ändern, z.B. beim Wechsel WLAN -> Mobilfunk.

Kann man das konfigurieren?

Grundsätzlich schon. Ob man auf Fritzboxen an den Parameter kommt, weiß ich allerdings nicht.

 

[Peter_Lehmann]

Es gibt ja in dem Sinne keinen Tunnel bei Wireguard. Das Protokoll arbeitet komplett verbindungslos.

Hallo Frank,

ja, klar verwendet WireGuard das verbindungslose UDP. Ich habe ja in meinem Betrag sogar darauf hingewiesen.
Und es stimmt auch, dass es hier keine Tunnel im herkömmlichen Sinn gibt, wo sich auch jeder (selbst ein Laie) etwas darunter vorstellen kann. Aber wie wollen wir dann das "Konstrukt" nennen, worin die Daten fließen? Ich werde es aus puren Gründen der Verständlichkeit weiterhin "Tunnel" nennen. Maximal "UDP-Tunnel".

Deine Erklärung bezüglich des KeepAlive ist schlüssig. Nur leider habe ich bei meinen wirklich vielen Tests mit unterschiedlichen Zeiten und Orten (also am "Server" und/oder am "Client" - Notebook u.a.) keinen Erfolg damit gehabt, dass sich der Client nach Wechsel der IP des Servers wieder automatisch verbindet. Wie schon geschrieben, funktioniert das perfekt zwischen zwei "WG-Servern" (*). Genau deswegen habe ich bewusst bei den betreffenden 8 Routern meines Netzes den Zeitpunkt für die Zwangstrennung unterschiedlich eingestellt. Aber wenn ich auf einem Notebook bewusst das VPN durchlaufend lasse und WGx den ganzen Tag nicht kurz deaktiviere, erfolgt kein erneuter Verbindungsaufbau. Egal, was in den Konfigurationen für KeepAlive eingestellt ist.
Nicht umsonst ist dieses Problem in der Originaldokumentation von WireGuard deutlich erwähnt worden, einschließlich eines Beispiels für ein Script zum Vergleich der IP aller x Sekunden und dem Neustart der Schnittstelle (welches ich für mich etwas verändert habe).

Und in der GUI eines WG-Servers unter OpenWrt ist auch zu lesen:
Persistentes Keep-Alive:
Optional. Sekunden zwischen Keep-Alive-Nachrichten. Standardwert ist 0 (deaktiviert). Der empfohlene Wert für Geräte hinter einem NAT sind 25 Sekunden.

(*)
Als vor ein paar Tagen der von mir präferierte DynDNS-Anbieter dynv6.com 2 oder 3 Tage down war, habe ich (meine Überwachung mit Nagios) das überhaupt nicht mitbekommen. Meine "Tunnel" standen trotz Zwangstrennung und wirklich geänderter IP absolut stabil. Die im DDNS-GUI angezeigte IP stimmte weder für das alte IPv4 noch für IPv6 mit der tatsächlichen IP überein. Trotzdem haben sich die Endpunkte immer wieder gefunden, sodass es zu keiner Unterbrechung kam. Nur keiner der vielen außerhäusig betriebenen Clients konnte eine Verbindung aufbauen ...

vy 73 de Peter

 

[frank_m24]

Nur leider habe ich bei meinen wirklich vielen Tests mit unterschiedlichen Zeiten und Orten (also am "Server" und/oder am "Client" - Notebook u.a.) keinen Erfolg damit gehabt, dass sich der Client nach Wechsel der IP des Servers wieder automatisch verbindet.

Das ist schon merkwürdig. Im Grunde gibt es ja bei Wireguard keinen "Server" und keinen "Client" mehr. Zwei Teilnehmer kommunizieren gleichberechtigt miteinander. Wenn der eine Daten für den anderen hat, schickt er sie rüber. Von daher ist es aus Sicht des Protokolls egal, ob der "Server" oder der "Client" die IP wechselt. Der Ablauf ist der gleiche. Deshalb dürfte es auch keine Rolle spielen, ob du den Versuch vom Notebook aus machst, oder ob es zwei "Server" sind, die eine Zwangstrennung hinter sich haben.

Was richtig ist: Wireguard macht keinen erneuten DNS Lookup in einer laufenden Session. Die Infos über die aktuelle IP des Gegenübers holt sich Wireguad ausschließlich aus der eigenen Kommunikation mit dem Gegenüber. Deshalb kann ich mir schon vorstellen, dass du den dynv6 Ausfall nicht mitbekommen hast. Wenn es genug Traffic zwischen den einzelnen Knoten gibt, dann bleiben die IPs darüber aktuell.

 

[erik]

KeepAlive nützt in Richtung Mobilfunk nichts, weil ein Server, der mit geänderter IP-Adresse KeepAlive-Pakete sendet, nicht zum Client durchkommt. Das wird von CG-NAT oder bei IPv6 von der Firewall des Providers geblockt. Und der Client seinerseits sendet an eine alte, falsche IP.
Die openWRT-Impementation von Wireguard enthält deshalb dazu ein fertiges Script, welches man als Cronjob aufrufen kann. Das Script veranlasst einen erneuten DNS Lookup, wenn die letzte Verbindung länger als z.B. eine Minute her ist.
Für Handys und andere mobile Endgeräte gibt es leider noch keine Lösung außer manuellem Neuverbinden.

 

[Peter_Lehmann]

Die openWRT-Impementation von Wireguard enthält deshalb dazu ein fertiges Script, welches man als Cronjob aufrufen kann. Das Script veranlasst einen erneuten DNS Lookup, wenn die letzte Verbindung länger als z.B. eine Minute her ist.

Danke, dass du das auch so siehst. Ich habe mein Script in einigen Kleinigkeiten verändert, weil ich z. Bsp. das Schreiben in eine Datei nicht haben wollte. Damals lief der erste WireGuard-<wie wir ihn auch immer nennen wollen> auf einem RasPi und ich versuche eben alle unnützen Schreibvorgänge zu vermeiden.

@frank_m24
Eigentlich schreiben wir beide nichts Gegensätzliches.
Fakt ist, wie auch bei Linux-Maschinen nicht unüblich, sind mehrmonatige stabile Verbindungen nichts Ungewöhnliches. Und wenn selbst der Ausfall des DynDNS-Dienstes von mir nicht bemerkt wird (mich rief erst ein Nutzer an), kann ich doch sehr zufrieden sein.

 

[erik]

das Schreiben in eine Datei nicht haben wollte

Ich habe den Log-Level in openWRT aufs m.M.n. niedrigste Level gestellt, um Schreibvorgänge zu minimieren. Außerdem hat jedes WG-Gerät einen weitgehend vorkonfigurierten Zwilling im Schrank liegen.

Um aber zum Thema zu kommen: Beim Fritzbox-Wireguard wissen wir noch nicht, was alles möglich sein wird. Ein spezielles Script für diesen Fall wird es aber wahrscheinlich nicht geben, weil das bei Standardanwendung der Box an entfernten DSL-Anschlüssen nicht nötig ist, wie du ja schon geschrieben hast. Und im speziellen Fall einer Mobilfunkverbindung am Handy gibt es noch gar keine Lösung.

 

[swcomputer]

Hallo zusammen,
danke für eure zahlreichen und ausführlichen Rückmeldungen.

Ich habe ggf. noch eine brauchbare Lösung für mobil gefunden. Es gibt eine VPN App „Passepartout“. Diese gibt es mit Testflight in einer Beta Version, die Wireguard unterstützt.
Man kann den Tunnel so konfigurieren, dass dieser im Standby des Handys deaktiviert wird. Somit wird der Tunnel beiReaktivierung des Handys neu aufgebaut und die DNS / IP Abfrage neu gestartet. Ich werde das mal testen.

Gruß
Steve

 

[SpecialFighter]

Hallo zusammen,

gerne würde ich hier mein Wissen auch mitteilen.
Habe exakt das selbe Problem, welches ich schon als Ticket an AVM geschickt habe.
Aber wie so oft: Wirklich eine brauchbare Lösung kommt hier von AVM nicht - es läge angeblich an der Wireguard IOS App ... (wie immer sind es die anderen Schuld )

Das Problem tritt auch unter macOS auf.

Allerdings konnte ich dies direkt verneinen.
Habe einen eigenen WG Server laufen und hiermit null Probleme.

Sobald ich die Fritzbox WG Server spielen lasse, habe ich auch die Trennungen, wie oben beschrieben.
Trennen und neu verbinden = Wieder OK

Hier liegt der Fehler ganz klar bei AVM

 

[frank_m24]

Wie oben beschrieben, das Verhalten von Wireguard bei Verbindungstrennungen ist bekannt. Man kann Maßnahmen in Form spezifischer Scripte dagegen ergreifen. Von allein macht Wireguard das nicht, die Foren sind voll davon. Da ist die Fritzbox nicht allein.

 

[SpecialFighter]

warum klappt es denn bei meinem Wireguard Server?
Also ich habe keine Trennung durch die Zwangstrennung, sondern wenn ich die WG Verbindung hergestellt habe, das Handy dann ca. 20 min nicht mehr benutze (Standby) und es dann wieder versuche: App sagt VPN aktiv -> komme aber auf keine Webseiten mehr drauf. Erst nachdem ich in der App trenne und erneut verbinde. Das muss ich nur machen, wenn die FB WG Server spielt.

Bei meinem WG Server (läuft auf meiner Synology) tritt dieses Problem nicht auf.