FRITZ!Box-WireGuard zum VPS: öffentliche IPv4 bei DS-Lite

FRITZ!Box-WireGuard zum VPS: So kommt Ihr Dienst an eine öffentliche IPv4

Eine WireGuard-Verbindung von der FRITZ!Box zu einem VPS gibt einem Dienst in Ihrem Heimnetz eine echte öffentliche IPv4-Adresse, auch hinter DS-Lite oder CGNAT. Die FRITZ!Box baut den Tunnel selbst auf. Der VPS nimmt Anfragen nur auf den Ports an, die Sie ausdrücklich nennen. Er reicht sie durch den Tunnel an einen Rechner zu Hause weiter.

Ein VPS (Virtual Private Server) ist ein gemieteter Server mit fester öffentlicher IP-Adresse. Sie brauchen keinen Raspberry Pi und keine zusätzliche Software auf dem Heimserver. Die Router-Seite erledigt FRITZ!OS mit Bordmitteln.

Das Problem kennen viele Kabelkunden und manche Glasfaserkunden in Deutschland. Bei DS-Lite (Dual-Stack Lite) hat Ihr Anschluss eine eigene öffentliche IPv6-Adresse, aber keine eigene IPv4-Adresse. IPv4-Verkehr läuft in IPv6 verpackt zum Anbieter. Dort teilt er sich eine öffentliche IPv4-Adresse mit vielen anderen Kunden. CGNAT (Carrier-Grade NAT, also Adressübersetzung beim Anbieter) hat für Sie dieselbe Wirkung. Eine Portfreigabe in der FRITZ!Box hilft für IPv4 deshalb nicht. Eine Verbindung von außen endet beim Anbieter und erreicht Ihre Box nie.

Der Ausweg nutzt die Richtung, die immer funktioniert: von innen nach außen. Die FRITZ!Box wählt sich beim VPS ein. Steht der Tunnel, kann der VPS Pakete hineinschicken, und die Antworten kommen auf demselben Weg zurück. Es gibt andere Wege zum selben Ziel, zum Beispiel einen Reverse-Tunnel mit frp, der auf einem Rechner im Heimnetz läuft, oder Tailscale statt klassischer Portweiterleitung. Diese Anleitung nutzt nur das, was die FRITZ!Box selbst kann.

Die Beispiele verwenden diese Adressen. Ersetzen Sie sie durch Ihre eigenen.

• Heimnetz: 192.168.178.0/24, die FRITZ!Box hat 192.168.178.1, der Heimserver hat 192.168.178.10.
• Tunnelnetz auf dem VPS: 10.66.0.0/24, der VPS hat darin 10.66.0.1.
• Öffentliche IPv4 des VPS: 203.0.113.20 (eine Dokumentationsadresse), Netzwerkkarte enp1s0.
• Öffentlicher Name des Dienstes: dienst.example.de, mit einem A-Record auf die VPS-Adresse.

Alle Befehle führen Sie selbst aus, auf einem VPS mit Ubuntu 24.04 oder auf Ihrem PC. Die Schritte in der FRITZ!Box-Oberfläche klicken Sie von Hand.

Was verlangt AVM für WireGuard zwischen FRITZ!Box und anderem Router?

AVM beschreibt diesen Aufbau im Wissensdatenbank-Artikel „WireGuard-VPN zwischen FRITZ!Box und anderem Router einrichten“. Aus Sicht der FRITZ!Box ist Ihr VPS einfach ein anderer Router. Die englische Fassung des Artikels nannte am 1. Oktober 2026 diese Bedingungen:

• Die Anleitung gilt für FRITZ!OS 8.50 oder neuer.
• FRITZ!Box 6590 Cable und FRITZ!Box 6490 Cable unterstützen kein WireGuard.
• Die Gegenstelle braucht eine IPv6-Adresse oder eine öffentliche IPv4-Adresse. Die FRITZ!Box muss eine Adresse derselben Protokollversion haben.
• In der FRITZ!Box darf noch keine WireGuard-Verbindung eingerichtet sein, auch keine für ein Smartphone. Vorhandene Verbindungen müssen Sie vorher löschen.
• Beide Seiten müssen in verschiedenen IP-Netzen liegen. Für die FRITZ!Box tragen Sie keine Adresse aus einem Transfernetz ein, sondern ihre lokale IP-Adresse.
• Als Vorbereitung nennt AVM ein eingerichtetes MyFRITZ!-Konto.

Die vierte Bedingung trifft viele Leser. Wer heute schon per WireGuard mit dem Handy nach Hause kommt, muss diese Verbindung zuerst löschen. Ob Sie danach wieder Einzelgeräte hinzufügen können, sagt der Artikel nicht. Lesen Sie die Seite vor dem Start selbst nach, denn AVM passt solche Anleitungen an neue FRITZ!OS-Versionen an.

Die fünfte Bedingung erklärt das Netzdesign. Das Heimnetz 192.168.178.0/24 und das Tunnelnetz 10.66.0.0/24 überschneiden sich nicht. In der Datei für die FRITZ!Box steht als Adresse 192.168.178.1, also ihre lokale Adresse, und kein Transfernetz.

Braucht der VPS bei DS-Lite eine IPv6-Adresse?

AVM beantwortet das nicht ausdrücklich. Ein zweiter AVM-Artikel behandelt die Frage, ob die FRITZ!Box IPv6-Daten über VPN überträgt. Er sagt: Die FRITZ!Box kann VPN-Verbindungen über IPv4 und über IPv6 aufbauen, deshalb funktioniert VPN auch an einem DS-Lite-Anschluss. Welche der beiden Varianten eine DS-Lite-Box bei der Kopplung mit einem fremden Router nehmen muss, steht dort nicht. Der Kopplungsartikel nennt nur die Bedingung der gleichen Protokollversion. Mehr steht in AVMs Dokumentation nicht, und mehr sollten Sie auch nicht voraussetzen.

Der praktische Weg ist ein Test. Ob Ihr VPS eine IPv6-Adresse hat, zeigt dieser Befehl:

ip -6 addr show scope global

Eine Zeile mit inet6 und einer Adresse außerhalb von fe80:: bedeutet: Der VPS hat eine globale IPv6-Adresse. Fehlt sie, fragen Sie Ihren Anbieter, ob Ihr Tarif eine bietet. Tragen Sie zuerst die IPv4-Adresse des VPS als Endpoint ein. Kommt trotz richtiger Schlüssel und offener Firewall kein Handshake zustande, tauschen Sie den Endpoint gegen die IPv6-Adresse in eckigen Klammern, zum Beispiel [2001:db8::20]:51820. Nach einem erfolgreichen Handshake zeigt sudo wg show auf dem VPS in der Zeile endpoint, von welcher Adresse die FRITZ!Box tatsächlich kommt.

Schlüssel und wg0.conf auf dem VPS anlegen

Die FRITZ!Box importiert eine fertige Konfigurationsdatei. Diese Datei enthält den privaten Schlüssel der Box. Sie erzeugen deshalb beide Schlüsselpaare auf dem VPS: eines für den VPS und eines für die FRITZ!Box. Den privaten Schlüssel der Box löschen Sie nach dem Import wieder.

sudo apt update && sudo apt install -y wireguard nftables
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/vps.key'
sudo sh -c 'wg pubkey < /etc/wireguard/vps.key > /etc/wireguard/vps.pub'
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/fritzbox.key'
sudo sh -c 'wg pubkey < /etc/wireguard/fritzbox.key > /etc/wireguard/fritzbox.pub'
sudo ls -l /etc/wireguard

Die letzte Zeile sollte bei beiden .key-Dateien -rw------- zeigen. Jeder andere Modus bedeutet, dass ein anderer Benutzer auf dem VPS den Schlüssel lesen kann.

Legen Sie dann /etc/wireguard/wg0.conf an:

[Interface]
Address = 10.66.0.1/24
ListenPort = 51820
PrivateKey = <Inhalt von /etc/wireguard/vps.key>

[Peer]
# FRITZ!Box
PublicKey = <Inhalt von /etc/wireguard/fritzbox.pub>
AllowedIPs = 192.168.178.0/24

AllowedIPs sagt hier, welche Adressen hinter der FRITZ!Box liegen. wg-quick leitet daraus eine Route ab: Alles an 192.168.178.0/24 geht in den Tunnel. Ein Endpoint fehlt mit Absicht. Der VPS kann die Box hinter DS-Lite nicht von sich aus erreichen, deshalb muss sie sich melden.

sudo chmod 600 /etc/wireguard/wg0.conf
sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg show listet jetzt das Interface wg0 und den Peer, aber noch ohne latest handshake. Das ist richtig so, denn die Box kennt den VPS noch nicht. UDP-Port 51820 muss eingehend offen sein. Das gilt für die Firewall auf dem VPS und für eine eventuelle Netzwerk-Firewall im Kundenpanel Ihres Anbieters. Das vollständige Regelwerk folgt weiter unten.

Die Konfigurationsdatei für die FRITZ!Box erzeugen

Diese Befehle schreiben die Datei mit den echten Schlüsseln in Ihr Home-Verzeichnis auf dem VPS. Passen Sie den Endpoint an Ihre VPS-Adresse an. Das umask 077 gilt nur für die aktuelle Shell-Sitzung und sorgt dafür, dass nur Sie die Datei lesen können.

FB_KEY=$(sudo cat /etc/wireguard/fritzbox.key)
VPS_PUB=$(sudo cat /etc/wireguard/vps.pub)
umask 077
cat > ~/fritzbox.conf <<EOF
[Interface]
PrivateKey = $FB_KEY
Address = 192.168.178.1/24

[Peer]
PublicKey = $VPS_PUB
Endpoint = 203.0.113.20:51820
AllowedIPs = 10.66.0.0/24
PersistentKeepalive = 25
EOF
unset FB_KEY

Die Zeilen bedeuten aus Sicht der FRITZ!Box:

• Address = 192.168.178.1/24 ist die lokale IP-Adresse der Box, so wie AVM es verlangt.
• AllowedIPs = 10.66.0.0/24 heißt: Pakete an das Tunnelnetz schickt die Box in den Tunnel. Alles andere geht weiter über Ihren normalen Internetanschluss.
• Endpoint ist die öffentliche Adresse des VPS.
• PersistentKeepalive = 25 soll alle 25 Sekunden ein kleines Paket senden. Das hält die Zuordnung beim Anbieter offen, damit der VPS die Box auch nach einer Pause erreicht.

Ob die FRITZ!Box PersistentKeepalive aus einer importierten Datei übernimmt, steht nicht in AVMs Dokumentation. Lassen Sie die Zeile trotzdem in der Datei. Sie prüfen das Verhalten gleich auf dem VPS.

Holen Sie die Datei auf Ihren PC:

scp benutzer@203.0.113.20:fritzbox.conf .

Nach dem erfolgreichen Import löschen Sie auf dem VPS die Datei und den privaten Schlüssel der Box:

shred -u ~/fritzbox.conf
sudo shred -u /etc/wireguard/fritzbox.key

Der öffentliche Schlüssel fritzbox.pub bleibt liegen. Den privaten Schlüssel der Box braucht der VPS nicht. Jede zusätzliche Kopie eines privaten Schlüssels ist ein Risiko.

Die Netzwerk-Kopplung in der FRITZ!Box einrichten

Die Schritte folgen AVMs Anleitung. Die genauen Beschriftungen können je nach FRITZ!OS-Version leicht abweichen. Maßgeblich ist der deutsche AVM-Artikel.

1. Öffnen Sie die Benutzeroberfläche unter http://fritz.box und gehen Sie zu Internet > Freigaben, Reiter „VPN (WireGuard)“.
2. Klicken Sie auf die Schaltfläche zum Hinzufügen einer WireGuard-Verbindung.
3. Wählen Sie die Option zum Koppeln von Netzwerken (AVMs englische Anleitung nennt sie „Link Networks“) und klicken Sie auf „Weiter“.
4. Bestätigen Sie, dass die Verbindung auf der Gegenseite bereits eingerichtet ist.
5. Geben Sie der Verbindung einen Namen, zum Beispiel vps.
6. Wählen Sie die Datei fritzbox.conf aus und laden Sie sie hoch.
7. Lassen Sie die Option aus, die den gesamten Internetverkehr über die VPN-Verbindung schickt. Sonst läuft Ihr ganzer Haushalt über den VPS.
8. Wenn die Box anbietet, den Zugriff auf bestimmte Geräte zu beschränken, wählen Sie nur den Heimserver aus.
9. Schließen Sie mit „Weiter“ ab und bestätigen Sie den Vorgang, wenn die Box danach fragt.

Lehnt die Box die Datei ab, prüfen Sie zuerst die Bedingungen von oben. Die häufigsten Gründe sind eine zu alte FRITZ!OS-Version und eine schon vorhandene WireGuard-Verbindung.

Steht der Tunnel? Handshake und Keepalive prüfen

Auf dem VPS:

sudo wg show
ping -c 3 192.168.178.10

wg show sollte beim Peer eine Zeile latest handshake zeigen, mit einem Wert von wenigen Sekunden oder Minuten. Die Zeile endpoint zeigt die Adresse, von der die Box kommt. Bei DS-Lite über IPv4 ist das eine Adresse Ihres Anbieters, die Sie mit vielen anderen Kunden teilen. Der Ping erreicht den Heimserver nur, wenn dessen Antwort zurück in den Tunnel geht. Das klappt hier, weil die Antwort an 10.66.0.1 adressiert ist und die FRITZ!Box dieses Netz in den Tunnel routet. Blockiert der Heimserver ICMP in seiner eigenen Firewall, bleibt der Ping stumm, obwohl der Tunnel steht.

Ob die Box Keepalives sendet, sehen Sie an den Byte-Zählern. Lesen Sie sie zweimal im Abstand von einer Minute, während keine andere Verbindung durch den Tunnel läuft:

sudo wg show wg0 transfer

Die erste Zahl nach dem Schlüssel ist die empfangene Datenmenge. Steigt sie ohne jeden Nutzverkehr, sendet die Box Keepalives. Bleibt sie stehen, übernimmt die Box die Einstellung nicht. Dann kann die Zuordnung beim Anbieter nach einer ruhigen Phase ablaufen. Anfragen vom VPS erreichen die Box dann nicht mehr, bis sie selbst wieder etwas sendet.

Die Abhilfe ist ein Eintrag in cron. Lassen Sie den Heimserver jede Minute einmal den VPS anpingen. Das erzeugt Verkehr von innen nach außen und hält den Tunnel offen. Mit crontab -e auf dem Heimserver:

* * * * * ping -c 1 -W 2 10.66.0.1 >/dev/null 2>&1

Warum bricht die Verbindung ohne SNAT ab?

Das ist der wichtigste Punkt dieser Anleitung. Eine reine Portweiterleitung auf dem VPS reicht nicht.

Nehmen wir an, der VPS ändert nur die Zieladresse. Das heißt DNAT (Destination NAT). Ein Besucher mit der Adresse 198.51.100.7 ruft Port 443 auf dem VPS auf. Der VPS schreibt das Ziel auf 192.168.178.10 um und schickt das Paket in den Tunnel. Der Heimserver sieht ein Paket von 198.51.100.7 und antwortet an diese Adresse.

Diese Antwort geht an das Standard-Gateway des Heimservers, die FRITZ!Box. Die Box schickt nur Pakete an 10.66.0.0/24 in den Tunnel. Für 198.51.100.7 nimmt sie den normalen Weg ins Internet, also über DS-Lite. Die Antwort kommt dort mit der falschen Absenderadresse an, oder sie wird schon beim Anbieter verworfen. Der Besucher hat Port 443 auf 203.0.113.20 angefragt und bekommt nie eine passende Antwort. Die Verbindung läuft in einen Timeout.

Sie können das sehen. Auf dem VPS:

sudo tcpdump -ni wg0 tcp port 443

Ohne SNAT zeigt die Ausgabe nur Pakete mit Flags [S], die sich alle paar Sekunden wiederholen. Ein Flags [S.] (die Antwort des Servers) kommt nie zurück. Ein tcpdump auf dem Heimserver zeigt dagegen, dass er sehr wohl antwortet. Die Antwort nimmt nur den falschen Weg.

Es gibt zwei saubere Lösungen. Beide sorgen dafür, dass der Heimserver an eine Adresse im Tunnelnetz antwortet.

Lösung 1: Ports per DNAT weiterleiten und maskieren

Der VPS ändert hier beide Adressen. DNAT setzt das Ziel auf den Heimserver. Masquerade, eine Form von SNAT (Source NAT), setzt die Absenderadresse auf 10.66.0.1. Der Heimserver antwortet dann an 10.66.0.1, die Box schickt die Antwort in den Tunnel, und der VPS macht beide Änderungen rückgängig. Der Preis: Der Heimserver sieht jeden Besucher als 10.66.0.1. Die echte IP-Adresse des Besuchers geht verloren.

Der Vorteil: Diese Lösung funktioniert für jedes Protokoll, nicht nur für HTTP. TLS (Transport Layer Security) endet auf dem Heimserver, deshalb sieht der VPS nur verschlüsselte Daten.

Zuerst muss der VPS Pakete weiterleiten dürfen. Ein Linux-Server verwirft standardmäßig alles, was nicht an ihn selbst adressiert ist.

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-forward.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Die letzte Zeile muss net.ipv4.ip_forward = 1 ausgeben. Den Namen Ihrer Netzwerkkarte liefert ip route show default nach dem Wort dev. Nehmen Sie nicht einfach eth0 an.

Schreiben Sie dann /etc/nftables.conf. Die Zeile flush ruleset löscht alle vorhandenen Regeln. Auf einem VPS, auf dem schon ufw läuft oder Docker eigene Firewall-Regeln setzt, überspringen Sie diese Datei und bauen die Regeln dort ein.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport 22 accept
    udp dport 51820 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "enp1s0" oifname "wg0" ip daddr 192.168.178.10 tcp dport { 80, 443 } counter accept
  }
}

table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "enp1s0" tcp dport { 80, 443 } counter dnat to 192.168.178.10
  }
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wg0" ip daddr 192.168.178.10 counter masquerade
  }
}

Laden Sie die Regeln und lassen Sie dabei eine zweite SSH-Sitzung offen. policy drop plus ein Tippfehler in der SSH-Regel sperrt Sie aus Ihrem eigenen Server aus.

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo systemctl restart nftables

nft -c prüft nur die Syntax und ändert nichts. Gibt es keinen Fehler, aktivieren Sie den Dienst. Der Neustart lädt die Datei auch dann, wenn der Dienst schon lief.

Die Regel für icmp und ipv6-icmp ist wichtig. Ohne ICMPv6 findet der VPS seine IPv6-Nachbarn nicht, und ein IPv6-Endpoint für die FRITZ!Box funktioniert dann nicht. Weitere Ports tragen Sie an zwei Stellen ein: in der forward-Kette und in der prerouting-Kette. Für UDP-Dienste schreiben Sie dort udp dport statt tcp dport.

Testen Sie von außen, zum Beispiel über den Hotspot Ihres Handys:

curl -I https://dienst.example.de

Sie sollten die Statuszeile Ihres Dienstes sehen, zum Beispiel HTTP/2 200. Danach zeigt sudo nft list ruleset bei allen counter-Regeln Pakete.

Lösung 2: HTTPS auf dem VPS annehmen und X-Forwarded-For weitergeben

Für Webdienste gibt es einen Weg, der die IP-Adresse des Besuchers erhält. Ein Reverse Proxy auf dem VPS nimmt die HTTPS-Verbindung selbst an. Er baut dann eine neue Verbindung zum Heimserver auf und schreibt die Adresse des Besuchers in den Header X-Forwarded-For.

Diese neue Verbindung startet auf dem VPS. Linux wählt als Absender die Adresse von wg0, also 10.66.0.1, weil die Route zu 192.168.178.0/24 über wg0 führt. Die Antwort findet deshalb von selbst zurück. Sie brauchen weder DNAT noch Masquerade, und auch ip_forward muss nicht aktiv sein.

Caddy holt das TLS-Zertifikat selbst und setzt X-Forwarded-For ohne weitere Einstellung. Ubuntu 24.04 liefert Caddy im Paket caddy mit.

sudo apt install -y caddy

Ersetzen Sie den Inhalt von /etc/caddy/Caddyfile:

dienst.example.de {
    reverse_proxy 192.168.178.10:8080
}

Laden Sie die Konfiguration neu und lesen Sie das Log:

sudo systemctl reload caddy
sudo journalctl -u caddy -n 50

Im Log sollte Caddy ein Zertifikat für dienst.example.de erhalten. Dafür müssen die Ports 80 und 443 auf dem VPS offen sein, und der A-Record muss auf den VPS zeigen. Im nftables-Regelwerk von oben ersetzen Sie dafür die forward-Regel und die ganze Tabelle ip nat durch eine Zeile in der input-Kette: tcp dport { 80, 443 } accept.

Der Heimserver darf dem Header nur glauben, wenn er von 10.66.0.1 kommt. Sonst kann jeder Besucher eine falsche Adresse mitschicken. Bei nginx auf dem Heimserver sieht das so aus:

set_real_ip_from 10.66.0.1;
real_ip_header X-Forwarded-For;

Danach stehen in den Logs des Heimservers wieder die echten Adressen der Besucher. Werkzeuge wie fail2ban arbeiten dann wieder sinnvoll.

Der Nachteil: TLS endet auf dem VPS. Zwischen VPS und Heimserver verschlüsselt WireGuard den Verkehr, aber auf dem VPS selbst liegt er im Klartext vor. Wer den VPS übernimmt, kann mitlesen.

Was dieser Aufbau öffentlich macht und was nicht

Öffentlich erreichbar sind nur die Ports, die Sie in nftables oder im Caddyfile nennen, und nur auf der Adresse des VPS. Jede Sicherheitslücke im Heimdienst auf diesen Ports ist damit aus dem Internet erreichbar. Halten Sie diesen Dienst aktuell.

Nicht öffentlich sind die anderen Geräte im Heimnetz, die Oberfläche der FRITZ!Box und die IP-Adressen Ihres Anschlusses. Ein Besucher sieht nur den VPS.

Dem VPS selbst müssen Sie vertrauen. Mit AllowedIPs = 192.168.178.0/24 kann er Ihr ganzes Heimnetz erreichen. Wer Root-Rechte auf dem VPS hat, hat damit Zugang zu jedem Gerät zu Hause. Schränken Sie das ein, sobald der Tunnel läuft. Ändern Sie auf dem VPS die Zeile zu AllowedIPs = 192.168.178.10/32. WireGuard verwirft dann jedes Paket an andere Heimgeräte. Wie Sie solche Änderungen übernehmen, ohne den Tunnel zu trennen, zeigt die Anleitung zum Hinzufügen von WireGuard-Peers ohne Neustart. Nutzen Sie zusätzlich die Gerätebeschränkung in der FRITZ!Box, wenn Ihre Version sie anbietet. Dann wirken zwei Schutzschichten auf zwei verschiedenen Geräten.

Fehlerbilder und ihre Ursachen

Kein Handshake. sudo wg show zeigt beim Peer keine Zeile latest handshake. Es kommt also nichts an, oder es wird nichts akzeptiert. Prüfen Sie zuerst UDP 51820 in der VPS-Firewall und in der Netzwerk-Firewall des Anbieters. Prüfen Sie dann die Adresse im Endpoint und die Schlüssel. In fritzbox.conf gehört unter [Peer] der öffentliche Schlüssel des VPS, in wg0.conf der öffentliche Schlüssel der Box. sudo tcpdump -ni any udp port 51820 auf dem VPS zeigt, ob überhaupt Pakete ankommen. Kommt nichts an, testen Sie den IPv6-Endpoint.

Handshake ja, Ping nein. Die Box ist verbunden, aber ping 192.168.178.10 bleibt ohne Antwort. Prüfen Sie AllowedIPs in wg0.conf, die Firewall des Heimservers und die Gerätebeschränkung in der FRITZ!Box.

Von außen ein Timeout, der DNAT-Zähler steigt. Die Pakete erreichen den VPS, verlassen ihn aber nicht. sysctl net.ipv4.ip_forward liefert dann meist 0, oder die forward-Regel passt nicht. Steigt auch der Masquerade-Zähler, aber tcpdump -ni wg0 zeigt kein Flags [S.], liegt das Problem hinter dem Tunnel. Dann läuft der Dienst nicht auf dem Port, oder die Firewall des Heimservers blockiert.

Der DNAT-Zähler bleibt bei null. Der Verkehr kommt nicht am VPS an. Prüfen Sie den Namen der Netzwerkkarte in iifname und die Anbieter-Firewall. Prüfen Sie auch Ihr DNS mit dig +short AAAA dienst.example.de. Zeigt ein AAAA-Record noch auf Ihren Heimanschluss, nehmen viele Clients diesen IPv6-Weg und kommen nie beim VPS an.

Es funktioniert eine Weile, dann nicht mehr. Nach einer ruhigen Phase erreichen Anfragen den Heimserver nicht. Nach dem ersten Paket von innen geht es wieder. Die Box sendet keine Keepalives. Richten Sie den Ping per cron ein, wie oben beschrieben.

Kleine Seiten laden, große hängen. Das deutet auf ein MTU-Problem hin (MTU: Maximum Transmission Unit, die größte Paketgröße auf einer Strecke). DS-Lite und WireGuard fügen beide eigene Kopfdaten hinzu. Setzen Sie in wg0.conf unter [Interface] testweise MTU = 1280 und starten Sie wg-quick@wg0 neu. Verschwindet das Hängen, war es die Paketgröße.

fail2ban sperrt alle Besucher. Mit Lösung 1 kommt jeder Besucher von 10.66.0.1. Eine Sperre gegen diese Adresse sperrt alle. Nutzen Sie Lösung 2, oder sperren Sie auf dem VPS statt auf dem Heimserver.

FAQ

Warum funktioniert eine Portfreigabe in der FRITZ!Box bei DS-Lite nicht für IPv4?

Bei DS-Lite hat Ihr Anschluss keine eigene öffentliche IPv4-Adresse. Ihr IPv4-Verkehr läuft über eine Adresse, die Ihr Anbieter mit vielen Kunden teilt. Eine Verbindung von außen auf diese Adresse endet beim Anbieter und erreicht Ihre FRITZ!Box nie. Eine Portfreigabe in der Box hilft deshalb nur für IPv6. Ein VPS mit eigener IPv4-Adresse, zu dem die Box selbst einen WireGuard-Tunnel aufbaut, löst das Problem.

Warum braucht die Portweiterleitung auf dem VPS Masquerade?

Ohne Masquerade antwortet der Heimserver direkt an die Adresse des Besuchers. Diese Antwort schickt die FRITZ!Box über ihren normalen Internetweg und nicht durch den Tunnel, weil sie nur das Tunnelnetz in den Tunnel routet. Der Besucher bekommt nie eine passende Antwort, und die Verbindung läuft in einen Timeout. Mit Masquerade antwortet der Heimserver an die Tunneladresse des VPS. Der Nachteil ist, dass der Heimserver die echte Besucheradresse nicht mehr sieht.

Wie sieht mein Webserver zu Hause die echte IP-Adresse der Besucher?

Nehmen Sie HTTPS auf dem VPS mit einem Reverse Proxy wie Caddy an. Caddy schreibt die Adresse des Besuchers in den Header X-Forwarded-For und verbindet sich über den Tunnel mit dem Heimserver. Auf dem Heimserver vertrauen Sie diesem Header nur, wenn die Anfrage von der Tunneladresse des VPS kommt, bei nginx mit set_real_ip_from und real_ip_header. Der Preis ist, dass der Verkehr auf dem VPS unverschlüsselt vorliegt.

Welche FRITZ!Box kann WireGuard mit einem VPS koppeln?

AVMs Anleitung nannte am 1. Oktober 2026 FRITZ!OS 8.50 oder neuer als Voraussetzung. Die FRITZ!Box 6590 Cable und die FRITZ!Box 6490 Cable unterstützen kein WireGuard. Außerdem darf vor der Einrichtung noch keine andere WireGuard-Verbindung in der Box bestehen, auch keine für ein Smartphone. Prüfen Sie die aktuelle Fassung des AVM-Artikels, bevor Sie anfangen.