Ein WireGuard-VPN verbindet Homeoffice-Geräte und entfernte Standorte verschlüsselt mit deinem Firmennetz – schlank, schnell und seit Linux-Kernel 5.6 fest im Mainline-Kernel verankert. In dieser Anleitung richtest du auf einem Linux-Server (Debian 12 oder Ubuntu 24.04 LTS) einen WireGuard-Server ein, erzeugst Schlüsselpaare, schreibst die Konfigurationsdateien für Server und Clients, aktivierst IP-Forwarding samt NAT und verbindest zwei Standorte per Site-to-Site. Alle Befehle und Konfigurationen sind copy-paste-fertig und auf den KMU-Alltag zugeschnitten.

Kurzfassung: Mit apt install wireguard installieren, pro Gerät ein Schlüsselpaar via wg genkey | wg pubkey erzeugen, Server-Config nach /etc/wireguard/wg0.conf ([Interface] + je [Peer]), IP-Forwarding über /etc/sysctl.d/99-wireguard.conf dauerhaft setzen, NAT per PostUp/PostDown-Regel (MASQUERADE), UDP-Port 51820 in der Firewall öffnen und mit systemctl enable --now wg-quick@wg0 starten. AllowedIPs steuert Routing und Zugriff zugleich; bei Peers hinter NAT setzt du PersistentKeepalive = 25.

Voraussetzungen

Ein Linux-Server mit Debian 12 (Bookworm) oder Ubuntu 24.04 LTS und root- bzw. sudo-Rechten
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 als reguläres Paket verfügbar. Da das Kernelmodul seit Linux 5.6 im Mainline-Kernel steckt, ist kein DKMS-Build nötig. Installiere als root das Paket wireguard – es zieht die Userspace-Werkzeuge wg und wg-quick mit.

apt update && apt install -y wireguard

Prüfe danach, dass die Werkzeuge bereitstehen:

wg --version

Schritt 2: Schlüsselpaare erzeugen

WireGuard nutzt für jeden Peer ein eigenes Schlüsselpaar aus privatem und öffentlichem Schlüssel. Best Practice: Pro Gerät und Standort ein eigenes Paar – so kannst du später einen einzelnen Peer widerrufen, ohne die anderen anzufassen. Wechsle ins Konfigverzeichnis und setze umask 077, damit neue Dateien sofort 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 im Idealfall nie das Gerät, auf dem er gehört. Der öffentliche Schlüssel der Gegenseite landet später im jeweiligen [Peer]-Block. Der optionale Preshared-Key (gleicher Wert auf beiden Seiten) erhöht die Robustheit gegenüber künftigen Quantenangriffen.

Schritt 3: IP-Forwarding dauerhaft aktivieren

Damit der Server Pakete zwischen Tunnel und LAN bzw. Internet weiterleiten darf, muss IP-Forwarding aktiv sein. Setzt du es nur mit sysctl -w, geht die Einstellung beim Reboot verloren – lege sie deshalb 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 brauchst du nur, wenn du auch IPv6 durch den Tunnel routest. Reines Host-zu-Host-Tunneln ohne Weiterleitung ins LAN benötigt weder Forwarding noch NAT – für ein KMU-Gateway sind beide aber die Regel.

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

Die zentrale Datei ist /etc/wireguard/wg0.conf – der Dateiname (wg0) ist zugleich der Interface-Name. Sie besteht aus einem [Interface]-Block für den Server selbst und je einem [Peer]-Block pro Client. Trage die Inhalte der Schlüsseldateien ein (nicht die Dateinamen). Passe eth0 an das tatsächliche WAN-Interface deines Servers an – prüfe es mit ip route.

[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

Die PostUp-Zeile aktiviert beim Hochfahren des Tunnels die Weiterleitung und das Masquerading auf dem WAN-Interface; PostDown räumt die Regeln wieder ab. AllowedIPs = 10.100.0.2/32 im [Peer] bedeutet: Nur Pakete mit genau dieser Tunnel-IP werden diesem Client zugeordnet – mehr dazu im nächsten Schritt.

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

Auf dem Homeoffice-Gerät legst du eine eigene wg0.conf an. Der wichtigste Hebel ist AllowedIPs: Dieses Feld hat eine Doppelfunktion – es ist gleichzeitig der Routing-Tabelleneintrag (welcher Verkehr durch den Tunnel geht) und der Eingangs-Zugriffsfilter (welche Quell-IPs vom Peer akzeptiert werden). Pakete außerhalb der AllowedIPs 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:

ModusAllowedIPs (Client)Was geht durch den TunnelTypischer 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 einer Firewall sitzt – ohne diesen Wert schläft die Verbindung ein, sobald die NAT-Session der Firewall abläuft. Der Server-Endpunkt muss eine öffentlich erreichbare IP oder ein Hostname sein; eine private IP macht den initialen Handshake unmöglich.

Schritt 6: Dateirechte setzen, starten und Autostart aktivieren

Schlüsseldateien und die Config dürfen niemals welt-lesbar sein. Setze strikt chmod 600 und Besitzer root, dann starte den Tunnel.

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

systemctl enable --now wg-quick@wg0 sorgt dafür, dass der Tunnel den Reboot übersteht und sofort läuft. Auf dem Client genügt nach Anlegen der Config derselbe Befehl.

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

Du musst eingehendes UDP auf Port 51820 zulassen und das Forwarding über das WireGuard-Interface erlauben. Mit der unkomplizierten Firewall (UFW) sieht das so aus:

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

Denke daran, dass die Freigabe auch auf vorgelagerten Stellen greifen muss: Router-Portforwarding zu Hause, Security-Group beim Cloud-Anbieter oder eine vorgeschaltete Firewall. Wird das UDP-Paket dort blockiert, kommt gar kein Handshake zustande. Prüfe mit ss -uapn | grep 51820, ob der Server überhaupt lauscht.

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

Bei der Standortvernetzung tragen sich beide Seiten gegenseitig als [Peer] ein. Entscheidend: In AllowedIPs der Gegenseite stehen deren Tunnel-IP als /32 plus deren komplettes LAN-Subnetz. Lässt du das entfernte LAN weg, werden alle Pakete dorthin verworfen. Im Beispiel hat Standort A das LAN 10.1.0.0/24, Standort B das LAN 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 Standorte denselben Bereich (etwa 192.168.0.0/24), kollidiert das Routing. Bei DS-Lite oder CGNAT auf einer Seite ist dort eingehend kein Portforwarding möglich; dann lässt du auf dieser Seite den Endpoint weg, und der erreichbare Standort initiiert die Verbindung.

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

Einen neuen Client kannst du ohne Neustart des Tunnels hinzufügen – praktisch, wenn nebenbei Verbindungen laufen. Trage den öffentlichen Schlüssel und die 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. Übernimm sie anschließend dauerhaft in die wg0.conf oder setze in der Server-Config SaveConfig = true, damit Laufzeitänderungen beim Herunterfahren des Interfaces zurückgeschrieben werden.

Typische Fehler und Troubleshooting

Beginne die Diagnose immer mit wg show – die Zeile latest handshake sowie die Transferzähler verraten sofort, ob die Verbindung steht.

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

Kein Handshake, vertauschte Schlüssel: Die häufigste Ursache. Der PublicKey im [Peer] muss exakt der öffentliche Schlüssel der Gegenseite sein – niemals der eigene oder ein privater Schlüssel.
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) auf der Gegenseite, werden Pakete dorthin verworfen. AllowedIPs ist Routing und Filter zugleich.
Tunnel steht, aber kein LAN-/Internetzugriff: Fehlendes NAT/MASQUERADE oder falsches WAN-Interface (eth0 vs. ens18/enp0s3). Prüfe das echte Interface mit ip route.
Verbindung schläft ein: Bei Peers hinter NAT PersistentKeepalive = 25 vergessen. Ohne den Wert läuft die NAT-Session der Firewall ab.
IP-Forwarding nach Reboot weg: Wurde nur per sysctl -w gesetzt. Immer zusätzlich in /etc/sysctl.d/ persistieren.
Privater Endpoint: Ein Endpoint mit privater statt öffentlicher IP macht den ersten Handshake unmöglich. Bei DS-Lite/CGNAT muss der erreichbare Standort initiieren.
Überlappende Subnetze: Nutzen zwei Standorte denselben LAN-Bereich, kollidiert das Routing. Eindeutige Subnetze je Standort planen.
Zeitabweichung: Große Clock-Drifts können Handshakes und Rekeying stören. Halte 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?

WireGuard nutzt ausschließlich UDP, der Standard-Port ist 51820. Es gibt kein TCP – gib in jeder Firewall, jedem Portforwarding und jeder Cloud-Security-Group also gezielt UDP 51820 frei. Den Port kannst du im [Interface]-Block über ListenPort ändern, falls er belegt ist.

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

Beim Split-Tunnel stehen in AllowedIPs nur das Tunnel- und das Firmen-Subnetz – nur dieser Verkehr läuft durch das VPN, der restliche Internetverkehr des Clients bleibt lokal. Beim Full-Tunnel (0.0.0.0/0, ::/0) wird der gesamte Client-Verkehr durch den Server geleitet, etwa zum Schutz in fremden WLANs oder für zentrales Filtern.

Wozu dient PersistentKeepalive und welcher Wert ist sinnvoll?

Standardmäßig steht PersistentKeepalive auf 0 (aus). Sitzt ein Peer hinter NAT oder einer Firewall, hält der empfohlene Wert 25 Sekunden die UDP-Session offen, damit eingehende Pakete weiterhin zugestellt werden. Für Peers mit dauerhaft offener, öffentlicher Erreichbarkeit ist der Wert nicht nötig.

Brauche ich immer IP-Forwarding und NAT?

Nein. Forwarding und MASQUERADE sind nur nötig, wenn der Server als Gateway ein LAN oder das Internet für die Clients bereitstellt. Ein reiner Host-zu-Host-Tunnel, bei dem nur die beiden Server-Endpunkte miteinander reden, kommt ohne FORWARD-Regel und NAT aus.

Wie binde ich einen weiteren Client oder Standort ein?

Erzeuge ein neues Schlüsselpaar, weise eine freie Tunnel-IP zu (z. B. 10.100.0.4/32) und ergänze einen zusätzlichen [Peer]-Block in der Server-Config – oder füge ihn zur Laufzeit mit wg set wg0 peer … hinzu. Pro Gerät ein eigenes Schlüsselpaar erleichtert das spätere Widerrufen.

Was tun bei DS-Lite oder CGNAT am Anschluss?

Bei DS-Lite oder CGNAT ist eingehend kein Portforwarding möglich, weil dir keine eigene öffentliche IPv4 zur Verfügung steht. Lass auf dieser Seite den Endpoint weg und richte die Gegenseite mit echter öffentlicher Adresse als Initiator ein. Mit PersistentKeepalive = 25 auf der NAT-Seite bleibt die Verbindung danach in beide Richtungen nutzbar.

Fazit

Ein WireGuard-VPN ist für KMU in unter einer Stunde produktiv: Paket installieren, pro Gerät ein Schlüsselpaar, eine übersichtliche wg0.conf mit [Interface] und [Peer]-Blöcken, IP-Forwarding plus NAT und den UDP-Port 51820 freigeben. Der entscheidende Stellhebel ist AllowedIPs – es bestimmt zugleich Routing und Zugriff, weshalb fehlende Subnetze die häufigste Fehlerquelle sind. Für die Standortvernetzung trägst du beide Seiten gegenseitig ein und ergänzt das jeweils entfernte LAN. Mit eigenen Schlüsselpaaren je Gerät, strikten Dateirechten und PersistentKeepalive für NAT-Peers steht eine wartungsarme, sichere Verbindung.

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.