Wireguard Abbruch nach Provider IP-Wechsel

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

orcape

@jegr
Hi,

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

Um es auf den Punkt zu bringen. Ich habe nun erst einmal wieder den OpenVPN-Tunnel am laufen. Nicht das mir die Geduld fehlen würde, aber es muss einen Sinn ergeben.
Am OpenWRT-Router steckt ein LTE-Stick, der ein eigenes Netz (192.168.8.0/24) aufbaut und dem OpenWRT als dessen Client, eine IP vergibt. Große Einstellungsänderungen, wie das bei Routern üblich ist, ist da natürlich Fehlanzeige.
Funktioniert alles bestens, bis auf die Tatsache, das dort LTE-seitig eine private-IP ankommt (10.xxx.xxx.xxx/???.???.???.?).
Nun habe ich auf meiner pfSense zu Hause auch noch 2 VLAN mit 10.100.xxx.x/24, 10.200.xxx.x/24, die als Routing-Netze im WG des OpenWRT eingetragen sind.
Ob das schon ein Problem darstellt und ob da die WG-IP (100.64.28.0/24) auch noch eine Rolle spielt, ich kann es nicht sagen.
Ich hatte ja den Tunnel auch schon laufen und für die dynamische Seite (DynDNS an der pfSense mal außen vor), sollte es ja eigentlich auch funktionieren.
OpenWRT hat auch für den dynamischen Wechsel der IP eine Möglichkeit der Lösung aufgezeigt.
Hier werden wohl mehrere Faktoren zusammen spielen und die Hardware ist "definitiv" an der "Kotzgrenze", denn von einem stabilen WLAN, kann z.B. schon keine Rede mehr sein.
Selbst der von mir noch getestete LinksysE4200 v2, mit 1000 MHz CPU, hat nur 128 MB RAM. Die Fritte3370 gar nur 500 MHz/128 MB.
Mit den ganzen weiteren installierten Futures, wird das in Verbindung mit LTE-WG dann wohl zum, .....könnte gehen oder auch nicht.

Richtig, wichtig ist sich nicht unterkriegen lassen

Der Winter ist noch lang, da geht noch was.
Gruß orcape

orcape

@orcape
@JeGr Ich habe das Thema Wireguard wieder neu aufgerollt, nachdem ich die OpenWRT-Fritte nebst LTE-Stick für die Kameraüberwachung mit OpenVPN wieder eingebaut habe.
Nun habe ich zu Hause den E4200 mit einem weiteren LTE-Stick stehen und einiges verändert, nachdem ich ein Tracert Richtung pfSene-WAN gemacht habe und feststellen musste, das am LTE gleich 2 x CG-NAT mit verschiedenen privaten IP 's gemacht wird.
Zum einen habe ich das Tunnelnetz (100.64.28.0/24) gegen (172.30.36.0/24) geändert und den Wireguard Standart Port 51820 ebenfalls etwas niedriger angesetzt und nun läuft es auf Anhieb.
Ich gehe mal davon aus, das der Provider entweder den Port 51820 blockt, oder es im Tunnelnetz eine Überschneidung gab.
Nun muss ich mir nur doch den Thread raussuchen, wo bei OpenWRT das leidige Problem des Tunnelabsturzes nach nach dem Ausfall des Servers gefixt wird.
Denn die 25 sec. Keep Alive, reichen wohl für die Zwangstrennung, nicht aber für einen 1/2 stündigen Stromausfall der Serverseite oder einen Neustart der pfSense.
Gruß orcape

slu

Ich stehe jetzt vor dem selben Problem und habe mich direkt an den Thread erinnert.
Sobald ich Zuhause eine neue IP bekomme funktioniert der Tunnel vom Android aus nicht mehr bis man ihn einmal ab und wieder anschaltet.

Soweit ich das sehe gibt es keine Chance die FQDN erneut aufzulösen, meine Hoffnung das die App das selber macht wenn eine weile nichts zurück kommt hat sich leider auch nicht bestätigt.

Es könnte so einfach sein...

orcape

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

Soweit ich das sehe gibt es keine Chance die FQDN erneut aufzulösen, meine Hoffnung das die App das selber macht wenn eine weile nichts zurück kommt hat sich leider auch nicht bestätigt.

Hi Slu,
zur Zeit bastele ich weiter an dem Tunnel, wobei ich sagen muss, das ich das so, niemals in einem produktiven Umfeld verwenden würde. Gut, da hätte man dann wohl auch ganz andere Vorraussetzungen. PfSense Plus, feste IP 's etc..
Letztlich ist es mehr oder weniger Hobby, mit positiven Nebeneffekten und selbst verursachten Kopfschmerzen.
Erschwerend kommt bei mir hinzu, das ich beide Seiten wechselnde IP 's habe. Einerseits die pfSense (CE) mit VDSL2 50 am WAN und DynDNS-Account, die "Client"-Seite, besser der Initiator des Tunnels mit USB-LTE-Stick und lt. Traceroute gleich 2 aufeinander folgende private IP-Bereiche.
Zum anderen hatte ich gestern einen Tunnelausfall, der wohl von der pfSense selbst ausging. Ein mit 75 % voll gelaufenes /var/tmpfs, ob nun die Ursache oder nicht?
Da musste ich erst die pfSense und anschließend den OpenWRT-Router neu starten.
Nun ist wohl WG nicht umsonst als Experimental gekennzeichnet und die CE-Version ist nicht der allerneueste Schrei an Software, schließlich muss Netgate auch Geld verdienen.
Was den Neustart des Tunnel angeht, so gibt es für Linux und OpenWRT Scripte, (vielleicht auch für Android) die den Tunnel abfragen und nach längerem Ausfall ggf. neu starten. Wenn Dein Android der Initiator des Tunnels ist, sollte ein Neustart des Handy's eigentlich helfen.
Leider hat das bei mir mit dem Script nicht wirklich funktioniert. Zumindest überlebt der Tunnel jetzt einen IP-Wechsel, leider nicht, wenn ich die pfSense neu starten muss. Dann muss ich zwangsweise danach den OpenWRT-Router neu starten. Selbstständig, wie geschrieben, tut er das zumindest bei mir nicht.
Gruß orcape

slu

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

Wenn Dein Android der Initiator des Tunnels ist, sollte ein Neustart des Handy's eigentlich helfen.

Ja das geht, es reicht den Tunnel einmal zu deaktivieren und wieder zu aktivieren.
Leider habe ich keine Möglichkeit gefunden das zu automatisieren.
So schade das es hier keine Option im WireGuard gibt.

orcape

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

So schade das es hier keine Option im WireGuard gibt.

Was ich da gefunden habe, betrifft OpenWRT...
WireGuard extras
und ein Linux-Tutorial....
automatically re-resolve DNS
Bei Android müsst da wohl etwas an der App gemacht werden.
Wenn Du das richtig stabil brauchst, wirst Du auf IPSec oder OpenVPN zurückgreifen müssen.
WG ist eine super Sache, nur eben mit dem kleinen Manko.
Gruß orcape

slu

@orcape
für alles was Strom/Netzteil hat nehme ich OpenVPN.

Bei den Smartphones läuft WG mit fester IP auf dem Server ohne Probleme,
derzeit testen wir das mit 19 Smartphone/Tablets.

orcape

@slu
Hi,
ich glaube das Problem gelöst zu haben.
Die pfSense zeigte mir sporadische Fälle von WG-Paketverlusten an, gefolgt vom Zusammenbruch der OpenWRT-WAN Vebindung.
Der LTE-Stick ist wohl das Problem.
Es ist halt schwierig, wenn so etwas nur sporadisch und relativ selten auftritt.
Gruß orcape

slu

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

Bei Android müsst da wohl etwas an der App gemacht werden.

Ja leider und ich finde nichts was in die Richtung geht das so eine Funktion eingebaut wird.
Normal braucht man das auch ja auch nicht...

Im Moment teste ich mit dem Keepalive von 20 Sekunden auf beiden Seiten, die Theorie war wie folgt:
Mein VDSL wird alle 24h einmal getrennt, damit gibt es eine neue WAN IP. Meine Hoffnung war das die 20 Sekunden Keepalive reichen um dem Smartphone über das Keepalive einmal ein Paket zu schicken womit die neue WAN Adresse angelernt wird.

Leider klappt das nicht, vielleicht teste ich mal ein Cronjob der im Zeitraum der Zwangstrennung die Smartphones 5 Minuten mit Pings alle Sekunde "flutet".