Zum Inhalt

WireGuard-VPN mit FritzBox und Ubuntu-Server einrichten

Stand: 04/2025
WireGuard-Logo
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 Setup 10.10.10.1/24, also erster Host im Tunnelnetz.
  • ListenPort
    Der UDP-Port, auf dem WireGuard Verbindungen erwartet. Standard ist 51820.
  • PostUp
    Shell-Kommandos, die nach dem Start der Schnittstelle ausgeführt werden. Hier: Aktivierung des IP-Forwardings.
  • PostDown
    Analog zu PostUp, 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.
  • 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
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


Anzupassende Parameter:
[...]
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 wie 10.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
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


Anzupassende Parameter:
[...]
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 Punkt Verbindung hinzufügen aus:

    FritzBox-WireGuard


  • Wählen Sie den Punkt Netzwerke koppeln oder spezielle Verbindungen herstellen aus und klicken Sie auf Weiter:

    FritzBox-WireGuard


  • Wählen Sie Ja aus und klicken Sie auf Weiter:

    FritzBox-WireGuard


  • Vergeben Sie einen Verbindungsnamen, wählen Sie die Datei wg-fritzbox.conf und klicken Sie auf Fertigstellen:

    FritzBox-WireGuard


  • Die Verbindung ist jetzt eingerichtet und sollte nach einem kurzen Augenblick aktiv (grün) werden:

    FritzBox-WireGuard


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:

wg0.conf
[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]
[...]

Anzupassende Parameter:
[...]
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.