Tailscale mit der FRITZ!Box: wo der Client wirklich läuft

Warum die FRITZ!Box kein Tailscale-Knoten wird

Tailscale mit der FRITZ!Box heißt immer: Tailscale läuft auf einem anderen Gerät, nie auf der Box selbst. FRITZ!OS ist ein geschlossenes System. AVM erlaubt keine Fremdsoftware, es gibt keinen Paketmanager und keinen Shell-Zugang, und einen Tailscale-Client für FRITZ!OS gibt es nicht. Die eigentliche Frage lautet deshalb nicht „wie installiere ich Tailscale auf der FRITZ!Box“, sondern „wo neben der FRITZ!Box sitzt der Knoten, und was muss die Box dafür wissen“.

Drei Antworten sind ehrlich. Erstens: kein Tailscale, sondern das WireGuard, das FRITZ!OS seit Version 7.50 mitbringt. Zweitens: ein Tailscale Subnet-Router auf einem Gerät im Heimnetz, der 192.168.178.0/24 in das Tailnet hebt. Drittens: ein VPS als dauerhaft erreichbarer Knoten oder Exit Node, wenn beide Seiten hinter Carrier-Grade NAT stecken. Welche Variante passt, entscheidet vor allem dein Internetanschluss, genauer: ob die FRITZ!Box eine öffentliche IPv4-Adresse hat.

Falls Tailscale für dich neu ist: Tailscale ist ein Overlay-Netz auf WireGuard-Basis mit zentraler Schlüsselverteilung. Jedes Gerät bekommt eine feste Adresse aus 100.64.0.0/10, und die Verbindungen laufen direkt von Gerät zu Gerät, ohne dass ein Port am Router geöffnet werden muss.

Zuerst prüfen: hat die FRITZ!Box eine öffentliche IPv4-Adresse?

Öffne in der FRITZ!Box-Oberfläche „Internet“ > „Online-Monitor“. Dort steht, wie die Box mit dem Internet verbunden ist. Steht bei IPv4 der Hinweis „DS-Lite“, teilt sich dein Anschluss eine IPv4-Adresse mit vielen anderen Kunden. Das ist auf vielen Kabelanschlüssen und auf den meisten LTE- und 5G-Heimtarifen der Normalfall. Über IPv4 kann dann niemand von außen eine Verbindung zur Box aufbauen, weil die Pakete beim Provider enden und nicht bei dir.

Steht dort eine gewöhnliche öffentliche IPv4-Adresse, meist bei DSL und Glasfaser, ist Option A ohne Einschränkung möglich. Steht dort DS-Lite, hängt Option A davon ab, ob deine Clients IPv6 haben. Option B und C funktionieren in beiden Fällen, weil sie keine eingehende Verbindung brauchen.

Option A: das WireGuard der FRITZ!Box, ganz ohne Tailscale

Seit FRITZ!OS 7.50 kann die FRITZ!Box selbst WireGuard-Server sein. Wenn du nur von einem Laptop und einem Handy aus nach Hause willst, ist das der kürzeste Weg, und du brauchst dafür kein Tailscale-Konto.

Die Einrichtung läuft komplett in der Oberfläche der Box. Zuerst brauchst du einen DynDNS-Namen, weil sich die öffentliche Adresse des Anschlusses ändert. AVM liefert ihn kostenlos über MyFRITZ!: „Internet“ > „MyFRITZ!-Konto“, E-Mail-Adresse eintragen, übernehmen. Danach legst du die VPN-Verbindung an: „Internet“ > „Freigaben“ > Reiter „VPN (WireGuard)“ > „Verbindung hinzufügen“ > „Vereinfachte Einrichtung“. Am Ende lädst du eine .conf-Datei herunter oder scannst einen QR-Code mit der WireGuard-App. Wichtig: AVM verlangt, dass die erste WireGuard-Verbindung aus dem Heimnetz heraus eingerichtet wird, nicht aus der Ferne.

Die .conf ist eine gewöhnliche WireGuard-Konfiguration. Hinter Endpoint steht dein MyFRITZ!-Name und der UDP-Port, den die Box für diese Verbindung geöffnet hat. Genau dieser eine Port ist alles, was Option A nach außen zeigt. WireGuard antwortet auf Pakete ohne gültigen Schlüssel gar nicht, ein Portscan sieht den Port also nicht. Wer die .conf besitzt, ist aber im Heimnetz. Behandle die Datei wie einen Schlüssel und lege für jedes Gerät eine eigene Verbindung an, damit du ein verlorenes Handy einzeln löschen kannst.

Was Option A nicht kann: Sie scheitert hinter DS-Lite, sobald der Client kein IPv6 hat. Die FRITZ!Box nimmt WireGuard-Verbindungen laut AVM über IPv4 und über IPv6 an, also auch am DS-Lite-Anschluss. Nur muss der Client die IPv6-Adresse der Box dann auch erreichen können. In einem Hotel-WLAN ohne IPv6 oder bei manchen Mobilfunkanbietern ist das nicht der Fall, und der Handshake bleibt einfach still. Im Protokoll der WireGuard-App steht dann nur Handshake for peer 1 (...) did not complete after 5 seconds, retrying, ohne weitere Erklärung, weil aus Sicht des Clients niemand antwortet.

Zweite Grenze: Was durch den Tunnel geht, ist bis FRITZ!OS 7.x nur IPv4. Seit FRITZ!OS 8 transportiert die Box auch IPv6 durch WireGuard ins Heimnetz, allerdings nur für Verbindungen, die unter FRITZ!OS 8 neu angelegt wurden (Stand September 2026). Eine alte Verbindung bekommt das nicht nachträglich, du musst sie löschen und neu anlegen.

Wenn Option A für dich reicht, brauchst du den Rest dieses Beitrags nicht. Willst du dagegen verstehen, was die Box in AllowedIPs einträgt und warum das Handy danach alles über zu Hause routet, erklärt WireGuard-Routing ins eigene Heimnetz denselben Aufbau mit einem selbst geschriebenen Server.

Option B: ein Tailscale Subnet-Router im Heimnetz

Das ist die Variante, die die meisten Leute eigentlich meinen, wenn sie „Tailscale auf der FRITZ!Box“ suchen. Ein kleines Gerät im LAN tritt dem Tailnet bei und meldet dort: „192.168.178.0/24 erreichst du über mich“. Danach erreicht jedes Tailnet-Gerät jeden Drucker, jede NAS, jede Kamera und die FRITZ!Box-Oberfläche selbst, ohne dass eines dieser Geräte von Tailscale weiß.

Als Subnet-Router taugt alles, was dauerhaft läuft und Linux kann: ein Raspberry Pi, eine Synology- oder QNAP-NAS mit dem Tailscale-Paket, eine VM oder ein Container unter Proxmox, oder Home Assistant mit dem Tailscale-Add-on. Die Befehle unten gelten für ein Debian- oder Ubuntu-System, etwa den Pi. Auf NAS und Home Assistant klickst du dieselben Optionen in deren Oberfläche an.

Gib dem Gerät zuerst eine feste Adresse, sonst zeigt die statische Route aus dem nächsten Abschnitt irgendwann auf ein Gerät, das es nicht mehr gibt: „Heimnetz“ > „Netzwerk“, das Gerät bearbeiten, Haken bei „Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen“. Im Beispiel bekommt der Pi 192.168.178.50.

Dann installierst du Tailscale und schaltest das Weiterleiten von Paketen ein. Ohne die beiden sysctl-Zeilen nimmt der Kernel Pakete für 192.168.178.20 zwar an, wirft sie aber weg, weil sie nicht an ihn selbst adressiert sind.

curl -fsSL https://tailscale.com/install.sh | sh
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale up --advertise-routes=192.168.178.0/24

tailscale up gibt eine Login-URL aus. Öffne sie im Browser und melde das Gerät an deinem Tailnet an. Die Route ist damit angeboten, aber noch nicht freigegeben. Das passiert in der Admin-Konsole unter „Machines“: das Gerät auswählen, „Edit route settings“, den Haken bei 192.168.178.0/24 setzen, speichern. Diese Freigabe vergessen fast alle beim ersten Mal. Das Symptom: tailscale status auf dem Laptop zeigt den Pi als online, aber ping 192.168.178.1 bekommt keine Antwort, weil der Laptop die Route nie bekommen hat.

Auf Linux-Clients ist noch ein zweiter Schalter nötig, weil Linux angebotene Routen aus Sicherheitsgründen nicht automatisch übernimmt:

sudo tailscale set --accept-routes
ping -c 3 192.168.178.1

Antwortet die FRITZ!Box, steht der Weg. Windows, macOS, iOS und Android übernehmen Routen ohne diesen Schalter. Wie sich derselbe Aufbau auf einem VPS statt auf einem Pi verhält, und was sich ändert, wenn der Router selbst in der Cloud steht, beschreibt Tailscale Subnet-Router auf einem VPS.

Nach außen zeigt Option B nichts. Die FRITZ!Box hat keinen offenen Port und keine Freigabe. Der Pi baut ausgehende UDP-Verbindungen auf, Tailscale handelt über die Koordinationsserver einen direkten Pfad aus, und wenn das an einem strengen NAT scheitert, läuft der Verkehr verschlüsselt über einen DERP-Relay. Warum das der Portfreigabe vorzuziehen ist, steht in Tailscale statt Portfreigabe.

Die statische Route auf der FRITZ!Box: wann du sie brauchst

Standardmäßig tauscht der Subnet-Router die Absenderadresse aus (Source NAT). Der Drucker sieht eine Anfrage vom Pi, nicht von 100.101.102.103, und antwortet dem Pi. Das funktioniert ohne jede Änderung an der FRITZ!Box und reicht für den Zugriff von außen nach innen.

Eine statische Route brauchst du erst, wenn ein Gerät im Heimnetz, das selbst kein Tailnet-Mitglied ist, eine Verbindung zu einem Tailnet-Knoten aufbauen soll. Typisches Beispiel: die NAS soll ein Backup auf den VPS unter 100.x.y.z schieben, oder Home Assistant soll einen Dienst auf dem Laptop abfragen. Die NAS kennt 100.64.0.0/10 nicht, schickt das Paket an ihr Standard-Gateway, also an die FRITZ!Box, und die Box schickt es ins Internet, wo es verloren geht.

Die Route sagt der Box, dass 100.64.0.0/10 über den Pi erreichbar ist: „Heimnetz“ > „Netzwerk“ > Reiter „Netzwerkeinstellungen“ > „weitere Einstellungen“ > „IPv4-Routen“ > „Neue IPv4-Route“. Trage als „IPv4-Netzwerk“ 100.64.0.0 ein, als „Subnetzmaske“ 255.192.0.0, als „Gateway“ 192.168.178.50, setze „IPv4-Route aktiv“ und übernimm. 255.192.0.0 ist die Maske eines /10; ein Tippfehler zu 255.255.0.0 deckt nur 100.64.0.0/16 ab, und jeder Knoten mit einer höheren Adresse bleibt unerreichbar.

Dazu gehört auf dem Pi das Abschalten des Source NAT, sonst sieht der antwortende Tailnet-Knoten weiterhin nur den Pi:

sudo tailscale set --snat-subnet-routes=false

Ohne die Route ist --snat-subnet-routes=false sogar schädlich: Die NAS bekäme dann Pakete von 100.x-Adressen, wüsste den Rückweg nicht, und die Verbindung bliebe halb offen. Beides zusammen oder nichts von beidem.

Option C: der VPS als Exit Node oder Treffpunkt

Ein VPS löst ein anderes Problem als der Subnet-Router. Tailscale kommt hinter DS-Lite und CGNAT auch ohne VPS aus, notfalls über einen Relay. Der VPS ist dann sinnvoll, wenn du eine öffentliche IPv4-Adresse brauchst, die immer erreichbar ist, oder eine feste Adresse, mit der dein Verkehr im Internet auftritt.

Drei Fälle, in denen der VPS gewinnt. Erstens, Exit Node: Im Hotel-WLAN soll der gesamte Verkehr des Laptops über eine vertrauenswürdige Adresse ins Netz. Ein Exit Node zu Hause geht auch, hängt aber am Upload deines Anschlusses. Der VPS hat symmetrische Bandbreite und ist nie gerade offline, weil der DSL-Anschluss die Zwangstrennung durchläuft. Auch auf dem VPS braucht der Kernel dafür die beiden sysctl-Zeilen von oben.

sudo tailscale up --advertise-exit-node

Auch das muss in der Admin-Konsole unter „Edit route settings“ mit „Use as exit node“ freigegeben werden. Auf dem Laptop wählst du ihn mit sudo tailscale set --exit-node=<Tailnet-IP des VPS>. Die Details, samt Firewall und dem Verhalten bei IPv6, stehen in Tailscale Exit Node auf einem VPS.

Zweitens, beide Seiten hinter CGNAT und ein Gegenüber ohne Tailscale: Ein Freund soll dein Home-Assistant-Dashboard im Browser öffnen, ohne ein Tailnet-Konto. Dann brauchst du irgendwo eine öffentliche Adresse, hinter der ein Dienst aus deinem Heimnetz sichtbar wird, und das ist genau der Fall für einen umgekehrten Tunnel vom Heimnetz zum VPS. Wie der aufgebaut wird und was er im Vergleich zu Tailscale nach außen zeigt, steht in VPS Reverse-Tunnel hinter CGNAT. Hier nur die Einordnung: Der Subnet-Router bringt dich ins Heimnetz, der Reverse-Tunnel bringt einen einzelnen Dienst aus dem Heimnetz heraus. Es sind zwei Werkzeuge für zwei Richtungen.

Drittens, Dienste, die nicht zu Hause laufen sollen: Ein Passwortmanager oder ein Git-Server, der auch dann erreichbar sein soll, wenn zu Hause der Strom weg ist. Der VPS ist dann einfach ein normaler Tailnet-Knoten mit sudo tailscale up, und der Subnet-Router zu Hause bleibt, was er ist.

Ob eine Verbindung direkt läuft oder über einen Relay, siehst du auf jedem Knoten:

tailscale status
tailscale ping 100.101.102.103

tailscale status zeigt hinter jedem aktiven Peer entweder direct mit Adresse und Port oder relay mit dem Kürzel des DERP-Standorts, etwa relay "fra" für Frankfurt. tailscale ping schickt mehrere Pakete und meldet in jeder Zeile, ob die Antwort via DERP oder über eine direkte Adresse kam. Bleibt es dauerhaft beim Relay, erklärt warum Tailscale über den Relay langsam ist und wie du einen direkten Pfad bekommst die Ursachen.

Typische Fehler mit der FRITZ!Box

Zwei Haushalte, beide auf 192.168.178.0/24

Jede FRITZ!Box kommt ab Werk mit 192.168.178.1 und dem Netz 192.168.178.0/24. Sobald zwei FRITZ!Box-Haushalte im selben Tailnet je einen Subnet-Router haben, bieten beide dasselbe Netz an. Tailscale kann das nicht auflösen. Es wählt nach dem längsten passenden Präfix, und bei zwei identischen /24 gewinnt einer, ohne dass du steuern kannst, welcher. Dasselbe Problem hast du mit dem Laptop zu Besuch bei Freunden mit FRITZ!Box: Deren LAN und deine Tailnet-Route zeigen auf dasselbe Ziel.

Der saubere Weg ist, eines der Netze umzustellen, und zwar das, an dem weniger feste Adressen hängen. „Heimnetz“ > „Netzwerk“ > Reiter „Netzwerkeinstellungen“, dort unter „IP-Adressen“ die Schaltfläche „IPv4-Einstellungen“ (in älteren FRITZ!OS-Versionen heißt sie „IPv4-Adressen“). Wähle etwas, das anderen FRITZ!Boxen nicht begegnet, etwa 192.168.30.1 mit Maske 255.255.255.0. Meide 192.168.179.0/24, das nutzt die FRITZ!Box für ihr Gastnetz. Nach dem Übernehmen bist du kurz ausgesperrt, weil die Box unter der alten Adresse nicht mehr antwortet; die Clients holen sich per DHCP neue Adressen. Danach den Subnet-Router auf das neue Netz umstellen, mit sudo tailscale set --advertise-routes=192.168.30.0/24, und die Freigabe in der Admin-Konsole wiederholen.

Wer das Netz nicht anfassen darf, etwa im Elternhaus, kann Tailscales 4via6-Routen nutzen, die jedes überlappende IPv4-Netz auf einen eigenen IPv6-Bereich abbilden. Das funktioniert, macht aber jede Adresse zu einem langen IPv6-String, und die FRITZ!Box-Oberfläche heißt dann nicht mehr 192.168.178.1. Für einen Haushalt ist die Umstellung des Netzes fast immer der einfachere Weg.

fritz.box, MagicDNS und Split DNS

Im Heimnetz erreichst du Geräte als nas.fritz.box, weil der DNS-Server der FRITZ!Box diese Namen kennt. Über Tailscale kennt sie niemand: Dein Laptop im Hotel fragt seinen normalen Resolver, und der weiß nichts von deiner NAS. ping nas.fritz.box endet mit Name or service not known, obwohl ping 192.168.178.20 funktioniert.

Die Lösung heißt Split DNS. In der Admin-Konsole unter „DNS“ > „Add nameserver“ > „Custom“ trägst du 192.168.178.1 ein und setzt bei „Restrict to domain“ den Wert fritz.box. Ab dann schickt jedes Tailnet-Gerät nur Anfragen für Namen unter fritz.box an die FRITZ!Box, durch den Tunnel, über den Subnet-Router. Alle anderen Namen gehen weiter an den normalen Resolver. Voraussetzung: Die Route 192.168.178.0/24 muss freigegeben sein, sonst erreicht die DNS-Anfrage die Box nie und läuft in einen Timeout.

MagicDNS stört dabei nicht, weil es andere Namen vergibt. Ein Gerät, das selbst im Tailnet ist, heißt nas.dein-tailnet.ts.net und ist über diesen Namen auch dann erreichbar, wenn der Subnet-Router ausfällt. Ein Gerät, das nur im Heimnetz ist, heißt drucker.fritz.box und hängt am Subnet-Router. Beide Namen können nebeneinander existieren. Was passiert, wenn DNS-Anfragen am Tunnel vorbei ins Hotel-WLAN laufen, und wie du das prüfst, beschreibt DNS über WireGuard reparieren am Beispiel eines reinen WireGuard-Clients; die Mechanik ist bei Tailscale dieselbe.

IPv6: die FRITZ!Box verteilt globale Adressen

Die meisten deutschen Anschlüsse liefern heute ein IPv6-Präfix, und die FRITZ!Box gibt jedem Gerät im Heimnetz daraus eine global gültige Adresse. Tailscale nutzt das an zwei Stellen. Erstens bekommt jeder Knoten zusätzlich zu seiner 100.x-Adresse eine Tailnet-IPv6-Adresse aus fd7a:115c:a1e0::/48; die ist unabhängig vom Provider und ändert sich nie. Zweitens, und das ist der interessante Teil hinter DS-Lite: Tailscale verwendet die globale IPv6-Adresse des Pi als Transportweg. Zwei Geräte, die beide IPv6 haben, bauen darüber eine direkte Verbindung auf, auch wenn keines von beiden eine eigene IPv4-Adresse hat.

tailscale netcheck

Die Zeile IPv6: zeigt yes mit der eigenen Adresse in eckigen Klammern, darunter die Latenz zu den DERP-Standorten. Steht dort no, obwohl die FRITZ!Box IPv6 hat, prüfe unter „Internet“ > „Zugangsdaten“ > Reiter „IPv6“, ob die Box IPv6 überhaupt anfordert, und mit ip -6 addr auf dem Pi, ob er eine Adresse außerhalb fe80:: bekommen hat.

Was du nicht tun solltest: das globale /64-Präfix als Subnet-Route anbieten. Das ist technisch möglich, aber das Präfix wechselt bei vielen Providern mit jeder Neueinwahl, und dann zeigt die freigegebene Route auf ein Netz, das es nicht mehr gibt. Bleibe für Routen bei 192.168.178.0/24 und lass IPv6 das sein, was es hier am besten kann: der Transportweg, über den der Tunnel direkt statt über einen Relay läuft.

Was jede Option nach außen zeigt

Option A öffnet einen UDP-Port auf der FRITZ!Box. Dahinter steht AVMs WireGuard-Implementierung, die du nicht selbst aktualisieren kannst, sondern nur mit dem nächsten FRITZ!OS-Update bekommst. Wer die .conf hat, hat Zugriff auf das ganze Heimnetz. Deine Vertrauensanker sind die Box und dein MyFRITZ!-Konto.

Option B und C öffnen nichts. Der Vertrauensanker wandert dafür zu Tailscale: zu dem Identitätsanbieter, mit dem du dich anmeldest, und zu den Koordinationsservern, die Schlüssel und Routen verteilen. Sie sehen nie deinen Verkehr, aber sie entscheiden, welche Geräte einander kennen. Wer diesen Teil selbst betreiben will, ersetzt ihn durch Headscale, den selbst gehosteten Koordinationsserver, und behält die Clients, wie sie sind. Was Tailscale genau sieht und was nicht, steht in der Sicherheitsanalyse von Tailscale.

Keine der drei Varianten macht dich anonym. Dein Verkehr tritt im Internet mit der Adresse deines Anschlusses oder deines VPS auf, und beide sind auf deinen Namen registriert. Ein VPN nach Hause schützt dich vor dem Hotel-WLAN, nicht vor der Zuordnung zu deiner Person.

Welche Variante für wen

Öffentliche IPv4-Adresse und nur ein oder zwei Geräte: Option A, das WireGuard der FRITZ!Box, und du bist in zehn Minuten fertig.

DS-Lite oder LTE, mehrere Geräte, verschiedene Betriebssysteme, oder Geräte im Heimnetz, die selbst kein VPN können: Option B, ein Subnet-Router auf einem Pi oder der NAS. Das ist für die meisten Haushalte die richtige Antwort.

Dienste, die von außen ohne Tailnet-Konto erreichbar sein müssen, oder ein Knoten, der auch bei Stromausfall zu Hause weiterläuft: Option C, ein VPS, und zwar zusätzlich zu Option B, nicht statt ihrer.

FAQ

Kann ich Tailscale direkt auf der FRITZ!Box installieren?

Nein. FRITZ!OS erlaubt keine Fremdsoftware und hat keinen Shell-Zugang, und AVM bietet keinen Tailscale-Client an. Tailscale läuft auf einem Gerät im Heimnetz, etwa einem Raspberry Pi oder einer NAS, das als Subnet-Router das Netz 192.168.178.0/24 in das Tailnet hebt. Die FRITZ!Box selbst braucht dafür keine Änderung.

Funktioniert das WireGuard der FRITZ!Box hinter DS-Lite?

Nur über IPv6. Die FRITZ!Box nimmt WireGuard-Verbindungen über IPv4 und IPv6 an, aber am DS-Lite-Anschluss ist die IPv4-Adresse geteilt und von außen nicht erreichbar. Der Client muss also selbst IPv6 haben und die IPv6-Adresse der Box erreichen. In einem WLAN ohne IPv6 bleibt der Handshake ohne Antwort. Ob dein Anschluss DS-Lite nutzt, zeigt „Internet“ > „Online-Monitor“ in der FRITZ!Box.

Warum erreiche ich 192.168.178.1 nicht, obwohl der Subnet-Router online ist?

Meist fehlt die Freigabe der Route. tailscale up --advertise-routes bietet das Netz nur an; in der Admin-Konsole unter „Machines“ > „Edit route settings“ musst du es aktivieren. Auf Linux-Clients kommt sudo tailscale set --accept-routes dazu, weil Linux angebotene Routen nicht automatisch übernimmt. Der dritte Kandidat ist das fehlende net.ipv4.ip_forward = 1 auf dem Router: Dann kommen die Pakete an, werden aber verworfen.

Brauche ich die statische Route auf der FRITZ!Box wirklich?

Für Zugriff von außen nach innen nicht. Der Subnet-Router setzt standardmäßig Source NAT ein, und die Geräte im Heimnetz antworten ihm wie einem normalen Nachbarn. Die Route für 100.64.0.0/10 brauchst du erst, wenn ein Gerät im Heimnetz ohne eigenes Tailscale eine Verbindung zu einem Tailnet-Knoten aufbauen soll, etwa die NAS zum VPS. Dann gehören die Route auf der FRITZ!Box und --snat-subnet-routes=false auf dem Router zusammen.