Wireguard Abbruch nach Provider IP-Wechsel

NOCling

Wie lange ist auf Client Seite die TTL vom DynDNS Eintrag?

Bob.Dig

@orcape Wie gesagt, wenn wäre es ein Problem auf der Client Side, also bei OpenWRT. Den Server interessiert es nicht.
Edit: Gerade mal getestet gegen WG für Android. In der Fritte neu verbunden, dann gewartet bis die entsprechenden E-Mail-Benachrichtungen dazu bei mir eingingen. Davor auf dem Smartphone WiFi aus und WG Client gestartet. Ergebnis, auch nach dem IP-Wechsel und DDNS nach Hause steht die Verbindung.
Was bei mir aber nicht wirklich funktioniert ist der IPv6-Wechsel, damit hat die Sense so ihre Probleme. WG und DDNS laufen bei mir aber über IPv4.

slu

@orcape
es wäre schon mal interessant ein tcpdump laufen zu lassen, wie @Bob-Dig schon schreibt hört sich das nach einem Client Problem an.

Allerdings weiß ich auch nicht was der WG Client macht wenn keine Paket Antwort kommt,
evtl. aller paar Sekunden eine neue FQDN IP Auflösung?
Darüber habe ich mir noch gar keine Gedanken gemacht, ist aber ein guter Punkt.

Wir setzen WG nur auf Smartphones ein, es ist halt super für Roaming (Wifi+LTE) und vor allem für den Akku verbraucht.

Alles was Strom hat bekommt OpenVPN ;)

orcape

@nocling said in Wireguard Abbruch nach Provider IP-Wechsel:

Wie lange ist auf Client Seite die TTL vom DynDNS Eintrag?

Da gibt es keinen TTL-Eintrag dafür, zumindest im GUI des OpenWRT nicht. Nur den KeepAlive und den habe ich auf 5 eingestellt. Wie mir dunkel in Erinnerung ist, hat es mit der TTL auch nur etwas auf sich, wenn das über mehrere Router läuft und das ist hier nicht der Fall.

@bob-dig said in Wireguard Abbruch nach Provider IP-Wechsel:

Edit: Gerade mal getestet gegen WG für Android. In der Fritte neu verbunden, dann gewartet bis die entsprechenden E-Mail-Benachrichtungen dazu bei mir eingingen. Davor auf dem Smartphone WiFi aus und WG Client gestartet. Ergebnis, auch nach dem IP-Wechsel und DDNS nach Hause steht die Verbindung.
Was bei mir aber nicht wirklich funktioniert ist der IPv6-Wechsel, damit hat die Sense so ihre Probleme. WG und DDNS laufen bei mir aber über IPv4.

Ich kenne Dein Netzwerk nicht, aber wenn bei Dir eine Fritzbox im Spiel ist, da läuft Wireguard über den My Fritz-Account. Das solltest Du auch mit meiner Konfiguration keinesfalls vergleichen können. Oder habe ich da was falsch verstanden.
Gruß orcape

Bob.Dig

@orcape Sry, Fritte ist vor der Sense, aber WG ist nur auf der Sense am Laufen, nicht auf der Fritte.

orcape

@slu said in Wireguard Abbruch nach Provider IP-Wechsel:

Allerdings weiß ich auch nicht was der WG Client macht wenn keine Paket Antwort kommt,
evtl. aller paar Sekunden eine neue FQDN IP Auflösung?

Genau das ist das Problem bei Wireguard, gegenüber OpenVPN. Eine FQDN IP Auflösung findet nur beim Start von WG statt. Bricht die Verbindung weg, weil der Server ausfällt, (hier wegen anderer IPv4) findet der Client den Server nicht mehr.
Sprich, man muss WG nach einem Abbruch der Verbindung davon überzeugen, die für Ihn "remote IP" per DynDNS-Eintrag wiederzufinden.
Und genau dafür brauche ich wohl eine Lösung.
Gruß orcape

orcape

@bob-dig said in Wireguard Abbruch nach Provider IP-Wechsel:

Sry, Fritte ist vor der Sense, aber WG ist nur auf der Sense am Laufen, nicht auf der Fritte.

Doppeltes NAT und die Fritte mach DynDNS?

Bob.Dig

@orcape said in Wireguard Abbruch nach Provider IP-Wechsel:

Genau das ist das Problem bei Wireguard, gegenüber OpenVPN. Eine FQDN IP Auflösung findet nur beim Start von WG statt.

Wie gesagt, Du liegst falsch, hab es doch gerade getestet gehabt. WG hat da kein Problem! WG als Server interessiert auch seine Adresse oder DDNS Adresse nicht, warum sollte es auch......

Doppeltes NAT und die Fritte mach DynDNS?

Korrekt, wobei beide machen bei mir DynDNS, wer zuerst kommt, malt zu erst.

slu

@orcape said in Wireguard Abbruch nach Provider IP-Wechsel:

Genau das ist das Problem bei Wireguard, gegenüber OpenVPN. Eine FQDN IP Auflösung findet nur beim Start von WG statt. Bricht die Verbindung weg, weil der Server ausfällt, (hier wegen anderer IPv4) findet der Client den Server nicht mehr.
Sprich, man muss WG nach einem Abbruch der Verbindung davon überzeugen, die für Ihn "remote IP" per DynDNS-Eintrag wiederzufinden.
Und genau dafür brauche ich wohl eine Lösung.

Aber dann wäre doch dein Client das Problem, nicht der Server.

orcape

@slu said in Wireguard Abbruch nach Provider IP-Wechsel:

Aber dann wäre doch dein Client das Problem, nicht der Server.

Der Überzeugung bin ich nun auch. Ich hätte das zu Hause, über einen IP-Wechsel des Providers hinaus, erst einmal länger probieren sollen, bevor ich das remote einbaue.
Hätte mir einiges an Stress erspaart.
Gruß orcape

Bob.Dig

@orcape Also Keep Alive in OpenWRT einrichten, wenn noch nicht geschehen.

Außerdem kannst Du auch WG und OpenVPN simultan benutzen, zumindest für den reinen Zugriff auf die Router. Ich wüsste zumindest nicht, was dagegen spräche.

orcape

@orcape
Es gibt dafür Linux ein schönes Tutorial.
Leider kann man das wohl beim OpenWRT-OS nicht so ohne weiteres anwenden.
Automatically re-resolve DNS in Wireguard
Nicht das mir Linux fremd wäre, aber das geht schon mit "opkg" und dem fehleden "systemd" los.
OpenWRT kommt zwar in meiner Variante schon mit einem 5.4 er Kernel daher, ist aber sonst gegenüber meinem Debian Systemen schon ein wenig "archquiert", so da ich hier wohl erst noch so einiges nachlesen muss, um nicht zu viel Schaden zu machen.
Gruß orcape

orcape

@bob-dig said in Wireguard Abbruch nach Provider IP-Wechsel:

Außerdem kannst Du auch WG und OpenVPN simultan benutzen, zumindest für den reinen Zugriff auf die Router. Ich wüsste zumindest nicht, was dagegen spräche.

Das funktioniert nicht. Die pfSense schreibt in Ihrer Routing Tabelle die remoten Netze nur einmal aus, entweder über das OpenWRT-Netz oder das WG-Netz. Müsste ich vllt. für den OpenVPN-Tunnel noch ein separates Interface, sowie GW und statische Routen setzen. Da wird dann aber das Tohupapohu noch größer.
Nee lass mal, das wäre der falsche Weg, glaube ich.
Also entweder die pfSense verbindet über WG oder OVPN, alles andere wird ein vielleicht oder könnte sein.
Gruß orcape

NOCling

Jeder DNS Eintrag hat einen TTL, die ist z.B. bei meinem Anbieter bei 60 Sekunden, normale ist heute 1-24h, länger nicht mehr, weil zu unflexibel, wenn man mal mit einer Seite umzieht.

Wenn das jetzt 60 Sekunden drin stehen, muss WG im Grunde alle 60 Sekunden den Eintrag erneuern. Damit sollte dann die neu WAN IP vom Server auch nach dieser Zeit wieder bekannt sein.

Wenn das wirklich nur bei Tunnelaufbau passiert, dann ist das nicht gerade optimal umgesetzt.

orcape

@nocling said in Wireguard Abbruch nach Provider IP-Wechsel:

Jeder DNS Eintrag hat einen TTL, die ist z.B. bei meinem Anbieter bei 60 Sekunden, normale ist heute 1-24h, länger nicht mehr, weil zu unflexibel, wenn man mal mit einer Seite umzieht.

Kann gut sein, wie das mit der TTL bei SPDNS aussieht habe ich nicht herausgefunden aber für letzteres bietet man ja Umzugstoken an.

Wenn das wirklich nur bei Tunnelaufbau passiert, dann ist das nicht gerade optimal umgesetzt.

Es kann nur mit dem IP-Wechsel zu tun haben, denn der Abbruch erfolgte zu genau der Zeit.
Ich arbeite gerade an einer Lösung, die man mir im OpenWRT-Forum verlinkt hat.
Wenn das funktioniert werde ich das hier noch posten, denn wie ich im Netz sehe, bin ich wohl nicht der einzige mit dem Problem.
Gruß orcape

JeGr

@orcape said in Wireguard Abbruch nach Provider IP-Wechsel:

Genau das ist das Problem bei Wireguard, gegenüber OpenVPN. Eine FQDN IP Auflösung findet nur beim Start von WG statt. Bricht die Verbindung weg, weil der Server ausfällt, (hier wegen anderer IPv4) findet der Client den Server nicht mehr.

Bitte dringend erst einmal im Grundsatz:

Wireguard kennt keine Interfaces und sendet über die Default Route. Dem ist somit auch die IP auch eigentlich recht egal.
Wireguard hat Peers, es gibt KEIN Client/Server Modell. Jede Seite kann wie bei IPsec Server und Client sein, es kommt drauf an, wer mit wem spricht.
Damit der Tunnel störungsfrei funktioniert, sollte jede Seite auf die andere zugreifen können. Da reicht ein einfaches NATting auch auf der dynamischen Seite, damit man da ordentlich hinkommt.

Das wollte ich mal einwerfen, denn das wird in jeder WG Diskussion immer wieder falsch rübergebracht. Es gibt keinen Server oder Client.

Da Wireguard während des laufenden Tunnels bei IP Change durchaus lustig weiterkommunizieren kann, muss nur eine Seite den Change mitbekommen und macht automatisch den Tunnel auf die neue IP mit. Wenn nicht beide Seiten zum gleichen Zeitpunkt die IP ändern, sollte das eigentlich stabil bleiben da die IP on the fly gewechselt wird. Ich hatte das Phänomen der fluiden IP hier schonmal nachstellen können, wenn bspw. der Tunnel über eine IP aufgebaut wird, WG aber wegen default Route über das andere GW antwortet, dann switcht der Tunnel einfach OTF auf die neue IP um obwohl keine der beiden Instanzen darauf konfiguriert wurde. Daher funktionieren WG Tunnel am Besten wenn beide Seiten sauber miteinander reden können (also Port an beiden Enden erreichbar), denn dann kann bei Ausfall einer Seite die andere ihr die Pakete schicken und das ganze läuft nicht einseitig.

orcape

@jegr
Hi JeGr,
@jegr said in Wireguard Abbruch nach Provider IP-Wechsel:

Bitte dringend erst einmal im Grundsatz:

Wireguard kennt keine Interfaces und sendet über die Default Route. Dem ist somit auch die IP auch eigentlich recht egal.

Wireguard hat Peers, es gibt KEIN Client/Server Modell. Jede Seite kann wie bei IPsec Server und Client sein, es kommt drauf an, wer mit wem spricht.

Damit der Tunnel störungsfrei funktioniert, sollte jede Seite auf die andere zugreifen können. Da reicht ein einfaches NATting auch auf der dynamischen Seite, damit man da ordentlich hinkommt.

zu 1.
Das ist erst einmal grundsätzlich richtig, denn eine Tunnelverbindung auf der pfSense, kommt definitiv auch ohne ein zugewiesenes Interface zustande.
Nur ist Wireguard auf der pfSense wohl nicht umsonst als "Experimental" deklariert.
Denn ohne die Zuweisung eines Interfaces, eines Gateways, der auf die remote Tunnel-IP verweist, sowie die Eintragung von statischen Routen zu den remoten Netzen, werden in der pfSense gar keine Routen angezeigt. Folglich auch keine Verbindung zu diesen Netzen. So viel zum Thema, "Wiregard und keine Interfaces kennen". Grundsätzlich richtig, wenn man das Routing außer acht lässt.
Zum anderen wird bei OpenWRT in den Netzwerkeinstellungen für Wireguard ein neues Interface erstellt, anders funktioniert da Wireguard, zumindest über den GUI gar nicht und auch die Zuordnung der Firewall und das Routing würde nicht funktionieren, aber das nur am Rande. Im Prinzip hast Du ja recht, wenn das Wörtchen "wenn" nicht wäre.
zu 2.
Auch völlig richtig, sprechen wir also von localer- und remoter Seite um das richtig auszudrücken. Man hat auf jeder Seite eine Grundeinstellung und ein Peer, wenn man von P-to-P spricht.
zu 3.
Und hier nun wieder mein Problem.
Fakt ist, mein Tunnel bricht weg, wenn ich die pfense (local) neu starte, respektive würde er das dann auch tun, wenn die IP wechselt.
Neu startet er erst nach einem resett der Remoten Seite.

Ich habe für die 3370 noch ein Backup-Gerät, ebenfalls OpenWRT. Beide habe ich nun mit unterschiedlichen Einstellungen mit Wireguard beglückt und von Stabilität, wie es bei OpenVPN der Fall war, kann hier keine Rede sein. Der Tunnel steht, die Verbindung ist in beide Richtungen gewährleistet, aber ja nachdem, wo ich was neu starte, empfinde ich das eher als "russisches Roulett", wenn ich das vor Ort wieder einbauen soll.
Die LTE-Seite mit Ihrer von öffentlich zu privater IPV4 umgeswitchten Internetanbindung, ist ja vielleicht noch nicht einmal das Problem bei meinem Construct.
Ich tippe mal nun eher auf die Hardware, denn bis die Fritte unter den gegebenen Bedingungen wieder hochfährt, mir WLAN etc. stabil zur Verfügung stellt, vermute ich eher die Grenzwertigkeit der Hardware und das tritt bei beiden Fritten gleich auf.

Nun ja, ein "Lantiq XWAY VRX288 (xRX200) 500MHz" in Verbindung mit "128 MB RAM", stößt wohl hier an seine Grenzen.
4 Port-Switch, aufgeteilt auf 3 verschiedene LAN's, 2 x USB-Interfaces mit MWAN3 Ausfallsicherung, WLAN, OpenVPN und nun noch Wireguard, bringt wohl den nicht mehr soo ganz "taufrischen" Fritzkasten an seine Grenzen.
Denn so zähfließend, wie mir dessen Arbeit erscheint, liege ich wohl mit meiner Vermutung "dicht dran".
Ich habe noch ein APU2C4 mit pfSense und WLAN auf dem Boden liegen, welches wohl als Nachfolger dienen könnte.
Die Fritte war eigentlich auch mal nur als Übergangslösung geplant, da das vorher eingebaute ALIX mit pfSense 2.3.5, die Umstellung von 3G zu LTE nicht mitgespielt hat.
Ein LTE-Stick, sollte aber nun mit pfSense 2.6.0 vom FreeBSD-12.3 Stable, nun doch hoffentlich akzeptiert werden.
Das Projekt wird also verschoben, nicht aufgehoben und ich glaube fast, das APU-Board wird das Problem lösen.
Gruß orcape

JeGr

@orcape said in Wireguard Abbruch nach Provider IP-Wechsel:

Da hast du leider nicht verstanden, was ich geschrieben habe. Dass WG für sich ein Interface erstellt habe ich nicht bestritten. Was ich gesagt habe war, dass sich Wireguard selbst nicht an ein Interface bindet oder darum kümmert, sondern lediglich über die System Routing Table agiert. Darum kann im Gegensatz zu IPsec oder OVPN auch der routing Weg nur eher schlecht konfiguriert werden, da man WG nicht dazu zwingen kann bspw. nur auf einem Interface zu lauschen. Es wird einfach im Kernel komplett auf jeglichen Verkehr gehört und das kann zum Problem werden. Von irgendwelchen Pseudo Devices wie das wg0 oder wg_tun, das man als Wrapper drumrum gebaut hat war hier nicht die Rede ;)
Genau das ist aber für die Funktion der relevante Punkt ;)
Der Punkt aus 2 ist relevant da:

@orcape said in Wireguard Abbruch nach Provider IP-Wechsel:

Fakt ist, mein Tunnel bricht weg, wenn ich die pfense (local) neu starte, respektive würde er das dann auch tun, wenn die IP wechselt

Nein, wenn die IP wechselt - und das konnten wir schon nachstellen - wird eben nicht abgrebrochen, sondern fluid mitgewechselt, wenn beide Seiten sauber miteinander reden und nicht nur eine Seite mit der anderen und diese nicht zurück. Wenn beide Seiten die andere erreichen können, kann in diesem Fall die andere Seite die Verbindung weiterführen. Bei einem Neustart sieht das anders aus, da ist der Tunnel aber auch ggf. über mehrere Minuten offline. Natürlich gibt es dann einen Abbruch. Wenn sich aber lediglich die IP wechselt ist das eben genau kein Problem, sonst wäre an der Stelle Wireguard nicht so rboust bei Roaming via LTE bspw.

Natürlich ist das aber an bestimmten Stellen noch nicht so ausgereift wie ein OpenVPN was jahrelang schon abgehangen ist, aber so instabil dass es bei Berührung zusammenbricht ist es auch nicht ;)
Ich habe hier einen Tunnel der zum Test gegen eine statische IP aufgebaut ist und dieser wird jeden Tag mit neuer IP4/IP6 resettet da Zwangstrennung. Dabei wurde die Gegenstelle extra so konfiguriert, dass sie die Verbindung NICHT zurück aufbaut (RoadWarrior Szenario) und das ganze gemonitort. Der Tunnel läuft schon seit Wochen durch. Klar bei IP Wechsel und Neueinwahl gibts ne kurze Unterbrechung, aber minimal und die Gegenstelle läuft einfach weiter. Egal welche Seite rebootet wird, der Tunnel baut sich enorm schnell wieder auf.

Wenn ich das richtig verstanden habe hast du das Problem dass beide Seiten dynamisch sind? Ist das richtig? Dann würde ich versuchen das so zu bauen dass beide Seiten nach Möglichkeit sich versuchen gegenseitig zu rufen. Und kontrollieren, ob die entsprechenden Endpunkte auch eine Neueinwahl ihrer IP mitbekommen. Also wenn sich IP ändert es auch bei WG ankommt und dann der Deamon neu geladen wird.

Mit den Updates aus der nächsten Version wird das aber definitiv nochmal besser werden :)

Cheers

orcape

@jegr
Hi JeGr,

Wenn ich das richtig verstanden habe hast du das Problem dass beide Seiten dynamisch sind? Ist das richtig?

Eine Seite DSL/DynDNS, die andere LTE-USB-Stick an der OpenWRT3370-Fritte.
Und wie ich oben schon geschrieben habe, brauche ich mit dieser Hardware nicht mehr weiter machen. Zu den Daten braucht man wohl nichts weiter zu kommentieren...

Nun ja, ein "Lantiq XWAY VRX288 (xRX200) 500MHz" in Verbindung mit "128 MB RAM", stößt wohl hier an seine Grenzen.
4 Port-Switch, aufgeteilt auf 3 verschiedene LAN's, 2 x USB-Interfaces mit MWAN3 Ausfallsicherung, WLAN, OpenVPN und nun noch Wireguard, bringt wohl den nicht mehr soo ganz "taufrischen" Fritzkasten an seine Grenzen.

Allein das WLAN hat sich "schwergängig" angefühlt, wie ein 90 jähriger Rentner auf Krücken.
Es lässt sich viel anstellen, mit solch alter Hardware, aber das hat eben auch seine Grenzen und wie man sieht, ausgerechnet wenn man es nicht erwartet.
Ich finde eine andere Hardware-Lösung und dann rennt auch Wireguard an LTE, davon bin ich überzeugt und... "wieder etwas dazu gelernt.
Gruß orcape

JeGr

@orcape said in Wireguard Abbruch nach Provider IP-Wechsel:

Eine Seite DSL/DynDNS, die andere LTE-USB-Stick an der OpenWRT3370-Fritte.

Argl, OK LTE ist natürlich ein anderes Problem, weil der Kram ja sehr oft durch 444-NAT geschoben wird. Da ist ja eingehend keine Chance ... Urks. Die HW ist da recht unentscheidend. Es sei denn du hast Glück und ne LTE SIM die sich mit ner echten Public IP verbindet. Da kann man zwar mutmaßlich was basteln wenn man die Einstellungen dreht, aber das ist meist Bastelei.

@orcape said in Wireguard Abbruch nach Provider IP-Wechsel:

Ich finde eine andere Hardware-Lösung und dann rennt auch Wireguard an LTE, davon bin ich überzeugt und... "wieder etwas dazu gelernt.

Richtig, wichtig ist sich nicht unterkriegen lassen