FRITZ!Box-VPN über IPv6 aus IPv4-Netzen: Direkt unmöglich, mit Tailscale lösbar

Die WireGuard-Schlüssel sind fehlerfrei generiert, die MyFRITZ!-Adresse ist erreichbar und die heimische FRITZ!Box läuft störungsfrei. Trotzdem bleibt der Tunnelaufbau im Hotel, im ICE-WLAN oder im Firmennetzwerk stumm. Es fließen keine Daten, und der Status meldet beharrlich: kein Handshake.

In den meisten Fällen liegt der Fehler weder an falschen Schlüsseln noch an einer verpatzten Portfreigabe. Wenn der heimische Internetanschluss über DS-Lite oder reines IPv6 angebunden ist, während das fremde Netzwerk ausschließlich IPv4 bereitstellt, scheitert der Verbindungsversuch nicht am VPN selbst, sondern an der Straße davor: Ein Gerät, das nur IPv4 spricht, kann kein Paket an eine IPv6-Adresse zustellen. Wer das Problem dauerhaft lösen will, muss aufhören, an den WireGuard-Parametern der FRITZ!Box zu drehen – und stattdessen den Transportweg reparieren.

Der Tunnel scheitert vor dem ersten WireGuard-Paket

Um die Ursache zu verstehen, hilft ein Blick auf die beiden beteiligten Netzwerke:

Viele moderne Glasfaser-, Kabel- oder DSL-Anschlüsse nutzen heute DS-Lite (Dual-Stack Lite). Dabei erhält die FRITZ!Box eine weltweit erreichbare, öffentliche IPv6-Adresse, teilt sich aber für herkömmliche IPv4-Verbindungen eine Adresse mit Hunderten anderen Kunden des Anbieters (Carrier-Grade NAT). Eingehende IPv4-Verbindungen von außen prallen an dieser Barriere ab.

Befindet sich das Notebook oder Smartphone nun in einem reinen IPv4-Netz – wie es in Hotels, Zügen, Gäste-WLANs oder vielen Mobilfunknetzen nach wie vor üblich ist –, kann das Gerät technisch schlicht keine Pakete an eine IPv6-Zieladresse absenden. AVM formuliert diese Voraussetzung in der offiziellen Wissensdatenbank zu DS-Lite eindeutig: Eingehende IPv6-Verbindungen zu einer FRITZ!Box sind zwar uneingeschränkt möglich, setzen aber zwingend voraus, dass auch der zugreifende Internetanschluss über eine funktionierende IPv6-Anbindung verfügt (AVM Wissensdatenbank zu DS-Lite).

Hierbei werden oft zwei Dinge verwechselt:

1. Das äußere Transportprotokoll: Wie erreichen sich der Client unterwegs und die FRITZ!Box zu Hause über das offene Internet?

2. Der innere Tunnelverkehr: Welche IP-Adressen erhalten die Geräte innerhalb des verschlüsselten Tunnels?

Wenn der äußere Weg fehlt, kommt es gar nicht erst zur Verschlüsselung. Gemäß der WireGuard-Spezifikation (WireGuard: Quick Start) muss der Endpunkt des Gegenübers über das bestehende Netz adressierbar sein, um den kryptografischen Handshake durchzuführen. Auch MyFRITZ! ändert daran nichts: Der Dienst fungiert lediglich als Telefonbuch, das die aktuelle IPv6-Adresse der FRITZ!Box auflöst. Ein DNS-Dienst übersetzt jedoch keine IPv4-Datenpakete in IPv6.

Vier Anzeigen zeigen, ob wirklich IPv4 gegen IPv6 steht

Bevor man die Netzwerkstruktur umbaut, lässt sich in wenigen Schritten prüfen, ob man es tatsächlich mit dieser Konstellation zu tun hat:

1. Heimanschluss prüfen: Auf der FRITZ!Box-Oberfläche unter Internet > Online-Monitor nachsehen. Steht dort „IPv4 über DS-Lite“ oder fehlt eine öffentlich geroutete IPv4-Adresse, während ein IPv6-Präfix aktiv ist, ist der Router von außen nur via IPv6 direkt erreichbar.

2. MyFRITZ!-Auflösung kontrollieren: Außerhalb des Heimnetzes prüfen (etwa über ein DNS-Abfragetool), welche Einträge für die MyFRITZ!-Adresse hinterlegt sind. Findet sich dort ausschließlich ein AAAA-Eintrag (IPv6) und kein A-Eintrag (IPv4), haben reine IPv4-Clients keine Zieladresse.

3. Fremdes Netz testen: Auf dem Client-Gerät im fremden Netzwerk über eine Testseite wie Testseite test-ipv6.com prüfen, ob echtes IPv6 ins Internet gelangt. Lokale IPv6-Adressen genügen nicht; der Test muss eine funktionierende globale Verbindung bestätigen.

4. WireGuard-Protokoll ansehen: Zeigt die WireGuard-App nach dem Aktivieren dauerhaft „Neuester Handshake: Keiner“ an, während gesendete Pakete steigen, aber keine empfangen werden, erreicht der Client den Endpoint physikalisch nicht.

Sobald feststeht, dass der Client nur über IPv4 sendet und die FRITZ!Box nur über IPv6 lauscht, sind weitere Änderungen an Schlüsseln oder Ports vergebene Liebesmüh.

Die beste direkte Lösung: Eine gemeinsame Adressfamilie schaffen

Der sauberste und performanteste Weg führt über eine direkte Verbindung ohne zusätzliche Zwischenstationen. Bevor komplizierte Relays aufgesetzt werden, sollten drei direkte Ansätze geprüft werden:

IPv6 auf Client-Seite nutzen: Häufig stellt das Smartphone im Mobilfunknetz bereits natives IPv6 bereit. Wer das Notebook kurzerhand mit dem mobilen Hotspot verbindet, umgeht das veraltete IPv4-Hotelnetz und erreicht die heimische IPv6-FRITZ!Box sofort auf direktem Weg per WireGuard.

Echtes Dual Stack beim Provider buchen: Viele Internetanbieter schalten auf Nachfrage, gegen einen geringen Aufpreis oder über einen Business-Tarif eine vollwertige, öffentlich erreichbare IPv4-Adresse frei. Damit erhält die FRITZ!Box wieder ein weltweites IPv4-Ziel, und alle WireGuard-Probleme unterwegs lösen sich in Luft auf.

Den Internetzugang wechseln: Ist der regelmäßige Zugriff auf das Heimnetz beruflich unverzichtbar, lohnt sich bei anstehenden Vertragsverlängerungen der gezielte Wechsel zu einem Provider, der standardmäßig Dual Stack mit öffentlichen Adressen für beide Protokolle bereitstellt.

Können jedoch weder der Heimanschluss eine öffentliche IPv4-Adresse noch das entfernte Netz IPv6 erhalten, ist die direkte FRITZ!Box-Verbindung an ihren physikalischen Grenzen angelangt. In diesem Fall wird ein Vermittler benötigt.

Wenn beide Netze feststehen: Ein Tailscale-Subnet-Router gewinnt

Muss die Brücke zwischen einem reinen IPv4-Netzwerk und einem reinen IPv6-Heimanschluss geschlagen werden, ist ein sogenannter Subnet-Router über Tailscale die praxistauglichste Lösung (Tailscale Docs: Subnet routers, Tailscale-Dokumentation zu Subnet Routers).

Das Prinzip umgeht das Grundproblem der FRITZ!Box: Statt darauf zu warten, dass jemand von außen anklopft, baut ein kleines Gerät im heimischen LAN – etwa ein dauerhaft laufender Raspberry Pi, ein sparsamer Mini-PC oder ein ohnehin aktives Synology-NAS – von innen heraus eine Verbindung zum Tailscale-Koordinationsserver auf. Da ausgehende Verbindungen über DS-Lite problemlos funktionieren, ist das Heimnetzwerk sofort Teil eines verschlüsselten Mesh-Netzwerks.

Konfiguriert man dieses Gerät als „Subnet Router“, reicht es den gesamten IP-Bereich der FRITZ!Box (beispielsweise 192.168.178.0/24) an die berechtigten Geräte weiter. Befindet sich der Laptop nun im IPv4-only-Hotelnetz, verbindet er sich ebenfalls ausgehend mit Tailscale.

Können sich die beiden Geräte wegen inkompatibler Protokolle nicht direkt verbinden, greift automatisch das integrierte DERP-Relay-System von Tailscale (Tailscale Docs: DERP servers, Tailscale-Dokumentation zu DERP-Servern). Diese Server beherrschen Dual Stack, nehmen den verschlüsselten Datenverkehr von der IPv4-Seite an und leiten ihn über IPv6 an den Subnet-Router zu Hause weiter. Weder offene Ports noch eine öffentliche IPv4-Adresse an der FRITZ!Box sind dafür erforderlich.

Für versierte Linux-Administratoren existiert als Alternative der Betrieb eines eigenen kleinen Virtual Private Servers (VPS) mit Dual Stack, der als WireGuard-Drehscheibe dient. Dieser Ansatz verlangt jedoch regelmäßige Sicherheitsupdates, manuelle Firewall-Konfigurationen und IP-Routing-Pflege. Für die allermeisten Anwender ist Tailscale daher der deutlich wartungsärmere Weg.

Wichtig: Den Zweck nicht verwechseln

An dieser Stelle muss eine klare Trennlinie gezogen werden: Ein Overlay-Netzwerk wie Tailscale dient dazu, das private Heimnetz aus der Ferne erreichbar zu machen.

Geht es einem Reisenden im offenen Hotel-WLAN dagegen gar nicht darum, auf heimische Dateien, den Netzwerkdrucker oder das Smart-Home zuzugreifen, sondern schlicht darum, den eigenen Internetverkehr gegen Mitleser abzusichern oder deutsche Streaming-Dienste stabil zu nutzen, ist der Umweg über das heimische Netzwerk oft unnötig komplex. Für diesen reinen Absicherungsfall nach außen ist ein klassischer Dienst wie OnlydogVPN^↗ die geradlinigere Wahl. Er schützt den ausgehenden Datenverkehr auf Windows, macOS, Android und iOS, fängt Netzschwankungen automatisch ab und erspart den Aufbau eigener Vermittlungsknoten im Wohnzimmer. Heimische Netzlaufwerke erreicht man damit allerdings nicht – dafür bleibt der Subnet-Router zuständig.