12
WireGuard Client nutzt IPv4 anstatt IPv6
Hallo liebe Netzwerker,
ich habe historisch bedingt privat noch klassische IPSec Verbindungen (S2S, C2S) im Einsatz. Um endlich auch mit der Zeit gehen stelle ich zurzeit auf WireGuard um.
Auf mehreren Rechnern mit Windows 10 und 11 kommt der offizielle WireGuard Client zum Einsatz. Der Verbindungsaufbau zur Firewall funktioniert problemlos.
Allerdings wird bei Geräten bzw. Internetanschlüssen mit DualStack die Verbindung nicht über IPv6, sondern über IPv4 aufgebaut. Sobald ich auf der Netzwerkkarte des Windows Rechners das Internetprotokoll Version 4 deaktiviere (Haken entfernt) wird die VPN-Verbindung problemlos über IPv6 aufgebaut.
Standardmäßig wir unter Windows (Server) bei der Verfügbarkeit einer IPv6 Adresse (sowohl am Client als auch Zielsystem) dieses Protokoll bevorzugt verwendet. Nun verhält sich der WireGuard Client genau andersherum. Zuerst dachte ich, dass an den Windows Rechnern, etwas "verkonfiguriert" wurde, was aber nicht der Fall ist.
Bei der Recherche bin ich u.a. über den Artikel Hostname in endpoint: WireGuard uses IPv4 instead of IPv6 gestolpert. Dort wird genau das oben beschriebene Verhalten wieder gegeben. Soweit ich das verstehe liegt es an der Implementierung in der Sprache "GO".
Bevor ich nun den Weg über zwei Subdomains gehe, wollte ich eure Expertise dazu hören. Weil würde bedeuten, dass der Anwender in Zukunft zwei VPN-Verbindungen im WireGuard Client hat. Je nach dem hat der Benutzer die Qual und muss natürlich ein Stück weit immer mitdenken.
Gibt es evtl. einen besseren Workaround?
Gruß,
Dani
ich habe historisch bedingt privat noch klassische IPSec Verbindungen (S2S, C2S) im Einsatz. Um endlich auch mit der Zeit gehen stelle ich zurzeit auf WireGuard um.
Auf mehreren Rechnern mit Windows 10 und 11 kommt der offizielle WireGuard Client zum Einsatz. Der Verbindungsaufbau zur Firewall funktioniert problemlos.
Allerdings wird bei Geräten bzw. Internetanschlüssen mit DualStack die Verbindung nicht über IPv6, sondern über IPv4 aufgebaut. Sobald ich auf der Netzwerkkarte des Windows Rechners das Internetprotokoll Version 4 deaktiviere (Haken entfernt) wird die VPN-Verbindung problemlos über IPv6 aufgebaut.
Standardmäßig wir unter Windows (Server) bei der Verfügbarkeit einer IPv6 Adresse (sowohl am Client als auch Zielsystem) dieses Protokoll bevorzugt verwendet. Nun verhält sich der WireGuard Client genau andersherum. Zuerst dachte ich, dass an den Windows Rechnern, etwas "verkonfiguriert" wurde, was aber nicht der Fall ist.
Bei der Recherche bin ich u.a. über den Artikel Hostname in endpoint: WireGuard uses IPv4 instead of IPv6 gestolpert. Dort wird genau das oben beschriebene Verhalten wieder gegeben. Soweit ich das verstehe liegt es an der Implementierung in der Sprache "GO".
Bevor ich nun den Weg über zwei Subdomains gehe, wollte ich eure Expertise dazu hören. Weil würde bedeuten, dass der Anwender in Zukunft zwei VPN-Verbindungen im WireGuard Client hat. Je nach dem hat der Benutzer die Qual und muss natürlich ein Stück weit immer mitdenken.
Gibt es evtl. einen besseren Workaround?
Gruß,
Dani
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: 1890762768
Url: https://administrator.de/contentid/1890762768
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
12 Kommentare
Neuester Kommentar
Weil würde bedeuten, dass der Anwender in Zukunft zwei VPN-Verbindungen im WireGuard Client hat. Je nach dem hat der Benutzer die Qual und muss natürlich ein Stück weit immer mitdenken.
Wozu? Wenn er die Verbindung doch mit IPv4 herstellt wozu sollte er dann extra auf IPv6 wechseln? Funktioniert doch über IPv4 genauso wie mit IPv6. Wenn der Windows WG-Client halt zu blöd ist , wird das vielleicht irgendwann mal behoben, bis dahin abwarten Tee trinken und die Clients die Verbindung eben über IPv4 aufbauen lassen, Hauptsache es läuft.Wenn ihr beide Wege bereitstellt aber wollte das nur IPv6 genutzt wird dann entfernt die IPv4 von dem Domainnamen.
IPv6 selbst kann man ja auch über eine IPv4 WG Verbindung tunneln, das macht keinen Unterschied.
JustMy2Cent
Gruß pj
Zitat von @10138557388:
Wozu? Wenn er die Verbindung doch mit IPv4 herstellt wozu sollte er dann extra auf IPv6 wechseln? Funktioniert doch über IPv4 genauso wie mit IPv6.
Wozu? Wenn er die Verbindung doch mit IPv4 herstellt wozu sollte er dann extra auf IPv6 wechseln? Funktioniert doch über IPv4 genauso wie mit IPv6.
Moin,
Wegen CGNAT!
Viele dyndns-Dienste, insbesondere myfritz, registrieren beide Adressen. Allerdings funktioniert v4 deswegen oft nicht und die Verbindung scheitert manchmal. Bei v6-first, wurde es immer funktionieren.
lks
Klappt hier seit Jahren problemlos.
Außerdem spielt die IP des Clients keine Rolle die ist ja eh dynamisch und der Server passt die automatisch an wenn sie sich ändert, das ist ja gerade der Vorteil .
Viele dyndns-Dienste, insbesondere myfritz, registrieren beide Adressen.
Aktuelle FritzOS nicht mehr! Die erkennen inzwischen wenn sie eine private oder IP aus dem 100.64.x.x Bereich bekommen und registrieren dann nur noch die IPv6 bei myfritz!Außerdem spielt die IP des Clients keine Rolle die ist ja eh dynamisch und der Server passt die automatisch an wenn sie sich ändert, das ist ja gerade der Vorteil .
Allerdings funktioniert v4 deswegen oft nicht und die Verbindung scheitert manchmal. Bei v6-first, wurde es immer funktionieren.
Das ist kein Problem man muss bei CGNat Clients nur in der Config das permanente Aufrechterhalten aktivieren (PersistentKeepalive 25) dann spielt IPv4 oder IPv6 keine Rolle denn die UDP Verbindung ist dann permanent offen und auch der Weg von Server zum Client.
Um endlich auch mit der Zeit gehen stelle ich zurzeit auf WireGuard um.
Das musst du nicht unbedingt. WG ist da nicht unbedingt besser als IPsec und hat (noch) diverse Nachteile. Besonders im v4 und v6 Handling.mit DualStack die Verbindung nicht über IPv6, sondern über IPv4 aufgebaut.
Hat dein WG Setup auf dem Server als auch auf dem Client denn auch ein gültiges IPv6 Setup??Nimmt man ein klassisches Setup ala
[Interface]
Address = 10.66.66.254/24, fd66:bade:affe:cafe::1/64
ListenPort = 57821
PrivateKey = zyx
[Peer]
PublicKey = xyz
AllowedIPs = 10.66.66.1/32, fd66:bade:affe:cafe::1001/128 Bzw. für den Client
[Interface]
PrivateKey = abc
Address = 10.66.66.1/24, fd66:bade:affe:cafe::1001/64
[Peer]
PublicKey = cba
AllowedIPs = 10.66.66.254/32, fd66:bade:affe:cafe::1/128
Endpoint = [2a05:d014:926:ffaa:87dd::123]:57821
PersistentkeepAlive = 25 Rennt WG fehlerlos mit einem preferierten IPv6 Tunnel.
Zitat von @10138557388:
Klappt hier seit Jahren problemlos.
Klappt hier seit Jahren problemlos.
Viele dyndns-Dienste, insbesondere myfritz, registrieren beide Adressen.
Aktuelle FritzOS nicht mehr! Die erkennen inzwischen wenn sie eine private oder IP aus dem 100.64.x.x Bereich bekommen und registrieren dann nur noch die IPv6 bei myfritz!Diverse Fritten 75x0 (AX) mit 7.57 bei Kunden sagen da was anderes.
lks
Zitat von @10138557388:
Allerdings funktioniert v4 deswegen oft nicht und die Verbindung scheitert manchmal. Bei v6-first, wurde es immer funktionieren.
Das ist kein Problem man muss bei CGNat Clients nur in der Config das permanente Aufrechterhalten aktivieren (PersistentKeepalive 25) dann spielt IPv4 oder IPv6 keine Rolle denn die UDP Verbindung ist dann permanent offen und auch der Weg von Server zum Client.Ich habe erst letzte Woche bei einem Kunden merkwürdige Geschwindigkeitsprobleme und Packetloss bei VPN debugged. Lösung: Auf IPv6 wechseln um das überlastete CGNAT des Providers zu umgehen.
Kein NAT = Kein Problem, deshalb will man IPv6 wo es geht bevorzugen.
@Dani:
Vor dem Problem wie du habe ich auch gestanden. Und festgestellt: Wireguard ist an der Stelle einfach inhärent kaputt. Mehrere Endpunkte für die selben Routen zu haben (IPv4 und IPv6 gelten als unterschiedliche Endpunkte) funktioniert nicht. Wird eine IPv6- und eine IPv4-Adresse eingetragen, versucht Wireguard auch in IPv4 only Netzen verzweifelt, eine IPv6-Verbindung aufzubauen. Ein Failover ist schlicht nicht vorgesehen.
Deshalb verhält sich Wireguard vermutlich auch bei DNS-Namen so, dass IPv4 immer bevorzugt verwendet wird. Aber auch nur der erste A-Record der kommt - wenn man hier Redundanz durch DNS-RR schaffen will, scheitert man ebenfalls an Wireguard.
Wenn du da eine funktionierende Lösung hast, dann solltest du sie nicht durch Wireguard ersetzen. Wenn du die Lösung ersetzen musst, dann ist Wireguard bestenfalls die letzte Option.
Meine Meinung zu Wireguard ist, dass das zu Unrecht hochgehyped wird. Und, da es von einer Consulting-Bude entwickelt wird, eventuell absichtlich so fürchterlich implementiert ist, damit die Consulting dafür verkaufen können.
1Zitat von @Lochkartenstanzer:
Diverse Fritten 75x0 (AX) mit 7.57 bei Kunden sagen da was anderes.
Zitat von @10138557388:
Klappt hier seit Jahren problemlos.
Klappt hier seit Jahren problemlos.
Viele dyndns-Dienste, insbesondere myfritz, registrieren beide Adressen.
Aktuelle FritzOS nicht mehr! Die erkennen inzwischen wenn sie eine private oder IP aus dem 100.64.x.x Bereich bekommen und registrieren dann nur noch die IPv6 bei myfritz!Diverse Fritten 75x0 (AX) mit 7.57 bei Kunden sagen da was anderes.
Hier ist bei allen die CG-Nat nutzen keine IPv4 mehr bei myfritz zu sehen, 10Fboxen mit 7.57.
Habe ich im Quell-Code der Fritzboxen auch mal aus Interesse nachgesehen, sieh selbst nach da steht es schwarz auf weiß wie sie es jetzt machen 😉.
Zitat von @10138557388:
Hier ist bei allen die CG-Nat nutzen keine IPv4 mehr bei myfritz zu sehen, 10Fboxen mit 7.57.
Habe ich im Quell-Code der Fritzboxen auch mal aus Interesse nachgesehen, sieh selbst nach da steht es schwarz auf weiß wie sie es jetzt machen 😉.
Zitat von @Lochkartenstanzer:
Diverse Fritten 75x0 (AX) mit 7.57 bei Kunden sagen da was anderes.
Zitat von @10138557388:
Klappt hier seit Jahren problemlos.
Klappt hier seit Jahren problemlos.
Viele dyndns-Dienste, insbesondere myfritz, registrieren beide Adressen.
Aktuelle FritzOS nicht mehr! Die erkennen inzwischen wenn sie eine private oder IP aus dem 100.64.x.x Bereich bekommen und registrieren dann nur noch die IPv6 bei myfritz!Diverse Fritten 75x0 (AX) mit 7.57 bei Kunden sagen da was anderes.
Hier ist bei allen die CG-Nat nutzen keine IPv4 mehr bei myfritz zu sehen, 10Fboxen mit 7.57.
Habe ich im Quell-Code der Fritzboxen auch mal aus Interesse nachgesehen, sieh selbst nach da steht es schwarz auf weiß wie sie es jetzt machen 😉.
O.k. Aber wie gesagt bisher wurde auch die cgnat-Adressegemeldet. Werde Mal morgen über die drüberschauen, zu denen ich Zugangsdaten bekommen habe.
lks
AVM hat es auch selbst dokumentiert
https://avm.de/service/update-news/neueste-updates-der-fritz-produkte/do ...
https://avm.de/service/update-news/neueste-updates-der-fritz-produkte/do ...
Verbesserung Keine Veröffentlichung der IPv4-Adresse zu MyFRITZ!Net an Dual-Stack-Anschlüssen mit Carrier-Grade-NAT; Auflösung der MyFRITZ!-Adresse erfolgt hier immer zur IPv6-Adresse
eventuell absichtlich so fürchterlich implementiert ist, damit die Consulting dafür verkaufen können.
Was man auch schon daran erkennt das eine umfassende und saubere Dokumentation aller Setup Kommandos auf der offiziellen Webseite fehlt. 
Ein Schelm wer Böses dabei denkt...IPsec ist dagegen immer eine sichere Bank.
Zitat von @aqui:
Ein Schelm wer Böses dabei denkt...
IPsec ist dagegen immer eine sichere Bank.
eventuell absichtlich so fürchterlich implementiert ist, damit die Consulting dafür verkaufen können.
Was man auch schon daran erkennt das eine umfassende und saubere Dokumentation aller Setup Kommandos auf der offiziellen Webseite fehlt. Ein Schelm wer Böses dabei denkt...IPsec ist dagegen immer eine sichere Bank.
Wireguard selbst ist nur das Transport-Protokoll, wie die unterschiedlichen Projekte die Parameter für den Aufbau des Tunnels in Konfigurationsdateien pressen ist deren Dokumentations-Bier. Hier braut auch mancher sein eigenes Süppchen wie man z.B. auch an der Grütze von AVM sehen kann.
Bei IPSec ist der Wildwuchs ja auch nicht gerade klein.
@10138557388
@aqui
@LordGurke
Nun haben seit Monaten immer wieder massive Probleme. Man sieht bei MTRs ganz klar, dass es die Peerings von ISP A zu ISP B einfach immer wieder voll sind. Die DTAG ist hier noch am auskunftsfreudlichsten. Vodafone und die regional Provider stellen sich tot oder schmeißen mit Textbausteinen um sich.
Gruß,
Dani
Wozu? Wenn er die Verbindung doch mit IPv4 herstellt wozu sollte er dann extra auf IPv6 wechseln? Funktioniert doch über IPv4 genauso wie mit IPv6.
Weil in der Regel am Weekend und am Abend die Peerings (DATG, Vodafone, regional ISPs) auf IPv4 überlastet sind. Hingegen bei IPv6 scheinen die Ressourcen groß genug zu sein.Wenn der Windows WG-Client halt zu blöd ist , wird das vielleicht irgendwann mal behoben, bis dahin abwarten Tee trinken und die Clients die Verbindung eben über IPv4 aufbauen lassen, Hauptsache es läuft.
Der Grund für das Verhalten liegt laut dem von mir verlinkten Post nicht am Client, sondern an Go. Kann das aber aus der Perspektive eines Entwicklers nicht vollumfänglich bewerten.Wenn der Windows WG-Client halt zu blöd ist , wird das vielleicht irgendwann mal behoben, bis dahin abwarten Tee trinken und die Clients die Verbindung eben über IPv4 aufbauen lassen, Hauptsache es läuft.
Es gibt eben nach wie vor Gegenstellen die nach wie vor kein IPv6 haben bzw. ein Tarifwechsel erforderlich wäre. Unabhängig davon gibt es noch 1-2 Szenarieren, wo ebenfalls kein IPv6 nutzbar ist.Wegen CGNAT!
Wobei man hier unterscheiden muss, ob es eine eingehende oder ausgehende Verbindung ist. Ersteres dürfte bei CGNAT nicht funktionieren. Letzteres hingegen schön.@aqui
Hat dein WG Setup auf dem Server als auch auf dem Client denn auch ein gültiges IPv6 Setup??
Ja, sonst würde eine IPv6 only Verbindung, wie oben beschrieben, nicht funktionieren.@LordGurke
Wird eine IPv6- und eine IPv4-Adresse eingetragen, versucht Wireguard auch in IPv4 only Netzen verzweifelt, eine IPv6-Verbindung aufzubauen. Ein Failover ist schlicht nicht vorgesehen.
War zu dem Zeitpunkt auf der Netzwerkkarte des Geräts das IPv6 Protokoll aktiviert oder deaktiviert?Deshalb verhält sich Wireguard vermutlich auch bei DNS-Namen so, dass IPv4 immer bevorzugt verwendet wird. Aber auch nur der erste A-Record der kommt - wenn man hier Redundanz durch DNS-RR schaffen will, scheitert man ebenfalls an Wireguard.
Daher die Idee für den Server Endpoint zwei Subdomains, SubA mit einem A Eintag, SubB mit einem AAAA Eintrag. Das würde bedeuten, dass ich im WireGuard Client zwei Profile habe. Einziger Unterschied der FQDN im Entpunkt. Somit muss allerdings der User gefordert.Wenn du da eine funktionierende Lösung hast, dann solltest du sie nicht durch Wireguard ersetzen. Wenn du die Lösung ersetzen musst, dann ist Wireguard bestenfalls die letzte Option.
Die aktuelle Lösung basiert auf OPNsense (IPSec + IKEv2). Allerdings erfolgt der Tunnelaufbau und die Kommunikation im Tunnel ausschließlich über IPv4. Zum damaligen Zeitpunkt haben wir den Tunnelaufbau über IPv6, Kommunikation innerhalb des Tunnels über IPv4, nicht zum Fliegen gebracht. Kumpel hat das Ganze aufgebaut und hat auch mit OPNsense Community Kontakt gehabt. Bekomm es leider nicht mehr ganz zusammen.Nun haben seit Monaten immer wieder massive Probleme. Man sieht bei MTRs ganz klar, dass es die Peerings von ISP A zu ISP B einfach immer wieder voll sind. Die DTAG ist hier noch am auskunftsfreudlichsten. Vodafone und die regional Provider stellen sich tot oder schmeißen mit Textbausteinen um sich.
Gruß,
Dani
