WireGuard-VPN mit FritzBox und Ubuntu-Server einrichten¶
| Stand: 04/2025 |
|---|
| Verwendete Software - Ubuntu 24.04 LTS - WireGuard 1.0.20210914 - FRITZ!OS 8.03 |
| Weitere Dokumentationen: |
Vorwort¶
Diese Dokumentation beschreibt die Einrichtung einer VPN-Verbindung zwischen einer FRITZ!Box und einem Ubuntu-Server mithilfe von WireGuard.
Der WireGuard-Server fungiert in dieser Anleitung als VPN-Gateway bzw. Router zwischen dem lokalen Netzwerk der FRITZ!Box und einem (ggf. größeren) entfernten Netz am Ubuntu-Standort. Der VPN-Tunnel ermöglicht den Zugriff auf weitere Geräte im entfernten Netzwerk, etwa Server, Drucker oder Steuergeräte.
Ziel ist es, zwei Netzwerke dauerhaft und sicher über das WireGuard-Protokoll zu koppeln, sodass Geräte beider Seiten direkt miteinander kommunizieren können (z. B. für SSH-Zugriffe, Dateifreigaben oder Management-Zugänge). Die Konfiguration ist bewusst einfach gehalten und auf direkte Umsetzung in realen Heimumgebungen oder kleinen Netzwerken ausgelegt.
Für die korrekte Kommunikation müssen im entfernten Netzwerk (z. B. beim Hosting-Anbieter) ggf. statische Routen für das Netzwerk der FritzBox gesetzt werden. Dies ist notwendig, da der WireGuard-Server typischerweise nicht das Standardgateway im entfernten Rechenzentrum ist – ohne diese Routen wäre ein Rückweg in das lokale Netz nicht möglich.
flowchart LR
A((lokales Netz)) -->|192.168.178.0/32| FB["FritzBox
(192.168.178.1)"]
FB --> WG["WireGuard-Server
(192.0.2.42)"]
WG -->|192.168.179.0/32| B((entferntes Netz))
subgraph "FritzBox"
FB
end
subgraph "WireGuard-Server"
WG
end
Es sind Grundkenntnisse im Umgang mit Linux erforderlich, da die Vorgehensweise, wie sie hier beschrieben ist, in manchen Teilen abweichen kann. Kein System ist wie das Andere. Die Dokumentation wurde sorgfältig von mir geprüft. Dennoch kann ich keinerlei Haftung für Schäden an Ihrem System oder eine Gewährleistung übernehmen. Bitte verwenden Sie diese Dokumentation auf eigene Gefahr.
Was muss ich in der Konfiguration anpassen?¶
Einige Parameter müssen auf Ihre Umgebung angepasst werden. Im Verlauf dieser Dokumentation müssen Sie nur die Parameter anpassen, die in der nachfolgenden Tabelle aufgelistet sind. Sie können also ganz einfach durch die Funktion "Suchen und Ersetzen" (STRG + H), die Konfigurationsdateien auf Ihre Umgebung anpassen. Das Gleiche gilt für auszuführende Kommandos.
Folgende Parameter werden verwendet:
| Wert | Hinweis | |
|---|---|---|
| WireGuard-Server: | ||
| öffentliche IPv4-Adresse | 192.0.2.42 | Ersetzen Sie diesen Wert durch die öffentliche IPv4-Adresse Ihres WireGuard-Servers. |
| private IPv4-Adresse | 10.10.10.1 | Ersetzen Sie diesen Wert durch die private IPv4-Adresse Ihres WireGuard-Servers. |
| Entferntes Netz | 192.168.179.0/24 | Ersetzen Sie diesen Wert durch das entfernte Netz Ihres WireGuard-Servers. |
| FritzBox: | ||
| öffentliche IPv4-Adresse | 203.0.113.42 (dynamisch) | Wir gehen von einer dynamischen IP-Adresse aus. Tatsächliche IP-Adresse für dieses Setup nicht relevant. |
| private IPv4-Adresse | 192.168.178.1 | Ersetzen Sie diesen Wert durch die private IPv4-Adresse Ihrer FritzBox. |
| lokales Netz | 192.168.178.0/24 | Ersetzen Sie diesen Wert durch das lokale Netz Ihrer FritzBox. |
Server vorbereiten¶
Root-Rechte einräumen¶
Während der gesamten Dokumentation werden Root-Rechte benötigt. Um auf das Voranstellen von sudo zu verzichten, verschaffen Sie sich für die gesamte Sitzung erhöhte Rechte mit:
sudo -i
Update durchführen¶
Bringen Sie den Server auf den aktuellen Patchstand:
apt update && apt upgrade
Software installieren¶
Laden Sie wireguard aus dem offiziellen Ubuntu-Repository herunter:
apt install wireguard
WireGuard-VPN einrichten¶
Keys generieren¶
Generieren Sie zunächst die Server-Keys:
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
und anschließend die FritzBox-Keys:
wg genkey | tee /etc/wireguard/fritzbox_private.key | wg pubkey > /etc/wireguard/fritzbox_public.key
Schränken Sie die Zugriffsrechte auf die Keys ein:
chmod 600 /etc/wireguard/*.key
WireGuard Konfiguration erstellen¶
wg0.conf¶
Info
Die Datei wg0.conf definiert die lokalen Schnittstellenparameter und den entfernten Peer (FritzBox).
[Interface]
PrivateKey
Der private Schlüssel des WireGuard-Servers. Unbedingt geheim halten. Wird automatisch der Schnittstelle zugeordnet.Address
Die lokale WireGuard-IP des Servers. In diesem Setup10.10.10.1/24, also erster Host im Tunnelnetz.ListenPort
Der UDP-Port, auf dem WireGuard Verbindungen erwartet. Standard ist51820.PostUp
Shell-Kommandos, die nach dem Start der Schnittstelle ausgeführt werden. Hier: Aktivierung des IP-Forwardings.PostDown
Analog zuPostUp, wird beim Deaktivieren ausgeführt. Hier: Rücknahme der IP-Forwarding-Einstellung.
[Peer]
PublicKey
Der öffentliche Schlüssel der FritzBox, dient zur Authentifizierung.AllowedIPs
Gibt an, welche IP-Adressen vom WireGuard-Server über diesen Peer erreichbar sind und welche eingehenden Pakete akzeptiert werden:- Die IP-Adresse des Initiators (in diesem Setup die FritzBox
192.168.178.1/32). - Zusätzlich werden alle Netze, die hinter der FritzBox erreichbar sein sollen (z. B.
192.168.178.0/24,192.168.150.0/24, usw.), hier angegeben. - Auch wenn in diesem Setup die IP-Adresse der FritzBox bereits im Subnetz enthalten ist und daher aus technische Sicht nicht explizit angegeben werden muss, empfiehlt sich die explizite Angabe des Initiators.
Insbesondere bei komplexeren Netz-Topologien ist die Konfiguration so deutlich transparenter.
- Die IP-Adresse des Initiators (in diesem Setup die FritzBox
PersistentKeepalive
Hält die Verbindung aktiv.
Hinweis!
Die WireGuard-Implementation der FRITZ!Box verwendet nicht wie üblich eine separate Adresse im VPN-Tunnelnetz (z. B. 10.10.10.2/32).
Stattdessen muss die interne IPv4-Adresse der FritzBox (z. B. 192.168.178.1/32) verwendet werden.
Das ist nicht standardkonform, aber für die VPN-Kopplung mit der FritzBox erforderlich.
Achten Sie daher unbedingt darauf, in der wg0.conf und wg-fritzbox.conf die interne LAN-IP Ihrer FritzBox zu setzen – und nicht eine WireGuard-typische 10.10.10.../32-Tunnel-IP.
Erstellen Sie eine neue Datei /etc/wireguard/wg0.conf mit folgendem Inhalt:
nano /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <server_private.key>
Address = 10.10.10.1/24
ListenPort = 51820
PostUp = sysctl -w net.ipv4.ip_forward=1
PostDown = sysctl -w net.ipv4.ip_forward=0
[Peer]
PublicKey = <fritzbox_public.key>
AllowedIPs = 192.168.178.1/32, 192.168.178.0/24
PersistentKeepalive = 25
[...]
PrivateKey = <server_private.key>
[...]
PublicKey = <fritzbox_public.key>
[...]
AllowedIPs = [...], 192.168.178.0/24
[...]
<server_private.key>:
cat /etc/wireguard/server_private.key
EEmwz05[...]cqoYiWIFQ=
<fritzbox_public.key>:
cat /etc/wireguard/fritzbox_public.key
kxN9mgY[...]mihEmfPR0=
wg-fritzbox.conf¶
Info
Die Datei wg-fritzbox.conf wird später in der FRITZ!Box importiert oder dient als Vorlage für die manuelle Konfiguration. Sie beschreibt die Sicht der FRITZ!Box auf den WireGuard-Peer (Server) und den Tunnel.
[Interface]
PrivateKey
Der private Schlüssel der FRITZ!Box. Dieser Schlüssel bleibt lokal und darf nicht weitergegeben werden.Address
Achtung: Die FRITZ!Box verwendet hier ihre interne LAN-IP-Adresse (z. B.192.168.178.1/24) anstelle einer dedizierten Tunnel-IP wie10.10.10.2/32. Dieses Verhalten ist nicht standardkonform, aber bei AVM erforderlich. Es darf keine abweichende IP-Adresse verwendet werden.
[Peer]
PublicKey
Der öffentliche Schlüssel des WireGuard-Servers. Dient zur Authentifizierung des entfernten Peers.AllowedIPs
Definiert, welche Zielnetze über den Tunnel erreichbar sein sollen:10.10.10.0/24: Das WireGuard-Tunnelnetz.192.168.179.0/24: Das entfernte Netz hinter dem WireGuard-Server, etwa am Hostingstandort.- Weitere Netze (z. B. andere VLANs oder zusätzliche interne Netzsegmente hinter dem WireGuard-Server) müssen hier ebenfalls explizit eingetragen werden, wenn sie über die VPN-Verbindung erreichbar sein sollen. Nur Ziele in den hier genannten Netzen werden über den Tunnel geroutet. Alle anderen Verbindungen erfolgen wie gewohnt über das lokale Gateway der FRITZ!Box (Split Tunneling bzw. Local Breakout).
Endpoint
Öffentliche IP-Adresse und Port des WireGuard-Servers.
Wichtig: Bei dynamischen IP-Adressen ist ggf. ein DynDNS-Eintrag erforderlich.PersistentKeepalive
Hält die Verbindung offen
Erstellen Sie eine neue Datei /etc/wireguard/wg-fritzbox.conf mit folgendem Inhalt:
nano /etc/wireguard/wg-fritzbox.conf
[Interface]
PrivateKey = <fritzbox_private.key>
Address = 192.168.178.1/24
[Peer]
PublicKey = <server_public.key>
AllowedIPs = 10.10.10.0/24, 192.168.179.0/24
Endpoint = 192.0.2.42:51820
PersistentKeepalive = 25
[...]
PrivateKey = <fritzbox_private.key>
[...]
PublicKey = <server_public.key>
[...]
AllowedIPs = [...], 192.168.179.0/24
Endpoint = 192.0.2.42:[...]
[...]
<fritzbox_private.key>:
cat /etc/wireguard/fritzbox_private.key
NxX5oPX[...]pVdrD0hUF8=
<server_public.key>:
cat /etc/wireguard/server_public.key
Emwz05y[...]mqoYiWIFQ=
Schränken Sie die Zugriffsrechte auf die Dateien ein:
chmod 600 /etc/wireguard/*.conf
WireGuard starten¶
Führen Sie folgendes Kommando aus, damit WireGuard nach einem Neustart automatisch startet:
systemctl enable wg-quick@wg0
Starten Sie WireGuard.
systemctl start wg-quick@wg0
Kontrollieren Sie, ob der Dienst erfolgreich gestartet ist:
wg show
interface: wg0
public key: Emwz05y[...]mqoYiWIFQ=
private key: (hidden)
listening port: 51820
FritzBox konfigurieren¶
- Rufen Sie das Webinterface Ihrer FritzBox auf und wählen Sie unter
Internet->Freigaben->VPN (WireGuard)den PunktVerbindung hinzufügenaus:
- Wählen Sie den Punkt
Netzwerke koppeln oder spezielle Verbindungen herstellenaus und klicken Sie aufWeiter:
- Vergeben Sie einen Verbindungsnamen, wählen Sie die Datei
wg-fritzbox.confund klicken Sie aufFertigstellen:
Inbetriebnahme und Test¶
Kontrollieren Sie auf dem WireGuard-Server, ob VPN-Verbindung besteht:
wg show
interface: wg0
public key: Emwz05y[...]mqoYiWIFQ=
private key: (hidden)
listening port: 51820
peer: kxN9mgY[...]mihEmfPR0=
endpoint: 203.0.113.42:57509
allowed ips: 10.10.10.2/32, 192.168.178.0/24
latest handshake: 54 seconds ago
transfer: 8.21 KiB received, 25.24 KiB sent
persistent keepalive: every 25 seconds
Routing in Cloud-Umgebungen (Hetzner, IONOS, etc.)¶
Hinweis!
Bei Cloud-Anbietern wie Hetzner Cloud oder IONOS wird der gesamte interne Datenverkehr für lokal zugewiesene Subnetze über ein zentrales Subnetz-Gateway geleitet.
Jeder Server erhält eine IP-Adresse aus dem Subnetz mit einem /32-Längenpräfix – es besteht also kein direktes Routing zwischen den Servern innerhalb desselben Subnetzes. Das Subnetz-Gateway übernimmt das Routing für das zugewiesene Subnetz (z. B. 192.168.179.0/24), akzeptiert aber ausschließlich Pakete mit Quelladressen aus diesem Subnetz. Pakete mit abweichenden Quelladressen (z. B. 192.168.178.0/24 vom lokalen Netz der FritzBox) werden vom Gateway verworfen – ein Verhalten, das durch den Mechanismus strict uRPF (Unicast Reverse Path Forwarding) bedingt ist.
Problem:
Wenn ein WireGuard-Server in diesem Subnetz ein Paket weiterleitet, das eine Quelladresse außerhalb des Cloud-Subnetzes trägt (z. B. aus dem FritzBox-Netz 192.168.178.0/24), wird dieses Paket vom Gateway verworfen, da es den uRPF-Check nicht besteht.
Dies tritt typischerweise auf, wenn:
- Der WireGuard-Server in einem Hetzner Cloud-Netz ohne vSwitch steht
- ein anderer VPN-Client aus dem lokalen Netz das Zielsystem in der Cloud erreichen will,
- der VPN-Traffic nicht genattet wird
Selbst wenn man auf einem anderen Cloud-Server eine statische Route zum FritzBox-Netz über den WireGuard-Server einrichten würde, greift diese Route nicht, da die Entscheidung über den Paketfluss vom Subnetz-Gateway erzwungen wird. Ein Eingriff in dessen Routing-Konfiguration ist nicht möglich.
flowchart LR
subgraph "lokales Netz"
FritzBox(("FritzBox
(192.168.178.1/24)"))
end
subgraph "entferntes Netz"
Gateway["Subnetz-Gateway (192.168.179.1/24)"]
Server1(("WireGuard-Server
192.168.179.10/32"))
Server2(("Server A
192.168.179.11/32"))
Drop["✖ Paket verworfen"]
end
FritzBox -->|VPN-Traffic mit Quell-IP 192.168.178.x| Server1
Server1 -->|weitergeleitetes Paket mit Quell-IP 192.168.178.x| Gateway
Gateway -->|strict uRPF verwirft Paket| Drop["✖ Paket verworfen"]
Server2 -. "möchte 192.168.178.x erreichen" .-> Gateway
Gateway -. "Route nicht bekannt" .-> Drop
Hinweis:
In höherwertigen Tarifen wie Hetzner Robot mit vSwitch besteht die Möglichkeit, echtes Routing innerhalb des Netzwerks zu konfigurieren. Dort können statische Routen eingerichtet werden, sofern die Infrastruktur ein geroutetes Netzwerksegment bereitstellt.
Option 1: Statische Route im Cloud-Netz (empfohlen, wenn möglich)¶
Wenn der Anbieter dies erlaubt (z. B. vSwitch bei Hetzner Robot oder IONOS Private Network), kann eine Route für das FritzBox-Netz gesetzt werden:
ip route add 192.168.178.0/24 via <IP-des-WG-Servers>
Info
Diese Route stellt sicher, dass alle Pakete mit Ziel 192.168.178.0/24 korrekt über den WireGuard-Server laufen.
Es gibt zwei Möglichkeiten, diese Route zu setzen:
-
🔁 Pro Server: Die Route wird lokal auf jedem Server im Cloud-Netz hinzugefügt, der Zugriff auf das FritzBox-Netz benötigt.
-
🌐 Global (vSwitch): Wenn das Netzwerk über einen vSwitch oder ein Layer-3-Netzwerksegment zentral verwaltet wird, kann die Route auf dem virtuellen Switch oder Gateway konfiguriert werden – falls vom Anbieter unterstützt.
Option 2: NAT (Masquerading)¶
Falls keine Routing-Anpassung möglich ist (z. B. bei Hetzner Cloud), kann man als Fallback Masquerading aktivieren – d. h. der WireGuard-Server ersetzt die Quelladresse durch seine eigene.
Beispielkonfiguration wg0.conf mit nftables:
[Interface]
[...]
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = nft add table ip nat
PostUp = nft add chain ip nat postrouting { type nat hook postrouting priority srcnat\; policy accept\; }
PostUp = nft add rule ip nat postrouting ip saddr 192.168.178.0/24 oifname != "wg0" masquerade
PostDown = sysctl -w net.ipv4.ip_forward=0
PostDown = nft flush chain ip nat postrouting && nft delete chain ip nat postrouting && nft delete table ip nat
[Peer]
[...]
[...]
PostUp = nft add rule ip nat postrouting ip saddr 192.168.178.0/24 oifname != "wg0" masquerade
[...]
Info
Nachteile von NAT:
Die Zielsysteme im entfernten Netz sehen nur die IP-Adresse des WireGuard-Servers – nicht die tatsächliche Quelladresse des Clients aus dem FritzBox-Netz.
Es handelt sich daher nicht um echtes Ende-zu-Ende-Routing, sondern um eine einseitige Tunnelverbindung mit maskierter Quelle.
Gleichzeitig bedeutet das: Vom entfernten Netz aus können keine eingehenden Verbindungen ins FritzBox-Netz aufgebaut werden, da:
- keine echte Route zurück existiert,
- und die Clients im FritzBox-Netz durch NAT vollständig verborgen bleiben.
Fazit¶
Cloud-Netzwerke mit uRPF erfordern zusätzliche Maßnahmen.
Die beste Lösung ist eine statische Route – wenn das nicht geht, kann Masquerading helfen, bringt aber Einschränkungen mit sich.
Abschluss¶
Wenn die VPN-Verbindung erfolgreich hergestellt wurde und Sie keine Fehlermeldungen erhalten haben, ist Ihr WireGuard-VPN einsatzbereit.


