Heimserver trotz DS-Lite per IPv6 freigeben

Warum das unter DS-Lite überhaupt geht

Bei DS-Lite (Dual-Stack Lite) teilst du dir die öffentliche IPv4-Adresse mit vielen anderen Kunden, aber die meisten Anschlüsse bekommen zusätzlich natives, öffentliches IPv6. Dein Heimserver hat damit bereits eine weltweit gültige Adresse. Es fehlt nur eine Freigabe in der FRITZ!Box. Du musst dafür nichts mieten und nichts tunneln.

Der Grund liegt in der Technik dahinter. Deine IPv4-Pakete laufen über einen Übersetzer beim Provider, den AFTR (Address Family Transition Router). Der bedient sehr viele Kunden gleichzeitig und kann bei einer Verbindung von außen nicht wissen, zu welchem Kunden sie gehört. Deshalb bleibt jede IPv4-Portfreigabe in der FRITZ!Box wirkungslos. Auf der IPv6-Seite gibt es diesen Übersetzer nicht: Dein Anschluss bekommt ein eigenes Präfix, jedes Gerät bildet daraus seine eigene öffentliche Adresse, und das Einzige, was den Zugriff von außen verhindert, ist die Firewall der FRITZ!Box.

Ich schreibe bewusst „die meisten“. Es gibt DS-Lite-Anschlüsse, auf denen IPv6 nicht nutzbar ist, und es gibt Provider, die Präfixe anders vergeben als der Anbieter nebenan. Behauptungen über Präfix-Lebensdauern, Zwangstrennungen oder einzelne Tarife stehen hier bewusst nicht drin, weil sie sich von Anbieter zu Anbieter unterscheiden. Lies das für deinen Anschluss in den Hilfeseiten deines Providers nach, und prüfe deine Leitung zuerst selbst.

Hat dein Anschluss wirklich öffentliches IPv6?

Zwei Prüfungen, eine im Browser und eine auf dem Server.

Rufe auf einem Gerät im Heimnetz test-ipv6.com oder ipv6-test.com auf. AVM verweist in seiner eigenen Wissensdatenbank auf genau diese beiden Seiten. Eine volle IPv6-Bewertung bedeutet: Der Anschluss hat IPv6, und dein Gerät benutzt es auch.

Auf dem Server selbst gehen zwei Befehle:

ip -6 addr show scope global
ip -6 route get 2001:4860:4860::8888

Der erste Befehl muss mindestens eine Adresse zeigen, die mit 2 oder 3 beginnt, zum Beispiel 2a02:…. Adressen, die mit fe80: beginnen, sind link-local und gelten nur im lokalen Netzsegment. Adressen, die mit fd beginnen, sind ULA-Adressen (unique local address) und werden im Internet nicht geroutet. Der zweite Befehl zeigt, welche Quelladresse der Kernel für einen Weg ins Internet wählen würde. Antwortet er mit Network is unreachable, hat der Server keinen IPv6-Weg nach draußen, und alles Weitere in dieser Anleitung läuft ins Leere.

Schritt 1: Der Server braucht eine stabile IPv6-Adresse

Eine IPv6-Adresse besteht aus zwei Hälften. Vorne steht das Präfix, das die FRITZ!Box vom Provider bekommt. Hinten steht die Interface-ID, die das Gerät selbst bildet. Das Präfix kann sich bei einer neuen Internetverbindung ändern, und dagegen kannst du nichts tun. Die Interface-ID dagegen muss konstant bleiben, denn die Freigabe in der FRITZ!Box wird auf genau diese ID gesetzt.

Im Auslieferungszustand bleibt sie das nicht. Privacy Extensions nach RFC 4941 erzeugen zusätzliche temporäre Adressen mit wechselnder Interface-ID, und ausgehende Verbindungen bevorzugen diese temporären Adressen. Ein Server, der von außen erreichbar sein soll, braucht das Gegenteil.

Unter NetworkManager kommt ein zweites Problem dazu. Im Modus stable-privacy bildet NetworkManager die Interface-ID nach RFC 7217 aus einem Hash, und in diesen Hash geht laut Dokumentation das Adresspräfix ein. Wechselt das Präfix deines Anschlusses, wechselt deshalb auch die Interface-ID. Die Adresse ist dann stabil pro Netz, aber nicht stabil über einen Präfixwechsel hinweg, und genau darauf kommt es hier an.

Zuerst der Blick auf den Ist-Zustand:

ip -6 addr show dev eth0

Jede Zeile, die mit inet6 beginnt und hinten das Flag temporary trägt, ist eine solche Wegwerfadresse. Wenn dort mehrere globale Adressen stehen, weißt du schon, warum die Freigabe später mal geht und mal nicht.

Auf Systemen mit NetworkManager, etwa Raspberry Pi OS oder Debian mit Desktop, stellst du beides in einem Befehl um:

nmcli connection show
sudo nmcli connection modify "Wired connection 1" ipv6.addr-gen-mode eui64 ipv6.ip6-privacy 0
sudo nmcli connection up "Wired connection 1"

Auf Systemen mit systemd-networkd, etwa Ubuntu Server, trägst du es in die passende Datei unter /etc/systemd/network/ ein:

[Network]
IPv6AcceptRA=yes
IPv6PrivacyExtensions=no

Danach sudo systemctl restart systemd-networkd und noch einmal ip -6 addr show dev eth0. Übrig bleiben soll eine einzige globale Adresse ohne temporary.

Im Modus eui64 leitet der Kernel die Interface-ID aus der MAC-Adresse der Netzwerkkarte ab. Sie bleibt also, solange die Netzwerkkarte bleibt. Tauschst du die Karte, klonst du eine virtuelle Maschine oder aktivierst du MAC-Zufallswerte, ändert sich die Interface-ID, und die Freigabe musst du neu setzen.

Notiere dir jetzt die Interface-ID. Das sind die letzten vier Blöcke der Adresse. Aus 2a02:8071:abcd:1200:1a2b:3cff:fe4d:5e6f ist das 1a2b:3cff:fe4d:5e6f. Bei einem Fertiggerät wie einem NAS findest du die Einstellung, falls vorhanden, in dessen eigener Netzwerkkonfiguration. Gibt es dort keine, lies die Adresse in der FRITZ!Box unter Heimnetz, Netzwerk beim jeweiligen Gerät ab und prüfe über mehrere Tage, ob die hintere Hälfte gleich bleibt.

Schritt 2: Genau einen Port in der FRITZ!Box per IPv6 freigeben

Die Beschriftungen unten stammen aus der AVM-Wissensdatenbank, geprüft im September 2026, und entsprechen der Oberfläche von FRITZ!OS 8.2x. AVM nennt in den Artikeln selbst keine Versionsnummer. Welche Version deine Box hat, steht auf der Übersichtsseite der Benutzeroberfläche. Weicht eine Beschriftung ab, suche nach dem gleichlautenden Begriff, nicht nach der gleichen Position.

AVM nennt drei Voraussetzungen: Die FRITZ!Box muss vom Internetanbieter eine IPv6-Adresse bekommen, das Gerät oder der Serverdienst muss IPv6 unterstützen, und der Zugriff ist nur von IPv6-Internetzugängen aus möglich. Der letzte Punkt ist kein Detail, sondern die Grenze dieses ganzen Ansatzes. Dazu unten mehr.

1. Rufe http://fritz.box auf und melde dich an.
2. Klicke auf Internet, dann auf Freigaben, dann auf den Reiter Portfreigaben.
3. Klicke auf „Gerät für Freigaben hinzufügen“.
4. Wähle deinen Server in der Ausklappliste „Name“ aus.
5. Klicke auf „Neue Freigabe“, wähle Portfreigabe und setze die Freigabe auf IPv6.
6. Trage Protokoll und Port ein, zum Beispiel TCP und 443, und bestätige mit OK.
7. Speichere die Einstellungen mit „Übernehmen“.

In der Ausklappliste „Name“ listet die FRITZ!Box laut AVM die Netzwerkgeräte auf, die ihre IPv6-Einstellungen automatisch von der Box beziehen. Genau hier scheitern viele: Ein Server, der seine Adresse ausschließlich per SLAAC aus den Router-Advertisements bildet, taucht dort nicht auf. Für diesen Fall gibt es den Eintrag „Benutzerdefiniert“. Dann trägst du Namen und Interface-ID des Geräts von Hand ein, und zwar genau die vier Blöcke, die du in Schritt 1 notiert hast.

Nach dem Speichern zeigt die Freigabenliste eine Spalte „Port extern vergeben“. Steht dort dein Port, hat die FRITZ!Box die Regel angelegt. Steht dort nichts, ist die Regel nicht aktiv, und du brauchst gar nicht erst von außen zu testen.

Gib genau einen Port für genau ein Gerät frei. Jede zusätzliche Regel ist eine zusätzliche Tür ins Heimnetz, und die Box erzwingt keine Begründung für ihre Existenz.

Schritt 3: Ein DynDNS-Name, der die AAAA des Servers aktualisiert

Deine öffentliche Serveradresse ist Präfix plus Interface-ID. Die Interface-ID steht jetzt fest, das Präfix nicht. Wechselt es, ändert sich die vollständige Adresse deines Servers, und ein gespeicherter Link zeigt ins Nichts.

Der naheliegende Griff zur DynDNS-Seite der FRITZ!Box hilft hier nicht. Unter Internet, Freigaben, DynDNS meldet die Box ihre eigenen Adressen an den Anbieter, und MyFRITZ! ist dafür da, die Box selbst erreichbar zu machen. Du brauchst aber einen AAAA-Eintrag, der auf die Adresse deines Servers zeigt, nicht auf die der Box. Die zuverlässigste Lösung ist deshalb: Der Server meldet sich selbst.

Als Beispiel dient deSEC mit seiner dynDNS-Schnittstelle unter update6.dedyn.io, die laut Dokumentation IPv6 erzwingt. Andere Anbieter funktionieren genauso, nur mit anderer URL und anderen Parameternamen. Lege das Token mit sudo install -m 600 /dev/null /etc/dedyn.token an und schreibe es hinein. Dann ein kleines Skript unter /usr/local/bin/dyndns-update.sh:

#!/bin/sh
set -eu
IFACE=eth0
DOMAIN=meinserver.dedyn.io
ADDR=$(ip -6 addr show dev "$IFACE" scope global -temporary -deprecated \
  | awk '/inet6/ {print $2}' | cut -d/ -f1 | head -n1)
test -n "$ADDR"
curl -fsS --user "$DOMAIN:$(cat /etc/dedyn.token)" \
  "https://update6.dedyn.io/?myipv6=$ADDR"

Mach es mit sudo chmod 755 /usr/local/bin/dyndns-update.sh ausführbar und führe es einmal von Hand aus. Eine erfolgreiche Antwort ist good. Danach ein Timer, damit es nach jedem Präfixwechsel von allein passiert. /etc/systemd/system/dyndns.service:

[Unit]
Description=AAAA-Eintrag beim DynDNS-Anbieter aktualisieren
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/dyndns-update.sh

Und /etc/systemd/system/dyndns.timer:

[Unit]
Description=DynDNS alle fünf Minuten aktualisieren

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now dyndns.timer
systemctl list-timers dyndns.timer

list-timers muss eine Zeile mit einem Zeitpunkt in der nahen Zukunft zeigen. Steht dort nichts, läuft der Timer nicht, und dein Name veraltet beim nächsten Präfixwechsel.

So lange dauert ein Wechsel im Alltag: Der Server bemerkt das neue Präfix erst beim nächsten Lauf des Timers, danach muss der alte AAAA-Eintrag noch aus den Caches der Auflöser verschwinden. Das Ergebnis ist eine Lücke von einigen Minuten, in der Zugriffe von außen scheitern. Kürzer wird sie durch einen kurzen TTL-Wert beim DNS-Anbieter und einen häufigeren Timer, ganz verschwinden wird sie nicht. Wann dein Anschluss überhaupt ein neues Präfix bekommt, siehst du in der FRITZ!Box unter System, Ereignisse in den Meldungen zur Internetverbindung.

Schritt 4: Die Firewall auf dem Server zählt getrennt für IPv6

Die FRITZ!Box lässt die Verbindung jetzt durch. Ob der Server sie annimmt, ist eine zweite Frage. AVM nennt das in seinem Artikel zu fehlgeschlagenen Portfreigaben ausdrücklich als Ursache: Läuft der Dienst auf einem Gerät mit eigener Firewall, muss diese ebenfalls eingerichtet sein.

Bei ufw ist die häufigste Falle eine Regel mit Quellangabe. sudo ufw allow from 192.168.178.0/24 to any port 443 passt auf kein einziges IPv6-Paket, weil die Quelle dort eine IPv4-Angabe ist. Der Besucher von außen läuft dann in die Default-Policy und bekommt gar keine Antwort. Prüfe mit sudo ufw status verbose, ob zu jeder Regel auch eine Zeile mit (v6) existiert, und ob in /etc/default/ufw die Zeile IPV6=yes steht. Die Details dazu, inklusive der Reihenfolge der Regeln, stehen in Ports für IPv6 in ufw richtig öffnen und werden hier nicht wiederholt.

Ebenso wichtig ist, worauf der Dienst überhaupt lauscht:

sudo ss -tlnp | grep ':443'

0.0.0.0:443 bedeutet: nur IPv4. Eine IPv6-Verbindung wird dort niemals ankommen, egal wie richtig die Freigabe ist. [::]:443 bedeutet IPv6, und unter Linux in der Standardeinstellung zusätzlich IPv4. Viele Dienste binden sich ohne ausdrückliche Konfiguration nur an IPv4, und das ist der Grund, warum der Test von außen ein Connection refused liefert statt eines Timeouts.

Schritt 5: Von außen testen, und was jeder Fehler bedeutet

Teste niemals aus dem eigenen Heimnetz. Du brauchst eine Gegenstelle, die selbst IPv6 hat. Mobilfunk ist dafür meistens geeignet, aber eben nicht immer. Rufe deshalb auf dem Handy zuerst test-ipv6.com im Mobilfunknetz auf, mit ausgeschaltetem WLAN. Erst wenn diese Seite IPv6 bestätigt, ist ein Fehlschlag aussagekräftig.

Dann, auf einem Rechner am Handy-Hotspot:

dig AAAA meinserver.dedyn.io +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://meinserver.dedyn.io/

Jedes Fehlerbild hat eine eigene Ursache.

dig gibt nichts zurück: Der DynDNS-Eintrag wurde nie gesetzt. Führe das Update-Skript von Hand aus und lies die Antwort.

dig gibt eine Adresse zurück, deren vordere Hälfte nicht zum aktuellen Präfix passt: Der Timer läuft nicht. Prüfe systemctl list-timers und journalctl -u dyndns.service -n 20.

curl meldet Network is unreachable oder Couldn't connect to server, obwohl die Adresse stimmt: Deiner Gegenstelle fehlt IPv6. Das ist kein Fehler auf deiner Seite.

curl bleibt hängen und endet im Timeout: Die Verbindung erreicht den Server nicht. Kontrolliere in der FRITZ!Box die Spalte „Port extern vergeben“ und vergleiche die eingetragene Interface-ID Zeichen für Zeichen mit der aktuellen Adresse des Servers. AVM nennt zwei weitere Ursachen, die man selten auf dem Schirm hat: Ist der Internetzugriff des Geräts durch die Kindersicherung eingeschränkt, ist kein Zugriff von außen möglich, und der NetBIOS-Filter blockiert die Ports für Datei- und Druckerfreigaben grundsätzlich.

curl meldet Connection refused: Die Freigabe funktioniert, der Server lehnt ab. Zurück zu ss -tlnp und zur Firewall aus Schritt 4.

Wenn der Besucher gar kein IPv6 hat

Hier endet der Weg ohne Miete. Ein Dienst, der nur über IPv6 erreichbar ist, ist für ein IPv4-only-Netz unsichtbar. Das betrifft viele Firmennetze, viele Hotel-WLANs und manche Mobilfunktarife. Du kannst daran von zu Hause aus nichts ändern, denn dir fehlt die öffentliche IPv4-Adresse, auf der so ein Besucher ankommen könnte.

Es gibt zwei ehrliche Brücken, und beide kosten Vertrauen oder Geld.

Die erste ist ein Portmapper-Dienst. Ein Anbieter mit öffentlicher IPv4-Adresse nimmt die Verbindung entgegen und leitet sie an deine IPv6-Adresse weiter. Damit hängt die Erreichbarkeit deines Servers am Betrieb dieses Anbieters, und sein Ausfall ist dein Ausfall. Der Anbieter sieht außerdem, wer wann wohin verbindet. Der Inhalt bleibt geschützt, solange TLS (transport layer security) erst auf deinem Server endet und nicht beim Anbieter. Feste-IP.net betreibt einen solchen Portmapper für DS-Lite- und IPv6-Anschlüsse, geprüft im September 2026, und beschreibt ihn als Weg, vom Smartphone oder einem IPv4-Anschluss aus wieder auf Geräte hinter einer DS-Lite-Anbindung zuzugreifen.

Die zweite Brücke betreibst du selbst: ein kleiner VPS mit öffentlicher IPv4-Adresse als eigener Vermittler. Er nimmt IPv4-Verbindungen an und reicht sie an deinen Heimserver weiter. Die robuste Variante ist dabei nicht die Weiterleitung an deinen DynDNS-Namen, sondern ein Tunnel, den dein Heimserver von sich aus zum VPS aufbaut, denn der überlebt Präfixwechsel ohne DNS-Umweg. Wie das im Detail aussieht, steht in einem Reverse-Tunnel über einen VPS hinter CGNAT. Wenn du weder den einen noch den anderen Weg willst, bleibt die Variante ganz ohne offenen Port, beschrieben in einem Tunnel, der ohne jede Portfreigabe auskommt. Auch dort gilt: Ein Dritter steht im Weg, und du entscheidest bewusst, dass dir das recht ist.

Was du dir mit der Freigabe einhandelst

Eine IPv6-Freigabe veröffentlicht einen Dienst im gesamten Internet. Die Vorstellung, eine 128 Bit lange Adresse sei zu lang zum Erraten, ist als Schutz wertlos, sobald du einen DynDNS-Namen benutzt: Der Name steht öffentlich im DNS. Holst du dir ein TLS-Zertifikat, erscheint der Hostname zusätzlich in den Certificate-Transparency-Logs, die jeder abfragen kann. Von der Veröffentlichung bis zum ersten fremden Verbindungsversuch vergehen erfahrungsgemäß Stunden, nicht Monate.

Daraus folgt: Für den Heimserver gelten dieselben Regeln wie für jeden Server mit öffentlicher Adresse. HTTPS statt HTTP, weil sonst Zugangsdaten im Klartext über fremde Netze laufen. Regelmäßige Updates, weil ein bekannter Fehler in einer Weboberfläche automatisiert ausgenutzt wird. Und eine Begrenzung für Anmeldeversuche, sonst probiert ein Botnetz unbegrenzt Passwörter durch. Wie du das für SSH einrichtest, steht in fail2ban gegen Brute-Force-Angriffe auf SSH, und derselbe Mechanismus lässt sich auf die Logdatei deiner Weboberfläche anwenden.

Ein Dienst ohne eigene Anmeldung gehört nicht ins Internet, auch nicht per IPv6, auch nicht auf einem ungewöhnlichen Port. Für solche Fälle ist der Weg über einen Tunnel oder ein VPN der richtige, nicht die Portfreigabe.

FAQ

Woran erkenne ich, ob mein DS-Lite-Anschluss öffentliches IPv6 hat?

Rufe auf einem Gerät im Heimnetz test-ipv6.com oder ipv6-test.com auf. AVM verweist in seiner Wissensdatenbank auf beide Seiten. Auf einem Linux-Server prüfst du es mit ip -6 addr show scope global. Eine Adresse, die mit 2 oder 3 beginnt, ist global gültig. Adressen mit fe80: am Anfang sind link-local, Adressen mit fd am Anfang sind private ULA-Adressen. Beide werden im Internet nicht geroutet.

Mein Server war erreichbar und ist es plötzlich nicht mehr. Was ist passiert?

In den meisten Fällen hat dein Anschluss ein neues Präfix bekommen, und der DynDNS-Eintrag zeigt noch auf die alte Adresse. Prüfe mit dig AAAA deinname +short, ob die vordere Hälfte der Adresse zur aktuellen Adresse des Servers passt, und mit systemctl list-timers, ob der Update-Timer läuft. Die zweite häufige Ursache ist eine gewechselte Interface-ID, etwa weil Privacy Extensions wieder aktiv sind oder die Netzwerkkarte eine andere MAC-Adresse benutzt. Dann stimmt die in der FRITZ!Box eingetragene Interface-ID nicht mehr.

Warum erreiche ich meinen Server aus dem Büro nicht?

Weil dieses Netz vermutlich nur IPv4 kann. AVM schreibt das als Voraussetzung ausdrücklich hin: Der Zugriff ist nur von IPv6-Internetzugängen aus möglich. Du kannst das von deiner Seite aus nicht reparieren, denn unter DS-Lite hast du keine eigene öffentliche IPv4-Adresse. Es bleiben ein Portmapper-Dienst oder ein eigener VPS mit IPv4-Adresse als Vermittler.

Reicht MyFRITZ! statt eines eigenen DynDNS-Eintrags?

MyFRITZ! und die DynDNS-Funktion der FRITZ!Box sind darauf ausgelegt, die Adressen der Box selbst zu veröffentlichen. Für eine Freigabe auf deinem Server brauchst du einen AAAA-Eintrag, der auf die Adresse dieses Geräts zeigt. Ein Update, das der Server selbst auslöst, hat außerdem den Vorteil, dass es genau die Adresse meldet, die er gerade wirklich benutzt, und es funktioniert unabhängig davon, ob deine Box einen bestimmten Dienst unterstützt.