13
Probleme mit Wireguard nach Upgrade Telekom Glasfaser
Guten Morgen,
ich habe ein sehr seltsames Problem.
Ich nutze eine pfsense (2.7.2), welche die Einwahl macht und an dem Glasfasermodem der Telekom angeschlossen ist. Über die pfsense wähle ich mich auch extern per Wireguard ein und route dann den gesamten Netzwerkverkehr über diese Verbindung. Diese Kombination läuft bereits seit einigen Jahren.
Gestern bin ich auf die tolle Idee gekommen unseren bestehenden Anschluss bei der Telekom (500/100) auf 1000/500 MBit aufzustocken. Heute morgen kam die Info, dass die Umstellung erfolgt ist.
Wenn ich jetzt die VPN-Verbindung am Handy aufbaue, so zeigt das Handy an, dass alles ok ist. Allerdings scheint DNS nicht mehr zu funktionieren (konfiguriert ist ein lokaler DNS, der auch von lokal funktioniert) und darüber hinaus kann ich auch nur IPs pingen die im öffentlichen Netz sind, keine aus dem internen Netz zuhause (was sicherlich die Ursache ist, dass DNS nicht funktioniert).
Die Frage die sich mir stellt, warum ist das jetzt plötzlich so? Der VPN wird ja augenscheinlich aufgebaut (zeigt die pfsense und auch das Handy), warum kann ich dann keine Geräte mehr aus dem internen Netz erreichen? Kann das überhaupt mit dem Upgrade zusammenhängen (das erscheint mir unlogisch, allerdings zeitgleich aufgetreten)?
Vielleicht hat ja jemand eine Idee.
Vielen Dank!
Carsten
ich habe ein sehr seltsames Problem.
Ich nutze eine pfsense (2.7.2), welche die Einwahl macht und an dem Glasfasermodem der Telekom angeschlossen ist. Über die pfsense wähle ich mich auch extern per Wireguard ein und route dann den gesamten Netzwerkverkehr über diese Verbindung. Diese Kombination läuft bereits seit einigen Jahren.
Gestern bin ich auf die tolle Idee gekommen unseren bestehenden Anschluss bei der Telekom (500/100) auf 1000/500 MBit aufzustocken. Heute morgen kam die Info, dass die Umstellung erfolgt ist.
Wenn ich jetzt die VPN-Verbindung am Handy aufbaue, so zeigt das Handy an, dass alles ok ist. Allerdings scheint DNS nicht mehr zu funktionieren (konfiguriert ist ein lokaler DNS, der auch von lokal funktioniert) und darüber hinaus kann ich auch nur IPs pingen die im öffentlichen Netz sind, keine aus dem internen Netz zuhause (was sicherlich die Ursache ist, dass DNS nicht funktioniert).
Die Frage die sich mir stellt, warum ist das jetzt plötzlich so? Der VPN wird ja augenscheinlich aufgebaut (zeigt die pfsense und auch das Handy), warum kann ich dann keine Geräte mehr aus dem internen Netz erreichen? Kann das überhaupt mit dem Upgrade zusammenhängen (das erscheint mir unlogisch, allerdings zeitgleich aufgetreten)?
Vielleicht hat ja jemand eine Idee.
Vielen Dank!
Carsten
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 94257453032
Url: https://administrator.de/contentid/94257453032
Ausgedruckt am: 19.11.2024 um 06:11 Uhr
13 Kommentare
Neuester Kommentar
Morschen.
Bitte mal die Wireguard Configs des Clients und des Servers (anonymisiert) posten.
Wurde die PFSense oder zumindest das sich einwählende Interface einmal "neu gestartet" nach der Umstellung?
Liegt da eine statische oder öffentliche IPv4 an oder ist das ein CGNAT Anschluss?
Kommt eventuell DynDNS zum Einsatz?
Gruß
Marc
Bitte mal die Wireguard Configs des Clients und des Servers (anonymisiert) posten.
Wurde die PFSense oder zumindest das sich einwählende Interface einmal "neu gestartet" nach der Umstellung?
Liegt da eine statische oder öffentliche IPv4 an oder ist das ein CGNAT Anschluss?
Kommt eventuell DynDNS zum Einsatz?
Gruß
Marc
1
Korrekte Konfig checken:
pfSense als Wireguard Server (Responder)
Wegen der nicht idealen Integration von WG wäre es deutlich sinnvoller einen IKEv2 VPN Server auf der pfSense zu verwenden um überall die bordeigenen VPN Clients nutzen zu können.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Oder alternativ die L2TP VPN Lösung:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Erspart einem zudem das Gefrickel mit externer (überflüssiger) VPN Client Software auf den Endgeräten.
pfSense als Wireguard Server (Responder)
Wegen der nicht idealen Integration von WG wäre es deutlich sinnvoller einen IKEv2 VPN Server auf der pfSense zu verwenden um überall die bordeigenen VPN Clients nutzen zu können.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Oder alternativ die L2TP VPN Lösung:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Erspart einem zudem das Gefrickel mit externer (überflüssiger) VPN Client Software auf den Endgeräten.
Hallo
wenn du IPs pingst dann ist der DNS unnötig und sollte trotzdem funktionieren.
Da ist ein anderes Problem.
wenn du IPs pingst dann ist der DNS unnötig und sollte trotzdem funktionieren.
Da ist ein anderes Problem.
Hallo zusammen,
Handy und pfsense habe ich neu gestartet. Der Anschluss hat nur eine dynamische IP (vorher, wie jetzt auch).
Die dyndns-Geschichte mache ich über aws Route53 und lasse die pfsense die IP dort aktualisieren.
Hier jetzt mal die Config vom Server und dem Handy (abc und xyz habe ich zum anonymisieren genutzt).
Was ich ganz seltsam finde, das Handy kann sich zwar nicht per WG verbinden, allerdings habe ich noch einen Reiserouter (gli.net) bei dem ich gerade testweise als upstream das Handy konfiguriert habe und der einwandfrei eine WG-Verbindung aufbauen konnte zum Server... in dem Fall halt auch über die Verbindung des Handies (DNS usw funktioniert da auch anschließend). Es scheint also grundsätzlich zu gehen. Eventuell war es auch ein Andoid-Update der letzten Tage?
Server
Android-Client
GLI-Router
LG
Carsten
Handy und pfsense habe ich neu gestartet. Der Anschluss hat nur eine dynamische IP (vorher, wie jetzt auch).
Die dyndns-Geschichte mache ich über aws Route53 und lasse die pfsense die IP dort aktualisieren.
Hier jetzt mal die Config vom Server und dem Handy (abc und xyz habe ich zum anonymisieren genutzt).
Was ich ganz seltsam finde, das Handy kann sich zwar nicht per WG verbinden, allerdings habe ich noch einen Reiserouter (gli.net) bei dem ich gerade testweise als upstream das Handy konfiguriert habe und der einwandfrei eine WG-Verbindung aufbauen konnte zum Server... in dem Fall halt auch über die Verbindung des Handies (DNS usw funktioniert da auch anschließend). Es scheint also grundsätzlich zu gehen. Eventuell war es auch ein Andoid-Update der letzten Tage?
Server
Android-Client
GLI-Router
LG
Carsten
Zitat von @Xerebus:
Hallo
wenn du IPs pingst dann ist der DNS unnötig und sollte trotzdem funktionieren.
Da ist ein anderes Problem.
Hallo
wenn du IPs pingst dann ist der DNS unnötig und sollte trotzdem funktionieren.
Da ist ein anderes Problem.
Da ist mir nicht klar, was du damit meinst, eventuell habe ich dich da auch missverstsanden. Was ich damit sagen wollte ist, dass er anscheinend den DNS nicht erreicht, der im lokalen Netz steht (dafür muss der VPN ja korrekt funktionieren).Mit ereichen meine ich weder pingen noch 53 UDP. Sprich DNS ist nicht das Problem, sondern bereits vorher die grundsätzliche Erreichbarkeit.
MTU einzustellen ist Unsinn, denn 1420 ist die Wireguard Default MTU. Kannst du also gleich weglassen da überflüssig.
Die IP Adressierung des Android Clients und auch GL.inet Clients ist falsch!
Die Client IP selber hat immer die Subnetzmaske des intern verwendeten VPN IP Netzes aber niemals eine Hostmaske. Die Hostmaske wird ausschliesslich nur in der "AllowedIP" Definition des internen Netzes verwendet! (Siehe entspr. Hinweis im Tutorial!)
Die "AllowedIP" Definition bestimmt immer WAS an Traffic in den Tunnel gesendet wird. Traffic mit Ziel IP Adressen in der "AllowedIP" Definition werden in den Tunnel geroutet. Das ist die klassische "Crypro Key Routing" Funktion bei WG!
Außerdem fehlt dort in den Allowed IPs die interne Server IP mit der /32er Maske. (Siehe Turorial)
Was noch viel fataler ist ist die Tatsache das die /19er Maske das interne WG Netz überschneidet. Mit so einer falschen "AllowedIP" Definition scheitert schon das "Crypro Key Routing" an sich.
Die gleichen Fehler wurden auch beim GL.inet Client wieder gemacht.
Die generell falsche IP Adressierung und das überschneiden der Routen mit dem internen IP Netz der beiden Clients ist die grundsätzlich Ursache für die Fehlfunktion!
Tutorial einmal wirklich lesen und verstehen hilft!
Die IP Adressierung des Android Clients und auch GL.inet Clients ist falsch!
Die Client IP selber hat immer die Subnetzmaske des intern verwendeten VPN IP Netzes aber niemals eine Hostmaske. Die Hostmaske wird ausschliesslich nur in der "AllowedIP" Definition des internen Netzes verwendet! (Siehe entspr. Hinweis im Tutorial!)
Die "AllowedIP" Definition bestimmt immer WAS an Traffic in den Tunnel gesendet wird. Traffic mit Ziel IP Adressen in der "AllowedIP" Definition werden in den Tunnel geroutet. Das ist die klassische "Crypro Key Routing" Funktion bei WG!
Außerdem fehlt dort in den Allowed IPs die interne Server IP mit der /32er Maske. (Siehe Turorial)
Was noch viel fataler ist ist die Tatsache das die /19er Maske das interne WG Netz überschneidet. Mit so einer falschen "AllowedIP" Definition scheitert schon das "Crypro Key Routing" an sich.
Die gleichen Fehler wurden auch beim GL.inet Client wieder gemacht.
- Wieder falsche Maske bei der Client IP Adressierung!
- Gateway Redirect statt Split Tunneling
- MTU überflüssig da Default
- DNS mus sman nur angeben wenn man einen internen DNS verwendet
Die generell falsche IP Adressierung und das überschneiden der Routen mit dem internen IP Netz der beiden Clients ist die grundsätzlich Ursache für die Fehlfunktion!
Tutorial einmal wirklich lesen und verstehen hilft!
1Zitat von @aqui:
Die generell falsche IP Adressierung und das überschneiden der Routen mit dem internen IP Netz der beiden Clients ist die grundsätzlich Ursache für die Fehlfunktion!
Tutorial einmal wirklich lesen und verstehen hilft!
- Wieder falsche Maske bei der Client IP Adressierung!
- Gateway Redirect statt Split Tunneling
- MTU überflüssig da Default
- DNS mus sman nur angeben wenn man einen internen DNS verwendet
Die generell falsche IP Adressierung und das überschneiden der Routen mit dem internen IP Netz der beiden Clients ist die grundsätzlich Ursache für die Fehlfunktion!
Tutorial einmal wirklich lesen und verstehen hilft!
Super, ganz lieben Dank für den Hinweis, aus meiner Sicht ist von den aufgeführten Punkten dann ja quasi "nur" das überschneiden der Routen ein Problem, denn der Rest wie in dem einen Fall Gateway Redirect und der interne DNS sind gewünscht.
Auch das das gesamte 10.0.96.0/19 Netz in dem Fall über den Tunnel geroutet wird, ist gewünscht. Bei dem WG-VPN-Netz werde ich dann mal den Adressbereich ändern, so dass dieser außerhalb liegt. Bei der MTU kann ich auch garnicht sagen, wie die dort hinein gekommen ist, ev hat der gli.net Router dies automatisch in die Config gepackt oder ich, ich weiß es nicht mehr.
Das werde ich jetzt erstmal machen, allerdings bin ich gespannt ob dies die Ursache für die plötzlichen Probleme sind, da es ja viele Monate (/Jahre?) so funktioniert hat.
Aber einen Schritt nach dem Anderen, vielen Dank auf jeden Fall für die Hinweise!
Ich muss sagen, es funktioniert jetzt einwandfrei. Vielen Dank nochmal!
Ich habe für das WG-Netz jetzt einfach 172.16.5.0/24 genommen und die Config auf dem Client und dem Server angepasst. Außerdem musste ich auf dem bind-DNS (10.0.100.61) noch dem 172.16.5er Netz erlauben DNS-Anfragen zu stellen, danach lief es einwandfrei.
Das Einzige, was ich noch immer nicht verstehe ist warum es bei dem Routing dann kein Problem ist, wenn ich alles über den WG-VPN route (0.0.0.0/0), denn diese Route umfasst ja ebenfalls das WG-Netz, so wie vorher auch das 10.0.96.0/19?
Aber da schaue ich mir in den nächsten Tagen nochmal dein Tutorial an. Die MTU habe ich in dem Zuge auch entfernt. Naja und warum es so monatelang funktioniert hat und die Probleme erst jetzt auftreten.
Vielen DAnk!
Ich habe für das WG-Netz jetzt einfach 172.16.5.0/24 genommen und die Config auf dem Client und dem Server angepasst. Außerdem musste ich auf dem bind-DNS (10.0.100.61) noch dem 172.16.5er Netz erlauben DNS-Anfragen zu stellen, danach lief es einwandfrei.
Das Einzige, was ich noch immer nicht verstehe ist warum es bei dem Routing dann kein Problem ist, wenn ich alles über den WG-VPN route (0.0.0.0/0), denn diese Route umfasst ja ebenfalls das WG-Netz, so wie vorher auch das 10.0.96.0/19?
Aber da schaue ich mir in den nächsten Tagen nochmal dein Tutorial an. Die MTU habe ich in dem Zuge auch entfernt. Naja und warum es so monatelang funktioniert hat und die Probleme erst jetzt auftreten.
Vielen DAnk!
1
👏👍 Glückwunsch!
Ein Problem ist ein Gateway Redirect 0.0.0.0/0 per se nicht. Man muss sich nur gut überlegen ob man sowas will oder doch lieber effizient mit einem Split Tunnel Konzept arbeiten will.
Redirect routet dann halt alles, auch jeglichen lokalen Traffic, in den Tunnel. Geht auch, kostet aber massiv Performance im Tunnel.
Andererseits macht es auch Sinn wenn man primär ein Security Konzept mit dem Client verfolgt und dessen Traffic generell immer verschlüsselt übertragen will z.B. weil man sich häufig in öffentlichen Netzen, Hotspots etc. aufhält. Dort zählt dann primär die Security und weniger die Performance.
Mit anderen Worten: Es hängt immer von deinem VPN Konzept ab und was DIR letztlich am wichtigsten ist und welches Ziel DU verfolgst.
Ein Problem ist ein Gateway Redirect 0.0.0.0/0 per se nicht. Man muss sich nur gut überlegen ob man sowas will oder doch lieber effizient mit einem Split Tunnel Konzept arbeiten will.
Redirect routet dann halt alles, auch jeglichen lokalen Traffic, in den Tunnel. Geht auch, kostet aber massiv Performance im Tunnel.
Andererseits macht es auch Sinn wenn man primär ein Security Konzept mit dem Client verfolgt und dessen Traffic generell immer verschlüsselt übertragen will z.B. weil man sich häufig in öffentlichen Netzen, Hotspots etc. aufhält. Dort zählt dann primär die Security und weniger die Performance.
Mit anderen Worten: Es hängt immer von deinem VPN Konzept ab und was DIR letztlich am wichtigsten ist und welches Ziel DU verfolgst.
Zitat von @aqui:
Die IP Adressierung des Android Clients und auch GL.inet Clients ist falsch!
Die Client IP selber hat immer die Subnetzmaske des intern verwendeten VPN IP Netzes aber niemals eine Hostmaske. Die Hostmaske wird ausschliesslich nur in der "AllowedIP" Definition des internen Netzes verwendet!
Die IP Adressierung des Android Clients und auch GL.inet Clients ist falsch!
Die Client IP selber hat immer die Subnetzmaske des intern verwendeten VPN IP Netzes aber niemals eine Hostmaske. Die Hostmaske wird ausschliesslich nur in der "AllowedIP" Definition des internen Netzes verwendet!
Das klappt bei mir seit drei Jahren genau so ohne Probleme. Allerdings habe ich auch keine Überschneidung der Tunnel IP mit der lokalen IP.
Zitat von @aqui:
Andererseits macht es auch Sinn wenn man primär ein Security Konzept mit dem Client verfolgt und dessen Traffic generell immer verschlüsselt übertragen will z.B. weil man sich häufig in öffentlichen Netzen, Hotspots etc. aufhält.
Andererseits macht es auch Sinn wenn man primär ein Security Konzept mit dem Client verfolgt und dessen Traffic generell immer verschlüsselt übertragen will z.B. weil man sich häufig in öffentlichen Netzen, Hotspots etc. aufhält.
Das finde ich gerade als Alternative zu irgendwelchen Dubiosen VPN Diensten die einzig wirklich sinnvolle Herangehensweise.
Gruß
Marc
Genau das ist für mich der Ansatz, ich nehme den Reiserouter mit in die FeWo und lasse da alles verschlüsselt drüber nach Hause laufen. Auch für die Kids, Frau usw.
Deshalb, so ist alles perfekt, es musste nur wieder funktionieren.... mir ist nur noch immer unklar, warum es jetzt plötzlich nicht mehr klappte, auch wenn ich einsehe, dass da grundsätzlich ein Fehler war. ;)
Vielen Dank nochmal für den entscheidenden Hinweis!
Deshalb, so ist alles perfekt, es musste nur wieder funktionieren.... mir ist nur noch immer unklar, warum es jetzt plötzlich nicht mehr klappte, auch wenn ich einsehe, dass da grundsätzlich ein Fehler war. ;)
Vielen Dank nochmal für den entscheidenden Hinweis!
Das klappt bei mir seit drei Jahren genau so ohne Probleme.
Ist aber dennoch laut offizieller Wireguard Dokumentation falsch. Ist auch verständlich, denn das Cryptokey Routing ist auf die Verwendung einer korrekten Maske angewiesen um das Routing eindeutig zu machen. Legt man auf Stabilität wert sollte man solche Frickeleien besser immer vermeiden.Das gilt ebenso für die Einzigartigkeit des internen IP Netzes was niemals die Range des Cryptokey Routings überschneiden darf, weil ansonsten eine korrekte Wegefindung nicht mehr möglich ist.
1Das klappt bei mir seit drei Jahren genau so ohne Probleme.
Ist aber dennoch laut offizieller Wireguard Dokumentation falsch. Ist auch verständlich, denn das Cryptokey Routing ist auf die Verwendung einer korrekten Maske angewiesen um das Routing eindeutig zu machen. Legt man auf Stabilität wert sollte man solche Frickeleien besser immer vermeiden.Ist beherzigt und habe das bei meinen Geräten nun entsprechend abgeändert.
Hatte vor Jahren, als ich mit Wireguard begonnen hatte, das irgendwo so übernommen
Da es keinerlei Probleme gab, hatte ich keine große Motivation das zu ändern.
Gruß
Marc
1
