FB7590 + WireGuard + Dual Stack = Kein IPv6-Traffic über VPN?

[Darkman.X]

EDIT:
Hat sich erledigt. Ich denke, dass es normal ist, dass IPv6-Traffic nicht über die VPN-Verbindung geht. VPN-Login über IPv6 geht, aber es kann danach nur IPv4-Traffic übermittelt werden.
Das ist ok, so lange Internetanschlüsse noch IPv4-Verbindungen haben (an denen die Fritzbox hängt) und Internetseiten über IPv4 erreichbar sind. Somit ist es aktuell nur ein theoretisches Problem.

Der Betreff ist auch (im Nachhinein) ungünstig gewählt, weil ich dachte, dass das irgendwie an einem vollwertigen Dual-Stack-Anschluss liegt.

---

---

Hallo zusammen,

ich habe etwas mit WireGuard rumgespielt und mir sind da etwas im Zusammenhang mit IPv6 aufgefallen. Bevor ich mich an den AVM-Support wende, wollte ich erstmal hier fragen, ob das Problem bekannt ist oder ob hier ein Bedien-/Denkfehler von mir vorliegt.

Mir geht es um IPv6 über VPN. Fritzboxen können seit FRITZ!OS 7.50 über WireGuard (und IPSec) nun auch VPN-Verbindungen über IPv6 herstellen.
Ich habe zu Hause eine Fritzbox 7590 (FW 7.56) und einen vollwertigen Dual-Stack-Anschluss (o2-DSL).
Und ich habe am Handy einen o2-Vertrag mit IPv4 + IPv6.

Kurzfassung:
Ich kann zwar über IPv6 eine VPN-Verbindung herstellen, aber ich kann darüber keine IPv6-Daten übermitteln (der normale Traffic, z.B. Webseiten nur mit IPv6 aufbauen).

Lange Version:
Mir ist bei meinen Tests aufgefallen, dass in der WG-Config-Datei / QR-Code, denn die FB erzeugt, unter "AllowedIPs" nur IPv4-Adressen auflistet sind (192.168.1.0/24,0.0.0.0/0), das häufig gelesene "::/0" (für den gesamten IPv6-Traffic) fehlt.
Wenn ich damit am Handy die VPN-Verbindung einrichte und aktiviere, dann habe ich laut Android und Testseiten nur eine IPv4-Adresse. Internet funktioniert damit grundsätzlich, aber reine IPv6-Testseiten (z.B. www.six.heise.de) lassen sich nicht aufrufen. Am PC (direkt an der FB angeschlossen) kann ich die reine IPv6-Seite ohne Probleme aufrufen.
Ich hatte am Handy in der WG-App testweise händisch das "::/0" unter "AllowedIPs" eingetragen und die VPN-Verbindung danach neu aufgebaut, aber keine Besserung.


Danach hatte ich zum Testen die WG-Verbindung in der FB gelöscht und unter Internet -> Zugangsdaten -> IPv6 von "Native IPv4-Anbindung verwenden" auf "Nur IPv6 verwenden" umgestellt. Die FB stellte danach eine reine IPv6-Internetverbindung her.

Danach nochmal eine WG-Verbindung in der FB eingerichtet und es wurden unter "AllowedIPs" wieder nur IPv4-Adressen auflistet (192.168.1.0/24,0.0.0.0/0). Und ein Test am Handy zeigte auch, dass IPv6 (egal ob mit oder ohne "::/0") nicht funktionierte.
Am Handy oder dessen Verbindung scheint das Problem nicht zu liegen. Ich kann im FB-Log sehen, dass das Handy über IPv6 eine Verbindung zur FB aufgebaut hatte. Aber es lief abseits der Authentifizierung kein Traffic darüber. Ich hatte am Handy dann gar kein Internet, egal ob mit IPv4- oder IPv6-Seiten.

So.....was nun? Liegt hier ein Bug vor? Oder funktionieren IPv6-WG-Verbindungen (inkl. Traffic) nur, wenn die Fritzbox eine IPv4-Adresse per DS-Lite / CGNAT erkennt? Mache ich etwas falsch?

Gruß
Darkman.X

Ergänzung (30. Juli 2023)

Je länger ich darüber nachdenke, umso mehr komme ich zum Schluss, dass es vermutlich so gewollt ist.

Das Problem vor FW 7.50 war ja, dass man über IPv6 keine Verbindung zum Fritzbox-VPN herstellen kann. Das wurde mit 7.50 behoben.

Aber es ist wohl nicht gewollt, dass der IPv6-Traffic über die VPN-Verbindung läuft. Deshalb hatte ich beim 2. Test (FB stellt nur eine reine IPv6-Internetverbindung her) auch dann gar keinen Seitenaufbau am Handy. Die FB hatte keine IPv4-Verbindung, worüber sie den IPv4-VPN-Traffic ins Internet weiterleiten konnte.

 

[_anonymous0815_]

Hat sich erledigt. Ich denke, dass es normal ist, dass IPv6-Traffic nicht über die VPN-Verbindung geht. VPN-Login über IPv6 geht, aber es kann danach nur IPv4-Traffic übermittelt werden.
Das ist ok, so lange Internetanschlüsse noch IPv4-Verbindungen haben (an denen die Fritzbox hängt) und Internetseiten über IPv4 erreichbar sind. Somit ist es aktuell nur ein theoretisches Problem.

Ich glaube das theoretische Problem ist eher ein praktischer Verbindungs- oder Konfigurationsfehler. Wireguard KANN definitiv eine dedizierte IPv6-Verbindung zwischen Fritz!Box und Endgerät herstellen.


https://avm.de/service/wissensdaten...eine-VPN-Verbindung-zur-FRITZ-Box-herstellen/

Falls Du sicher bist, dass Dual Stack auf der Fritz!Box richtig konfiguriert ist, überprüfe am besten nochmal die Wireguard-Konfiguration und die IPv6-Konfiguration auf dem Endgerät.

Das kann man z.B. über diese Seite testen:
http://www.test-ipv6.com/

Und hier wird eine beispielhafte Config für IPv4 und IPv6 gezeigt: https://www.hosting.de/helpdesk/anleitungen/server/wireguard_server/

Ich selbst habe es noch nicht über IPv6 gemacht, aber die Zeichen sind klar, dass es geht. Dediziert wenn Du die Config so anpasst, dass nur über v6 eine Verbindung aufgebaut wird oder eben DualStack.

Ergänzung (31. Juli 2023)

Du verwendest doch sicherlich DynDNS, oder? Kann dieser Service IPv4 und 6? Ich bin z.B. bei noip und meine DynDNS-Adresse hat nur IPv4 hinterlegt, das wäre bei mir schon der Punkt, wo sich vermutlich auf IPv4 festgelegt wird.

Dann was mir auffällt, Du musst natürlich auch eine IPv6 für das wg0 interface auf dem Client (z.B. Smartphone) hinterlegen. Da sich das /56 oder /64 Präfix des ISPs bei jedem neuen Verbindungsaufbau ändert, kannst Du keine global gültige, statische IPv6 für das wg0 Interface vergeben. Also ISP-Präfix+Custom-Suffix.

Da kann es vonnöten sein, in den Netzwerkeinstellungen für IPv6, Unique Local Addresses (ULA) für alle IPv6 Interfaces im Netzwerk zu aktivieren. Dh. Dass Du auf jedem Interface DREI IPv6-Adressen hast. Nämlich die global gültige mit dem ISP-Präfix welches sich mit jeder Verbindung ändert, die Unique Local und eine Link Locale.

Die ULA zeichnet sich dadurch aus, dass sie quasi der statischen, privaten IPv4 Adresse wie 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 entspricht.

Du vergibst ein Präfix, dafür gibt es Richtlinien wie das zu beginnen hat:
https://www.ipv6-handbuch.de/Plakate/plakat-ipv6-unicast-adressen-20141208001.pdf

Und das Suffix wird aus der Mac-Adresse (48 Bit) und dem Zusatz ff:fe erstellt.

24BitMac:ff:fe:24BitMac

Aber das ist auch nur Theorie meinerseits, vielleicht liegt der Fehler auch ganz wo anders.

Wenn Du damit experimentierst, empfiehlt es sich immer, vorher die Config der Box zu sichern, um sie im Notfall wiederherstellen zu können. Aber das ist ja nichts Neues.

 

[Darkman.X]

Das kam vielleicht falsch rüber. Ich sehe die Ursache des "Problems" nicht bei WireGuard, sondern an der Umsetzung von AVM. Ich gehe davon aus und hatte auch im Internet gelesen, dass WG mit IPv6 umgehen kann.

Ich gehe von einer AVM-Ursache aus, weil das IPSec-VPN von denen funktioniert auch nur mit IPv4, kein IPv6-Traffic darüber möglich.
Und bei WG geht AVM auch einen eigenen Weg: Die nutzen nicht ein separates Subnet, wie es sonst bei WG normal ist (korrigiere mich, wenn ich falsch liege), sondern im gleichen Subnet wie die Fritzbox und alle LAN/WLAN-Clients.

Das kann man z.B. über diese Seite testen:
http://www.test-ipv6.com/

Am Festnetzanschluss (DSL) und am Handy (über Mobilfunk!) 10 von 10 Punkten.

Und hier wird eine beispielhafte Config für IPv4 und IPv6 gezeigt: https://www.hosting.de/helpdesk/anleitungen/server/wireguard_server/

Ich selbst habe es noch nicht über IPv6 gemacht, aber die Zeichen sind klar, dass es geht. Dediziert wenn Du die Config so anpasst, dass nur über v6 eine Verbindung aufgebaut wird oder eben DualStack.

Am "Server" (die Fritzbox) kann ich an den Einstellungen nichts ändern, die GUI erlaubt es nicht. Vielleicht geht es über Umwege mit "Fritzbox Tools" oder "Fritzbox JSTool", womit man direkt auf der FB oder über eine modifizierte exportierte Config-Datei einiges ändern kann, aber soweit wollte ich eigentlich nicht gehen. Ich könnte es theoretisch, aber es geht ja auch um ein generelles Problem.

Das ist auch der Grund, warum ich nicht weiter auf deine IPv6-Einstellungen (Aktivierung der ULA usw.) eingehe. Das bringt ja leider nichts, wenn man an der WG-Config auf dem "Server" nichts ändern kann. Und meinem Verständnis nach bringt es nichts, wenn ich die Config ausschließlich am Client/Peer ändere.

Du verwendest doch sicherlich DynDNS, oder? Kann dieser Service IPv4 und 6?

Ich nutze den Dienst von AVM: MyFritz.net. Das kann IPv4 und IPv6.

 

[riversource]

Richtig, AVM unterstützt im Tunnel bislang kein IPv6. Nur für die Tunnelübertragung wird IPv6 unterstützt, z.B. an DS-Lite oder CGNAT Anschlüssen.

 

[c303]

Ich hole das mal aus den Untiefen heraus ...

Ist zu dem Thema schon was bekannt? Bei mir geht es auch nicht, selbst mit einem dahinter liegenden eigenen WireGuard Server.

IPv4 ohne Probleme.
IPv6 geht kein Traffic ins Internet raus. Also durch das VPN meine ich.

 

[Darkman.X]

Es geht in dem Thread um die Wireguard-Umsetzung von AVM/Fritz.
Da du einen eigenen Wireguard-Server verwendest, hast du eine ganz andere Problemursache und du solltest einen neuen Thread erstellen.

Zum ursprünglichen Problem gibt es bisher keine Änderung. Eine WG-Verbindung zur Fritzbox kann über IPv6 hergestellt werden; es können auch an der Fritzbox angeschlossene Geräte über IPv6 angesprochen werden, aber es ist kein Weiterleitung von IPv6-Paketen ins Internet möglich.

Siehe auch https://fritz.com/apps/knowledge-ba...t-die-FRITZ-Box-IPv6-Netzwerkverkehr-uber-VPN

 

[c303]

In Ordnung.

 

[Avenger84]

Das Problem ist das nötige NAT für IPv6 ins Internet.
Ich verwende seit Jahren (noch bevor es Wireguard für FB gab) Wireguard in Linux.

Damit die Endgeräte über mein Zuhause ins Internet über IPv6 kommen verwende ich Source NAT:

PostUp = nft add table ip6 nat
PostUp = nft add chain ip6 nat postrouting '{ type nat hook postrouting priority srcnat; policy accept; }'
PostUp = nft add rule ip6 nat postrouting ip6 saddr { fd08::2, fd08::3, fd08::4, fd08::5 } oifname "enp1s0" counter masquerade

Im Internet habe ich dann die IPv6 Adresse der Linux VM.
IPv4 NAT macht die FB ganz normal, auch für VPN Geräte.

Hilft für Wireguard über FB vermutlich nicht, aber wollte es erwähnt haben ;-)

 

[c303]

Ich habe das so gelöst auf einem Ubuntu. Das ist aber in der Tat nicht das Thema hier, nur falls es jemand Interessiert.

Wichtig ist, in meinem Beispiel:
FritzBox = ULA-Präfix manuell festlegen = fd00/64
fd00:10::1/64 in der WireGuard config ist ein anderes Subnetz!

Das ULA-Präfix fd00::/8 (davon fd00::/64 als Subnetz) und die Adresse fd00:10::1/64 in der WireGuard-Konfiguration gehören tatsächlich zu unterschiedlichen Subnetzen, wenn das FritzBox-ULA-Präfix festgelegt ist als fd00::/64 und WireGuard eine Adresse aus fd00:10::/64 verwendet.

Das Subnetz fd00::/64 und fd00:10::/64 sind nicht identisch, da fd00:10::/64 eine andere Adresse im Bereich von fd00:0000:0010::/64 ist, also ein separates ULA-Subnetz.

Ergo, wenn in der FritzBox das ULA-Präfix fd00::/64 manuell verwendet wird und in WireGuard fd00:10::1/64, sind das verschiedene Subnetze. Man kann sagen, sie gehören nicht zum selben Subnetz, sondern zu eigenständigen ULA-Subnetzen. Das funktioniert technisch, wenn man unterschiedliche ULA-Subnetze für unterschiedliche Zwecke oder Netzsegmente nutzt.

Kurz: fd00::/64 und fd00:10::/64 sind unterschiedliche Subnetze, ja.

vi /etc/wireguard/wg0.conf

# WireGuard Server
[Interface]
PrivateKey =    dein_privater_Schlüssel
Address =       10.0.0.1/24, fd00:10::1/64
ListenPort =    51820

PostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE; iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT; iptables -A FORWARD -i eth0 -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT; ip6tables -t nat -A POSTROUTING -s fd00:10::/64 -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -o eth0 -j ACCEPT; ip6tables -A FORWARD -i eth0 -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT

PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE; iptables -D FORWARD -i wg0 -o eth0 -j ACCEPT; iptables -D FORWARD -i eth0 -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT; ip6tables -t nat -D POSTROUTING -s fd00:10::/64 -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -o eth0 -j ACCEPT; ip6tables -D FORWARD -i eth0 -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Client 1
[Peer]
PublicKey =     dein_öffentlicher_Schlüssel
AllowedIPs =    10.0.0.2/32, fd00:10::2/128

Mit der config hat man dann nativ IPv4 und IPv6 wenn man dem Client bei AllowedIPs dann die

0.0.0.0/0, ::/0

mitgibt - so wie es sich halt gehört.

Test z.B. mit https://frankfurt.test-ipv6.com
PS: https://www.google.com/intl/en/ipv6/statistics.html

 

[Avenger84]

bei IPv4 arbeite ich komplett ohne NAT in der WG-Konfig, kann ich nur empfehlen, gerade wenn man (wie ich) zusätzlich noch 3 verschiedenen Netzwerke miteinander verbunden hat und nachvollziehen will wer sich wo eingeloggt hat.

 

[c303]

Und jeder Client hat seine eigene IPv4 Adresse, oder machste das über Ports?

 

[Avenger84]

jeder Client hat seine Wireguard IPv4 und IPv6 wie bei dir auch:

[Peer]
PublicKey =
AllowedIPs = 192.168.99.2/32, fd08::2/128
[Peer]
PublicKey =
AllowedIPs = 192.168.99.3/32, fd08::3/128
[Peer]
PublicKey =
AllowedIPs = 192.168.99.4/32, fd08::4/128
[Peer]
PublicKey =
AllowedIPs = 192.168.99.5/32, fd08::5/128
[Peer]
PublicKey =
AllowedIPs = 192.168.99.10/32, 192.168.99.20/32, 192.168.74.0/24, 192.168.75.0/24
AllowedIPs = fd08::10/128, fd08::20/128, fd00:bbbb::/64, fd00:cccc::/64

2-5 sind Mobilgeräte die auch ins Internet gelangen.
10 ist eine Brücke zu Netzwerk B.

Angenommen ich logge mich vom Smartphone (99.2) aus in ein Gerät Zuhause ein, dann steht in dem Log dass sich ..99.2 eingeloggt hat. Falls ich mich per IPv6 einlogge steht dann nicht fd08::2 im Log wegen IPv6 SRCNAT sondern die ULA der VM.
Generell sollte man so wenig NAT wie möglich betreiben.

Die Brücke in Netz B & C arbeitet ohne NAT, d.h. wenn ich mich von Netz C per IPv6 in ein Gerät aus A oder B einlogge steht dort die jeweilig korrekte ULA also fd00:cccc::...
daher auch nur 2-5 NAT:

nft add rule ip6 nat postrouting ip6 saddr { fd08::2, fd08::3, fd08::4, fd08::5 } oifname "enp1s0" counter masquerade

und nicht fd08::10.

Wenn ich mit dem Smartphone bei browserleaks.com schaue, werden mir dort die korrekten Local IP Adress: 192.168.99.2 und fd08::2 angezeigt. Public IP die IPv4 vom ISP und IPv6 die GUA von der VM.

Wenn ich keine dynamische IPv6 bekommen würde (die sich alle 24h ändert), könnte ich auch IPv6 ins Internet ohne NAT machen.

 

[c303]

Ahso, ich dachte du hast für jeden IPv4 Client auch eine öffentliche IPv4 Adresse, was ja technisch gesehen kein Problem wäre.