Wireguard Abbruch nach Provider IP-Wechsel
-
@bob-dig said in Wireguard Abbruch nach Provider IP-Wechsel:
Komisch ist auch, dass sich die IP bei dir daheim ändert und Du dann WireGuard neustartest, was angeblich helfen soll.
Da ich den OpenVPN-Tunnel auf der pfSense noch eingerichtet habe, musste ich den Wireguard-Server erst abschalten um auf den remoten Router zu kommen und diesen zu resetten. Da spielt sonst das Routing nicht mit.
Die remote Seite befindet sich in einem Wochendhaus und da ist derzeit keiner, der den Client neu starten kann.
Fakt ist wohl, das Wireguard mit DynDNS so seine Probleme hat und beim IP-Wechsel versagen kann. Die Ursache ist wohl dabei, das die DynDNS-Adresse nur beim hochfahren der Wireguard Einstellungen des Clients neu eingelesen wird und genau das führt dazu, das die alte IP weiter benutzt wird.
Somit bricht der Tunnel ab, bis der Router entweder resettet wird oder vom Netz getrennt.
Sollte also die Lösung ein Script oder ein Cron basierender Neustart sein und nicht, wie ich vermutete, ein Cron-Job auf der pfSense, sondern auf dem OPenWRT-Router.
Gruß orcape -
@orcape Also hier mit der Plus läuft es grundsätzlich. Mein Eindruck ist nur, dass wenn man ohne Keep Alive arbeitet, dass ein Wiederaufbau eines Tunnels für manche Anwendung etwas zu lange dauern kann.
-
Also hier mit der Plus läuft es grundsätzlich.
Kann gut sein. Das Problem mit der Zwangstrennung ist aber bekannt, ob und wann das in der Wireguard Config gelöst wird, keine Ahnung.
Die Keep Alive war auf 15 gesetzt.
Ich werde das mit dem Cron Job mal ins Auge fassen.
Notfalls funktioniert erst einmal OpenVPN problemlos.
Gruß orcape -
Wie lange ist auf Client Seite die TTL vom DynDNS Eintrag?
-
@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. -
@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 ;)
-
@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 -
@orcape Sry, Fritte ist vor der Sense, aber WG ist nur auf der Sense am Laufen, nicht auf der Fritte.
-
@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 -
@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?
-
@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.
-
@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.
-
@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 -
@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
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 -
@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 -
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.
-
@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 -
@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.
-
@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
