VPS als IPv4-Portweiterleitung für DS-Lite-Anschluss (FritzBox = WireGuard-Server)

Diese Anleitung richtet einen VPS mit öffentlicher IPv4-Adresse als "Vorposten" für einen DS-Lite-Anschluss (z. B. sim.de) ein. Ziel: Dienste im Heimnetz (Webserver, NAS, etc.) sollen über die feste IPv4 des VPS von außen erreichbar sein, obwohl die FritzBox selbst nur eine wechselnde öffentliche IPv6-Adresse hat.

Architektur: Die FritzBox arbeitet als WireGuard-Server, der VPS als WireGuard-Client. Eingehender Traffic auf dem VPS wird per DNAT durch den Tunnel ins Heimnetz weitergeleitet.

Voraussetzungen

• VPS mit Debian/Ubuntu und fester öffentlicher IPv4-Adresse
• FritzBox ab FRITZ!OS 7.29 (WireGuard-Unterstützung), getestet mit FritzBox 7590 / FRITZ!OS 8.25
• Root- bzw. sudo-Zugriff auf dem VPS
• Zugriff auf die FritzBox-Oberfläche (fritz.box oder 192.168.178.1)
• Wichtig: Zugang zur Web-Konsole deines VPS-Providers (Hetzner Cloud Console, Netcup VNC, etc.) als Fallback, falls SSH während der Einrichtung ausfällt

Teil 1: MyFRITZ! aktivieren (Adressierbarkeit der FritzBox sicherstellen)

Da DS-Lite-Anschlüsse nur eine wechselnde öffentliche IPv6-Adresse haben, braucht der VPS einen festen Hostnamen, um die FritzBox jederzeit zu finden.

1. FritzBox-Oberfläche öffnen → Internet → MyFRITZ!-Konto
2. MyFRITZ!-Freigabe aktivieren (falls noch nicht geschehen)
3. Den zugewiesenen Hostnamen notieren, z. B. server.abcdefghijklmnop.myfritz.net

Dieser Hostname bleibt stabil, auch wenn sich die IPv6-Adresse der FritzBox ändert.

Teil 2: WireGuard-Verbindung auf der FritzBox anlegen

1. Internet → Freigaben → VPN (Freigaben) → VPN-Verbindung hinzufügen
2. Option für WireGuard, Verbindung für ein einzelnes Gerät/einen Nutzer wählen (nicht "Site-to-Site" – die Variante für ein einzelnes Gerät lässt die FritzBox eine fertige Konfigurationsdatei erzeugen, inkl. eigenem Schlüsselpaar)
3. Verbindung benennen (z. B. "VPS") und speichern
4. Die generierte Konfigurationsdatei herunterladen (z. B. vps.conf)

Warum diese Reihenfolge wichtig ist: Die FritzBox nutzt intern einen einzigen privaten Schlüssel für alle WireGuard-Verbindungen. Ein Import einer selbst erstellten Config mit fremdem PrivateKey schlägt mit der Fehlermeldung "Importierte Konfigurationsdatei der WireGuard-Gegenstelle löst einen Schlüsselkonflikt aus" fehl. Lässt man stattdessen die FritzBox die Config erzeugen, entfällt dieses Problem komplett.

Teil 3: Config auf den VPS übertragen

scp vps.conf root@<VPS-IP>:/etc/wireguard/wg0.conf

Datei ansehen:

sudo cat /etc/wireguard/wg0.conf

Typischer Inhalt (Beispielwerte):

[Interface]
PrivateKey = <von der FritzBox generiert>
Address = 192.168.178.203/24, fd41:2ff5:823c::203/64
DNS = 192.168.178.1

[Peer]
PublicKey = <Public Key der FritzBox>
Endpoint = server.abcdefghijklmnop.myfritz.net:51820
AllowedIPs = 192.168.178.0/24, 0.0.0.0/0, fd41:2ff5:823c::/64, ::/0

Diese Datei muss vor dem ersten Start an zwei Stellen zwingend angepasst werden (Teil 4 und 5) – sonst drohen die zwei häufigsten Fehler dieser Einrichtung.

Teil 4: DNS-Zeile entfernen (verhindert Startfehler)

wg-quick versucht bei einer vorhandenen DNS =-Zeile, das Tool resolvconf aufzurufen, um den DNS-Server systemweit einzutragen. Das ist auf den meisten schlanken VPS-Images nicht installiert und lässt den Dienst mit status=127 fehlschlagen.

sudo nano /etc/wireguard/wg0.conf

Zeile löschen:

DNS = 192.168.178.1

Der VPS braucht diesen DNS-Server nicht – er soll nur gezielt Pakete ins Heimnetz weiterleiten, nicht seinen eigenen DNS-Verkehr umleiten.

Teil 5: AllowedIPs einschränken (verhindert SSH-Aussperrung!)

Die von der FritzBox generierte Config enthält standardmäßig 0.0.0.0/0 und ::/0 in AllowedIPs. Das weist den VPS an, seinen gesamten Internet-Traffic – inklusive der laufenden SSH-Verbindung – durch den Tunnel zur FritzBox zu routen. Sobald der Tunnel steht, bricht SSH ab und der VPS ist nur noch über die Provider-Webkonsole erreichbar.

sudo nano /etc/wireguard/wg0.conf

Ersetze:

AllowedIPs = 192.168.178.0/24, 0.0.0.0/0, fd41:2ff5:823c::/64, ::/0

durch nur das Heimnetz-Subnetz (kein 0.0.0.0/0, kein ::/0):

AllowedIPs = 192.168.178.0/24, fd41:2ff5:823c::/64

Noch enger fassen (empfohlen): Willst du nur ein einzelnes Gerät erreichbar machen (z. B. deinen Webserver auf 192.168.178.163), trage nur dessen Adresse mit /32 ein:

AllowedIPs = 192.168.178.163/32

Damit ist ausschließlich dieses eine Gerät über den Tunnel erreichbar – alle anderen Geräte im Heimnetz (auch die FritzBox selbst) bleiben vom VPS aus unerreichbar. Mehrere einzelne Geräte lassen sich kommagetrennt ergänzen:

AllowedIPs = 192.168.178.163/32, 192.168.178.1/32

Teil 6: IP-Forwarding aktivieren

sudo nano /etc/sysctl.conf

Zeile einfügen/entkommentieren:

net.ipv4.ip_forward=1

Anwenden:

sudo sysctl -p

Teil 7: WireGuard-Tunnel starten (mit SSH-Absicherung)

Öffne dafür zwei separate Terminal-Fenster/Sessions zum VPS – falls die Verbindung durch einen Konfigurationsfehler abbricht, hast du im zweiten Fenster noch Zugriff, um zu korrigieren.

sudo systemctl start wg-quick@wg0
sudo systemctl enable wg-quick@wg0

Status und Handshake prüfen:

sudo wg show

Ein erfolgreicher Aufbau zeigt eine Zeile latest handshake: X seconds ago. Fehlt diese Zeile dauerhaft, sind Keys, Endpoint oder Firewall/Cloud-Firewall-Regeln zu prüfen (siehe Fehlerbehebung am Ende).

Verbindungstest zum Heimnetz:

ping 192.168.178.163

(Hinweis: Manche FritzBox-Geräte blocken ICMP/Ping auf VPN-Schnittstellen – falls Ping nicht antwortet, aber der Handshake steht, direkt mit einem TCP-Dienst testen, z. B. nc -zv 192.168.178.163 80.)

Teil 8: Firewall auf dem VPS öffnen

WireGuard-Port und Firewall-Weiterleitung freigeben:

sudo iptables -A FORWARD -i wg0 -j ACCEPT
sudo iptables -A FORWARD -o wg0 -j ACCEPT

Falls dein VPS-Anbieter zusätzlich eine Cloud-Firewall / Security Group anbietet (Hetzner Cloud Firewall, DigitalOcean, etc.): Diese ist getrennt von iptables auf dem Server selbst und muss den UDP-Port 51820 ebenfalls freigeben – ein häufig übersehener Blocker, der zu fehlendem Handshake führt.

Teil 9: HTTP/HTTPS per DNAT ins Heimnetz weiterleiten

Eingehenden Traffic auf Port 80/443 zur Ziel-IP im Tunnel umleiten (Beispiel-Ziel 192.168.178.163):

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.178.163:80
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.178.163:443

sudo iptables -A FORWARD -p tcp -d 192.168.178.163 --dport 80 -j ACCEPT
sudo iptables -A FORWARD -p tcp -d 192.168.178.163 --dport 443 -j ACCEPT

MASQUERADE für den Rückweg sicherstellen:

sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

Prüfen:

sudo iptables -t nat -L POSTROUTING -v -n

Regeln dauerhaft speichern (sonst gehen sie beim nächsten Neustart verloren):

sudo apt install iptables-persistent -y
sudo netfilter-persistent save

Teil 10: Portfreigabe auf der FritzBox selbst

Zusätzlich zur DNAT-Regel auf dem VPS muss die FritzBox die Ports 80/443 lokal an das Zielgerät freigeben (unabhängig vom WireGuard-Tunnel, normale Portfreigabe):

Internet → Freigaben → Portfreigaben → Gerät 192.168.178.163 auswählen → Port 80 (HTTP) und 443 (HTTPS) freigeben.

Teil 11: End-to-End-Test

Von einem externen Gerät (nicht VPS, nicht Heimnetz – z. B. Smartphone im Mobilfunknetz):

curl -I http://<VPS-öffentliche-IPv4>
curl -Ik https://<VPS-öffentliche-IPv4>

Kommt eine Antwort von deinem Heimnetz-Server zurück, funktioniert die komplette Kette.

Zur Live-Kontrolle während des Tests, ob Pakete überhaupt ankommen:

sudo iptables -t nat -L PREROUTING -v -n
sudo iptables -L FORWARD -v -n

Die Paketzähler (pkts) sollten bei den passenden Regeln hochzählen.

Teil 12: DNS-Einträge für eine eigene Domain

Ziel: Ein Hostname wie server.deinedomain.de soll per IPv4 über den VPS-Tunnel und per IPv6 direkt über die FritzBox erreichbar sein. Ein A-Record und ein AAAA-Record können für denselben Namen nebeneinander existieren (kein Konflikt) – ein CNAME auf myfritz.net funktioniert an dieser Stelle dagegen nicht, da an einem Namen mit A-Record kein CNAME gleichzeitig existieren darf.

Record-Typ | Wert | Update-Art

A | öffentliche IPv4 des VPS | statisch, einmalig eintragen

AAAA | aktuelle IPv6 der FritzBox | dynamisch, da DS-Lite die Adresse wechselt

A-Record (einmalig, beim DNS-Anbieter der Domain):

server.deinedomain.de.   A   <VPS-öffentliche-IPv4>

AAAA-Record (dynamisch via DynDNS):

Da sich die IPv6-Adresse bei DS-Lite regelmäßig ändert, braucht es einen DynDNS-Dienst, der AAAA-Updates für die eigene Domain unterstützt (nicht nur myfritz.net-Subdomains), z. B. deSEC (kostenlos, direkt in FRITZ!OS als Anbieter wählbar) oder IPv64.net.

Einrichtung in der FritzBox: Internet → Freigaben → DynDNS → Anbieter auswählen → Zugangsdaten und Domain eintragen. Die FritzBox aktualisiert den AAAA-Record danach automatisch bei jedem Präfixwechsel.

Fehlerbehebung – häufigste Probleme dieser Einrichtung

Symptom | Ursache | Lösung

wg-quick scheitert mit resolvconf: command not found (Exit 127) | DNS =-Zeile in der Config, resolvconf fehlt auf dem VPS | DNS-Zeile aus wg0.conf entfernen (Teil 4)

Key is not the correct length or format | Platzhaltertext statt echtem Public Key in der Config stehen geblieben | Echten Key eintragen, exakte Base64-Zeichenkette prüfen

FritzBox-Import: "Schlüsselkonflikt mit bestehenden Verbindungen" | FritzBox nutzt einen einzigen PrivateKey für alle WireGuard-Verbindungen; eigene Config mit fremdem PrivateKey wird abgelehnt | Nicht selbst eine Config mit eigenem PrivateKey importieren – stattdessen die FritzBox die Config generieren lassen (Teil 2)

SSH-Verbindung zum VPS bricht ab, sobald der Tunnel startet | AllowedIPs enthält 0.0.0.0/0/::/0, kompletter VPS-Traffic wird umgeleitet | Web-Konsole des Providers nutzen, Tunnel stoppen, AllowedIPs auf das Heimnetz-Subnetz bzw. Ziel-IPs einschränken (Teil 5)

wg show zeigt keinen latest handshake | Falscher Endpoint/Port, Cloud-Firewall blockt UDP 51820, oder falsche Keys | Cloud-Firewall-Regeln beim VPS-Provider prüfen, Endpoint (MyFRITZ!-Hostname:51820) und Keys gegenchecken

Ping durch den Tunnel funktioniert nicht, obwohl Handshake steht | FritzBox blockt ICMP auf der VPN-Schnittstelle (normales Verhalten) | Statt Ping direkt einen TCP-Dienst testen, z. B. nc -zv <Ziel-IP> 80

Kurzübersicht: Zusammenspiel der Komponenten

flowchart LR
    A[Internet-Client] -->|HTTP/HTTPS Port 80/443| B[VPS<br/>öffentliche IPv4]
    B -->|DNAT + iptables| C[WireGuard-Tunnel<br/>wg0]
    C -->|verschlüsselt via IPv6| D[FritzBox<br/>WireGuard-Server]
    D -->|Portfreigabe| E[Zielgerät im Heimnetz<br/>192.168.178.163]