Ein WireGuard-VPN verbindet Homeoffice-Geräte und entfernte Standorte verschlüsselt mit Ihrem Firmennetz. Sie richten auf Debian 12 oder Ubuntu 24.04 LTS einen WireGuard-Server ein, erzeugen Schlüsselpaare, schreiben die Konfigurationen für Server und Clients, aktivieren IP-Forwarding samt NAT und verbinden zwei Standorte per Site-to-Site.

Voraussetzungen

Ein Linux-Server mit Debian 12 (Bookworm) oder Ubuntu 24.04 LTS und root- bzw. sudo-Rechten; 1 CPU-Kern und 512 MB RAM genügen für ein Büro-VPN
Eine öffentlich erreichbare IP-Adresse oder ein DNS-Hostname für den Server-Endpunkt (z. B. vpn.firma.example.de)
Die Möglichkeit, eingehendes UDP auf Port 51820 durchzulassen (Router-Portforwarding, Cloud-Security-Group, Host-Firewall)
Eindeutig geplante Subnetze: ein Tunnel-Netz (z. B. 10.100.0.0/24) plus pro Standort ein eigenes LAN-Netz ohne Überlappungen
Bei DS-Lite oder CGNAT: mindestens ein Standort mit echter öffentlicher IP, der als Initiator dient

Schritt 1: WireGuard installieren

WireGuard ist auf Debian 12 und Ubuntu 24.04 ein reguläres Paket; da das Kernelmodul seit Linux 5.6 im Mainline-Kernel steckt, ist kein DKMS-Build nötig. Installieren Sie als root wireguard (mit wg und wg-quick) und iptables, das Minimalinstallationen für die NAT-Regeln in Schritt 4 fehlt.

apt update && apt install -y wireguard iptables

Prüfen Sie danach, dass die Werkzeuge bereitstehen:

wg --version
modprobe wireguard && lsmod | grep wireguard

Verifizieren: wg --version gibt eine Versionsnummer aus (z. B. wireguard-tools v1.0.20210914), lsmod zeigt das geladene Modul wireguard.

Schritt 2: Schlüsselpaare erzeugen

Jeder Peer hat ein eigenes Schlüsselpaar aus privatem und öffentlichem Schlüssel. Best Practice: ein Paar pro Gerät und Standort, damit Sie einzelne Peers widerrufen können. Setzen Sie im Konfigurationsverzeichnis umask 077, damit neue Dateien nur für root lesbar sind.

cd /etc/wireguard
umask 077
# Server-Schlüsselpaar
wg genkey | tee server_private.key | wg pubkey > server_public.key
# Client-Schlüsselpaar (auf dem Server vorbereiten oder direkt am Client erzeugen)
wg genkey | tee client_private.key | wg pubkey > client_public.key
# Optional: Preshared-Key als zusätzliche Härtung
wg genpsk > psk.key

Der private Schlüssel verlässt idealerweise nie sein Gerät; der öffentliche Schlüssel der Gegenseite kommt in den jeweiligen [Peer]-Block. Der optionale Preshared-Key (gleicher Wert auf beiden Seiten) erhöht die Robustheit gegenüber künftigen Quantenangriffen.

Verifizieren: ls -l /etc/wireguard zeigt die Schlüsseldateien mit -rw------- und Besitzer root; jede Datei enthält eine Zeile mit 44 Zeichen (Base64, endet auf =).

Schritt 3: IP-Forwarding dauerhaft aktivieren

Zum Weiterleiten zwischen Tunnel und LAN bzw. Internet muss IP-Forwarding aktiv sein. sysctl -w gilt nur bis zum Reboot; legen Sie die Einstellung dauerhaft in /etc/sysctl.d/ ab.

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-wireguard.conf
echo 'net.ipv6.conf.all.forwarding = 1' >> /etc/sysctl.d/99-wireguard.conf
sysctl --system

Die IPv6-Zeile brauchen Sie nur für IPv6 durch den Tunnel. Ein Host-zu-Host-Tunnel braucht weder Forwarding noch NAT, ein KMU-Gateway meist beides.

Verifizieren: sysctl net.ipv4.ip_forward liefert net.ipv4.ip_forward = 1, auch nach einem Neustart.

Schritt 4: Server-Config schreiben (wg0.conf)

Die zentrale Datei ist /etc/wireguard/wg0.conf; der Dateiname ist zugleich der Interface-Name. Sie besteht aus einem [Interface]-Block für den Server und je einem [Peer]-Block pro Client. Tragen Sie die Inhalte der Schlüsseldateien ein, nicht die Dateinamen, und ersetzen Sie eth0 durch das WAN-Interface aus ip route (hinter default via … dev).

[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = INHALT-VON-server_private.key
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Homeoffice-Notebook
PublicKey = INHALT-VON-client_public.key
AllowedIPs = 10.100.0.2/32

PostUp aktiviert beim Start des Tunnels Weiterleitung und Masquerading auf dem WAN-Interface, PostDown räumt die Regeln ab. AllowedIPs = 10.100.0.2/32 ordnet diesem Client nur Pakete mit genau dieser Tunnel-IP zu (Details in Schritt 5).

Verifizieren: wg-quick strip wg0 gibt die Konfiguration ohne Fehlermeldung aus. Ein Parse-Fehler nennt die fehlerhafte Zeile.

Schritt 5: Client-Config und Routing (Split- vs. Full-Tunnel)

Auf dem Homeoffice-Gerät legen Sie eine eigene wg0.conf an (unter Windows und macOS in der WireGuard-App über „Leeren Tunnel hinzufügen“). AllowedIPs hat eine Doppelfunktion: Routing-Eintrag (welcher Verkehr durch den Tunnel geht) und Eingangsfilter (welche Quell-IPs vom Peer akzeptiert werden). Pakete außerhalb werden verworfen.

[Interface]
PrivateKey = INHALT-VON-client_private.key
Address = 10.100.0.2/24

[Peer]
PublicKey = INHALT-VON-server_public.key
Endpoint = vpn.firma.example.de:51820
AllowedIPs = 10.100.0.0/24, 192.168.11.0/24
PersistentKeepalive = 25
# Full-Tunnel stattdessen: AllowedIPs = 0.0.0.0/0, ::/0

Die Wahl der AllowedIPs entscheidet über den Routing-Modus:

Modus	AllowedIPs (Client)	Was geht durch den Tunnel	Typischer Einsatz
Split-Tunnel	`10.100.0.0/24, 192.168.11.0/24`	Nur Tunnel- und Firmen-LAN-Verkehr	Homeoffice mit Zugriff aufs Firmennetz, Internet bleibt lokal
Full-Tunnel	`0.0.0.0/0, ::/0`	Sämtlicher Client-Verkehr	Schutz in fremden WLANs, zentrales Filtern/Logging

PersistentKeepalive = 25 hält die UDP-Session offen, wenn der Client hinter NAT oder Firewall sitzt; sonst schläft die Verbindung ein, sobald die NAT-Session abläuft. Der Server-Endpunkt muss eine öffentlich erreichbare IP oder ein Hostname sein, mit privater IP scheitert der Handshake.

Verifizieren: 192.168.11.0/24 steht im Beispiel für Ihr Firmen-LAN. Die Client-Datei enthält den privaten Schlüssel des Clients und den öffentlichen des Servers; AllowedIPs enthält kein Netz, das der Client lokal selbst nutzt.

Schritt 6: Dateirechte setzen, starten und Autostart aktivieren

Schlüsseldateien und Config dürfen nie welt-lesbar sein. Setzen Sie chmod 600 und Besitzer root, dann starten Sie den Tunnel.

chmod 600 /etc/wireguard/wg0.conf /etc/wireguard/*.key
systemctl enable --now wg-quick@wg0   # Autostart beim Boot + sofort starten
# Stoppen bei Bedarf:
systemctl stop wg-quick@wg0

Starten Sie den Tunnel nicht zusätzlich mit wg-quick up wg0: Ist wg0 schon aktiv, bricht der Dienst mit wg0 already exists ab. Auf einem Linux-Client genügt derselbe systemctl-Befehl.

Verifizieren: systemctl is-active wg-quick@wg0 liefert active, wg show wg0 zeigt listening port: 51820 und die Peers. Nach dem Verbinden des Clients erscheint latest handshake mit Zeitangabe.

Schritt 7: Firewall – nur den VPN-Port öffnen

Lassen Sie eingehendes UDP auf Port 51820 zu und erlauben Sie das Forwarding über das WireGuard-Interface. Mit UFW (Uncomplicated Firewall):

ufw allow 51820/udp
ufw route allow in on wg0
ufw reload

Die Freigabe muss auch an vorgelagerten Stellen greifen (Router-Portforwarding, Cloud-Security-Group, vorgeschaltete Firewall), sonst kommt kein Handshake zustande.

Verifizieren: ufw status listet 51820/udp ALLOW und die Route-Regel für wg0; ss -ulpn | grep 51820 zeigt den lauschenden Socket. Von außen erkennen Sie die Freigabe nur am erfolgreichen Handshake, da WireGuard auf unbekannte Pakete nicht antwortet.

Schritt 8: Standort-zu-Standort vernetzen (Site-to-Site)

Bei der Standortvernetzung tragen sich beide Seiten gegenseitig als [Peer] ein. In AllowedIPs der Gegenseite stehen deren Tunnel-IP als /32 plus deren LAN-Subnetz; fehlt das entfernte LAN, werden alle Pakete dorthin verworfen. Im Beispiel hat Standort A das LAN 10.1.0.0/24, Standort B 10.2.0.0/24.

Standort A – /etc/wireguard/wg0.conf:

[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = A_PRIVATE
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = B_PUBLIC
Endpoint = standort-b.example.de:51820
AllowedIPs = 10.100.0.2/32, 10.2.0.0/24
PersistentKeepalive = 25

Standort B – /etc/wireguard/wg0.conf:

[Interface]
Address = 10.100.0.2/24
ListenPort = 51820
PrivateKey = B_PRIVATE
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = A_PUBLIC
Endpoint = standort-a.example.de:51820
AllowedIPs = 10.100.0.1/32, 10.1.0.0/24
PersistentKeepalive = 25

Beide LAN-Subnetze müssen eindeutig sein; nutzen beide denselben Bereich (etwa 192.168.0.0/24), kollidiert das Routing. Zu DS-Lite oder CGNAT siehe FAQ.

Verifizieren: wg show zeigt auf beiden Seiten einen aktuellen latest handshake, und ein Ping von Standort A auf eine Adresse in 10.2.0.0/24 wird beantwortet. Geräte in den LANs brauchen eine Route zum anderen Netz, meist über ihr Standard-Gateway.

Schritt 9: Peer zur Laufzeit ergänzen (optional)

Neue Clients fügen Sie ohne Tunnel-Neustart hinzu, bestehende Verbindungen laufen weiter. Tragen Sie öffentlichen Schlüssel und Tunnel-IP direkt am Interface ein:

wg set wg0 peer CLIENT_PUBLIC_KEY allowed-ips 10.100.0.3/32

Diese Änderung ist flüchtig. Übernehmen Sie sie in die wg0.conf oder setzen Sie SaveConfig = true, damit Laufzeitänderungen beim Herunterfahren zurückgeschrieben werden. Dann überschreibt wg-quick beim Stoppen alle manuellen Änderungen an der Datei, die Sie bei laufendem Tunnel gemacht haben.

Verifizieren: wg show wg0 allowed-ips listet den neuen Peer mit 10.100.0.3/32.

Typische Fehler und Troubleshooting

Beginnen Sie mit wg show: latest handshake und die Transferzähler zeigen sofort, ob die Verbindung steht.

wg show                         # Handshake-Zeit, RX/TX, Endpoint je Peer
ss -ulpn | grep 51820           # lauscht der UDP-Socket?
journalctl -u wg-quick@wg0 -e   # Fehler beim Bringup

Kein Handshake, vertauschte Schlüssel: Häufigste Ursache. Der PublicKey im [Peer] muss der öffentliche Schlüssel der Gegenseite sein, nie der eigene oder ein privater.
UDP-Port blockiert: Cloud-Security-Group, Router-Portforwarding oder Host-Firewall lassen eingehendes UDP 51820 nicht durch – dann kommt kein Handshake zustande.
AllowedIPs unvollständig: Fehlt das entfernte LAN (z. B. 10.2.0.0/24), werden Pakete dorthin verworfen.
Tunnel steht, aber kein LAN-/Internetzugriff: Fehlendes NAT/MASQUERADE oder falsches WAN-Interface (eth0 vs. ens18/enp0s3). Prüfen Sie das echte Interface mit ip route.
Verbindung schläft ein: PersistentKeepalive = 25 beim Peer hinter NAT fehlt.
IP-Forwarding nach Reboot weg: nur per sysctl -w gesetzt, siehe Schritt 3.
Privater Endpoint: Ein Endpoint mit privater IP macht den Handshake unmöglich; bei DS-Lite/CGNAT initiiert die Seite hinter CGNAT.
Zeitabweichung: Große Clock-Drifts können Handshakes und Rekeying stören. Halten Sie NTP aktiv.
Welt-lesbare Schlüssel: privatekey und wg0.conf strikt auf chmod 600 und Besitzer root setzen.

Häufige Fragen

Welcher Port und welches Protokoll werden verwendet?

Nur UDP, Standard-Port 51820, kein TCP. Geben Sie in Firewall, Portforwarding und Cloud-Security-Group gezielt UDP 51820 frei; ändern lässt sich der Port über ListenPort im [Interface]-Block.

Was ist der Unterschied zwischen Split-Tunnel und Full-Tunnel?

Beim Split-Tunnel läuft nur Verkehr zu Tunnel- und Firmennetz durch das VPN, beim Full-Tunnel (0.0.0.0/0, ::/0) der gesamte Verkehr des Clients. Details stehen in der Tabelle in Schritt 5.

Wozu dient PersistentKeepalive und welcher Wert ist sinnvoll?

Standard ist 0 (aus). Für Peers hinter NAT hält 25 Sekunden die UDP-Session offen; öffentlich erreichbare Peers brauchen den Wert nicht.

Brauche ich immer IP-Forwarding und NAT?

Nein. Beides ist nur nötig, wenn der Server Clients ein LAN oder das Internet bereitstellt. Ein Host-zu-Host-Tunnel kommt ohne aus.

Wie binde ich einen weiteren Client oder Standort ein?

Neues Schlüsselpaar erzeugen, freie Tunnel-IP zuweisen (z. B. 10.100.0.4/32) und einen [Peer]-Block in der Server-Config ergänzen oder zur Laufzeit mit wg set wg0 peer … hinzufügen (Schritt 8).

Was tun bei DS-Lite oder CGNAT am Anschluss?

Ohne eigene öffentliche IPv4 ist eingehend kein Portforwarding möglich. Die Seite hinter CGNAT trägt den Endpoint der erreichbaren Gegenseite ein und baut die Verbindung auf; die erreichbare Seite braucht für diesen Peer keinen Endpoint. Mit PersistentKeepalive = 25 auf der NAT-Seite bleibt die Verbindung in beide Richtungen nutzbar.

Fazit

Ein WireGuard-VPN steht in unter einer Stunde: Paket, Schlüsselpaar pro Gerät, wg0.conf, IP-Forwarding plus NAT, UDP 51820 freigeben. AllowedIPs bestimmt Routing und Zugriff zugleich; fehlende Subnetze sind die häufigste Fehlerquelle.

Weiterführende Anleitungen und Quellen

Feste IP, Gateway und DNS unter Windows und Linux einrichten – Grundlage für eindeutige Subnetze und einen erreichbaren Server-Endpunkt
pfSense/OPNsense-Firewall – Erstkonfiguration – Portforwarding und Firewall-Regeln für UDP 51820 in der Web-GUI
SSH-Key-Authentifizierung einrichten (Linux & Windows) – sicherer Admin-Zugang zum WireGuard-Server
Alle Netzwerk-Anleitungen bei Schönfelder EDV

Quellen: WireGuard Quick Start (offizielle Projekt-Doku), Debian Wiki – WireGuard, Red Hat Documentation – Setting up a WireGuard VPN, ArchWiki – WireGuard.