Wer auf einer FritzBox einen WireGuard-VPN-Tunnel betreibt und der Gegenstelle einen DDNS-Hostnamen statt einer festen IP-Adresse mitteilt, erlebt mitunter eine frustrierende Situation: Der Tunnel kommt nicht zustande – obwohl die Konfiguration korrekt aussieht. Der Grund liegt häufig daran, dass der Hostname intern auf eine private IPv6-ULA-Adresse aufgelöst wird, die außerhalb des lokalen Netzes nicht erreichbar ist. Dieser Artikel erklärt das Problem und zeigt, wie man es behebt.
Das Symptom: VPN-Zugang eingerichtet, aber kein Tunnel
Im FritzBox-Ereignisprotokoll erscheinen in schneller Folge zwei Einträge:
18:42:55 VPN-Zugang eingerichtet.
18:43:00 Internetverbindung IPv6 wurde erfolgreich hergestellt.
IP-Adresse: fd55:4fa6:4d53::1eed:6fff:feb1:72c2
Die FritzBox meldet zwar, dass der VPN-Zugang eingerichtet wurde, ein echter Datenaustausch über den Tunnel findet aber nicht statt. Auf der Gegenseite – etwa einem pfSense- oder OPNsense-Router – laufen keine Handshakes ein.
Die Ursache: ULA-Adresse statt globaler IPv6
Der entscheidende Hinweis versteckt sich in der IPv6-Adresse, die das Protokoll ausgibt: fd55:4fa6:4d53::1eed:6fff:feb1:72c2. Das Präfix fd kennzeichnet eine sogenannte Unique Local Address (ULA) – das IPv6-Äquivalent zu privaten RFC-1918-Adressen (10.x.x.x, 192.168.x.x). Diese Adressen sind nicht im Internet routbar.
Was passiert konkret? Die FritzBox löst den im WireGuard-Peer hinterlegten DDNS-Hostnamen (z. B. mein-homelab.ipv64.net) lokal über DNS auf. Die FritzBox versucht nun, den WireGuard-Tunnel zu dieser ULA-Adresse aufzubauen – was außerhalb des eigenen Segments sinnlos ist und scheitert.
Globale vs. lokale IPv6-Adressen auf einen Blick
- Präfix fc00::/7 (fd…, fc…) → ULA – privat, nicht im Internet routbar
- Präfix 2000::/3 (z. B. 2a01:…, 2003:…) → Globale Unicast-Adresse (GUA) – öffentlich erreichbar
- Präfix fe80::/10 → Link-Local – nur im selben Netzsegment gültig
Warum erkennt die FritzBox das Problem nicht?
Die FritzBox führt keine Plausibilitätsprüfung durch, ob die aufgelöste IP-Adresse tatsächlich über das WAN erreichbar ist. Sie nimmt das DNS-Ergebnis, schreibt es als Endpunkt in die WireGuard-Konfiguration und meldet im Protokoll lapidar VPN-Zugang eingerichtet. Das klingt nach Erfolg – ist es aber nicht. Ein tatsächlicher Verbindungsaufbau (Handshake) wird gar nicht erst versucht oder scheitert still.
Lösung: DNS-Auflösung für den WireGuard-Endpoint korrigieren
Es gibt mehrere Ansätze, um das Problem zu beheben. Welcher passt, hängt von der eigenen Netzinfrastruktur ab.
Option 1: Direkt die globale IPv6-Adresse eintragen (schnellste Lösung)
Falls die öffentliche IPv6-Adresse des WireGuard-Servers bekannt ist und sich selten ändert, kann man sie direkt als Endpoint in der FritzBox hinterlegen – ohne Hostnamen. Dann entfällt die DNS-Auflösung komplett. Bei dynamischer IPv6 ist das aber keine dauerhafte Lösung.
Option 2: IPv4 als WireGuard-Endpunkt verwenden
Ist IPv4 für den WAN-Anschluss verfügbar (kein reines DS-Lite), kann man den DDNS-Hostnamen so konfigurieren, dass er nur einen A-Record (IPv4) liefert und keinen AAAA-Record (IPv6). Die FritzBox baut den WireGuard-Tunnel dann über IPv4 auf – stabiler und einfacher zu debuggen.
