WireGuard 2026: So verbindest Du Cloud Server sicher miteinander

Aktualisiert am 16. September 2026, erstmals veröffentlicht am 14. Oktober 2024

Für dieses Update habe ich das Setup aus der ersten Version dieses Artikels noch einmal von null aufgebaut: zwei Cloud Server, auf dem einen eine Webanwendung, auf dem anderen Redis als Session-Speicher. Redis überträgt Daten ohne eigene TLS-Konfiguration im Klartext. Stehen beide Server nicht im selben privaten Netz, wandern Session-Daten und Passwörter offen durchs Internet.

In den zwei Jahren seit dem ersten Artikel hat sich bei WireGuard einiges getan. Die Windows-Version hat nach einer wochenlangen Sperre durch Microsoft endlich Version 1.0 erreicht, und die aktuellen Server-Distributionen liefern das Kernelmodul ab Werk.

Warum unverschlüsselte Serververbindungen ein Problem sind

HTTPS schützt Deine Website, SSH Deinen Admin-Zugang. Viele Dienste im Hintergrund haben aber gar keine Verschlüsselung eingebaut oder nur eine, die Du erst mit Zertifikaten einrichten musst. Typische Beispiele sind Redis, NFS-Freigaben ohne Kerberos, der Prometheus node_exporter, der seine Metriken per HTTP ausliefert, und Datenbankreplikationen, bei denen niemand die TLS-Option gesetzt hat.

Du kannst jeden dieser Dienste einzeln absichern. Bei drei Diensten auf vier Servern sind das zwölf Stellen, an denen Zertifikate ablaufen können. Ein VPN-Tunnel verschlüsselt den gesamten Verkehr zwischen den Servern an einer einzigen Stelle. Welche weiteren Grundregeln für Deine Server gelten, haben wir im Beitrag Wie Du Deine Webseite sicher hältst zusammengefasst.

Was ist WireGuard?

WireGuard ist ein freies VPN-Protokoll und zugleich die gleichnamige Software, die Jason A. Donenfeld seit 2015 entwickelt. Es arbeitet auf Layer 3 des OSI-Modells, transportiert also IP-Pakete, und schickt sie verschlüsselt per UDP an die Gegenstelle. Seit Kernel 5.6 aus dem Jahr 2020 ist WireGuard Teil von Linux. Offizielle Clients gibt es für Windows, macOS, iOS und Android, dazu Kernel-Implementierungen für FreeBSD und OpenBSD.

Auf dem Server erscheint WireGuard als normales Netzwerkinterface, meist mit dem Namen wg0. Du vergibst eine IP-Adresse, setzt Routen und Firewallregeln mit den Werkzeugen, die Du ohnehin kennst.

Die Kryptografie ist fest vorgegeben: Curve25519 für den Schlüsselaustausch, ChaCha20 und Poly1305 für Verschlüsselung und Authentifizierung, BLAKE2s als Hashfunktion und das Noise-Framework für den Handshake. Client und Server müssen keine Verfahren aushandeln. Deshalb kann auch niemand versehentlich ein schwaches erlauben.

Cryptokey Routing: Wie WireGuard entscheidet, wer was darf

Jede Gegenstelle heißt bei WireGuard Peer und besteht aus einem öffentlichen Schlüssel und einer Liste erlaubter Adressen, den AllowedIPs. Diese Liste erfüllt zwei Aufgaben.

Beim Senden funktioniert sie wie eine Routingtabelle. Ein Paket an 10.10.0.2 geht verschlüsselt an genau den Peer, dem diese Adresse zugeordnet ist. Beim Empfangen wirkt sie wie eine Zugriffsliste. Kommt ein entschlüsseltes Paket mit einer Absenderadresse an, die nicht zum Schlüssel des Peers passt, verwirft WireGuard es.

Deshalb kannst Du in der Firewall alles erlauben, was von 10.10.0.2 auf wg0 ankommt. Diese Absenderadresse kann nur der Server nutzen, der den passenden privaten Schlüssel besitzt.

WireGuard, OpenVPN und IPsec im Vergleich

Für Verbindungen zwischen Servern mit festen IP-Adressen macht WireGuard 2026 den geringsten Aufwand. OpenVPN behält seinen Platz, wenn Laptops aus Hotel- oder Firmennetzen kommen, die nur TCP auf Port 443 durchlassen.

Was sich 2026 bei WireGuard getan hat

Die größte Geschichte des Jahres spielte unter Windows. Microsoft hatte für sein Windows Hardware Program eine Pflichtprüfung der Identität eingeführt, die am 16. Oktober 2025 startete und nur 30 Tage offen stand. Donenfeld erhielt nach eigener Aussage keine Benachrichtigung. Sein Konto wurde gesperrt, und ohne dieses Konto kann er keine Windows-Treiber signieren. Im Frühjahr 2026 konnte er deshalb keine Updates für WireGuard unter Windows ausliefern. Die Entwickler von VeraCrypt und Windscribe traf es genauso.

Nach der Freischaltung erschien im April 2026 zuerst Version 0.6.1, das erste Windows-Update seit Jahren. Am 18. April folgte Version 1.0 von WireGuard für Windows und dem Kerneltreiber WireGuardNT. Laut Donenfelds Ankündigung enthält sie 42 Fehlerkorrekturen. Außerdem erkennt der Treiber MTU-Änderungen jetzt sofort, vorher hat er alle drei Sekunden nachgefragt. Wenn Du WireGuard unter Windows nutzt, prüfe im Client, ob der eingebaute Updater die 1.0 schon installiert hat.

Auch bei den VPN-Anbietern hat sich die Richtung verfestigt. Mullvad hat OpenVPN am 15. Januar 2026 von allen Servern und aus allen Apps entfernt und setzt nur noch auf WireGuard.

Offen bleibt das Thema Quantencomputer. Der Schlüsselaustausch mit Curve25519 gilt nicht als quantensicher. Überträgst Du Daten, die auch in zehn Jahren noch vertraulich bleiben müssen, setze in der Konfiguration zusätzlich einen PresharedKey pro Peer. Dieser symmetrische Schlüssel fließt in den Handshake ein und schützt gegen Angreifer, die heute Verkehr mitschneiden, um ihn später zu entschlüsseln. Das Projekt Rosenpass handelt diesen Schlüssel mit Post-Quanten-Verfahren aus und tauscht ihn regelmäßig, WireGuard selbst verschlüsselt weiter die Daten.

Anleitung: Zwei Cloud Server mit WireGuard verbinden

Mein Testaufbau besteht aus zwei Cloud Servern mit Debian 13. Auf Server A läuft die Anwendung, auf Server B Redis. Redis soll nur über den Tunnel erreichbar sein und nie direkt aus dem Internet.

Alle Adressen sind Beispielwerte, ersetze sie durch Deine eigenen. Das Tunnelnetz 10.10.0.0/24 darf sich nicht mit einem privaten Netz überschneiden, das Du bereits nutzt. Ich arbeite als root. Mit einem normalen Benutzer setzt Du sudo vor die Befehle.

1. Werkzeuge installieren (auf beiden Servern)

apt update
apt install wireguard-tools

WireGuard steckt seit Linux 5.6 im Kernel. Bei Debian 13 sowie Ubuntu 24.04 und 26.04 ist das Modul also schon an Bord, Du brauchst nur die Werkzeuge wg und wg-quick. Ältere Anleitungen, die dafür Debian unstable oder ein PPA einbinden, kannst Du ignorieren.

2. Schlüssel erzeugen (auf beiden Servern)

cd /etc/wireguard
umask 077
wg genkey | tee private.key | wg pubkey > public.key
cat public.key

umask 077 sorgt dafür, dass nur root die neuen Dateien lesen kann, allerdings nur in dieser Shell-Sitzung. Der private Schlüssel verlässt den Server nie. Zur Gegenstelle kopierst Du nur die Zeile, die cat public.key ausgibt.

3. Konfiguration anlegen

Auf Server A legst Du die Datei /etc/wireguard/wg0.conf an. Den eigenen privaten Schlüssel zeigt Dir cat /etc/wireguard/private.key.

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = PRIVATER_SCHLUESSEL_VON_A

[Peer]
PublicKey = OEFFENTLICHER_SCHLUESSEL_VON_B
Endpoint = 203.0.113.20:51820
AllowedIPs = 10.10.0.2/32

Auf Server B sieht dieselbe Datei spiegelverkehrt aus:

[Interface]
Address = 10.10.0.2/24
ListenPort = 51820
PrivateKey = PRIVATER_SCHLUESSEL_VON_B

[Peer]
PublicKey = OEFFENTLICHER_SCHLUESSEL_VON_A
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.10.0.1/32

Vergiss den ListenPort auf Server B nicht. Ohne diese Zeile wählt WireGuard einen zufälligen Port, und Server A erreicht B unter Port 51820 nicht mehr. Weil der private Schlüssel in der Datei steht, schützt Du sie auf beiden Servern:

chmod 600 /etc/wireguard/wg0.conf

Einen PersistentKeepalive brauchst Du zwischen zwei Servern mit festen öffentlichen Adressen nicht. Der Wert wird erst wichtig, wenn ein Peer hinter NAT sitzt, etwa an einem DSL-Anschluss.

Statt der IP-Adresse kannst Du beim Endpoint auch einen Hostnamen eintragen, den Du in Deinem DNS pflegst. wg-quick löst den Namen aber nur einmal beim Start des Tunnels auf. Ändert sich die IP später, startest Du den Tunnel neu.

Die MTU leitet wg-quick von der Netzwerkschnittstelle ab, über die die Gegenstelle erreichbar ist, und zieht 80 Byte für den WireGuard-Overhead ab. Bei der üblichen MTU von 1500 ergibt das 1420. Ist die MTU irgendwo auf dem Weg zwischen den Servern kleiner, als die Schnittstelle meldet, klappt zwar der Ping, größere Übertragungen hängen aber. Dann trägst Du im [Interface]-Block einen kleineren Wert ein, zum Beispiel MTU = 1380.

4. Firewall einrichten (auf beiden Servern)

WireGuard braucht genau einen UDP-Port, und den öffne ich nur für die Adresse der Gegenstelle. Der Verkehr im Tunnel kommt aber auf dem Interface wg0 an und braucht eigene Regeln. Fehlen sie, scheitern Ping und Redis-Verbindung, obwohl der Handshake klappt.

Hat Dein Cloud Server zusätzlich eine Firewall im Kundenpanel, muss UDP 51820 auch dort für die Gegenstelle offen sein. Sonst kommt kein Paket bis zur Firewall auf dem Server.

Für die Firewall auf dem Server zeige ich zwei Wege, nftables direkt oder ufw unter Ubuntu. Nutze nur einen davon. ufw schreibt seine Regeln unter Ubuntu über iptables-nft ebenfalls in nftables. Aktivierst Du zusätzlich den nftables-Dienst, löscht dessen flush ruleset die Regeln von ufw, sobald der Regelsatz nach ufw geladen wird. Das passiert beim Booten genauso wie bei jedem späteren nft -f. Bleiben beide Regelsätze aktiv, muss jedes Paket durch beide hindurch, und eine Freigabe in ufw hilft nichts, wenn nftables das Paket verwirft.

Variante 1: nftables

Die Beispieldatei /etc/nftables.conf von Debian legt zwar Tabelle und Ketten an, setzt aber keine Policy und lässt deshalb alles durch. Ich schreibe den Regelsatz komplett neu. Falls nftables fehlt, installierst Du es mit apt install nftables.

Auf Server B enthält /etc/nftables.conf Folgendes:

#!/usr/sbin/nft -f
flush ruleset
table inet filter {
 chain input {
 type filter hook input priority filter; policy drop;
 ct state established,related accept
 ct state invalid drop
 iif "lo" accept
 meta l4proto { icmp, ipv6-icmp } accept
 tcp dport 22 accept
 ip saddr 203.0.113.10 udp dport 51820 accept
 iifname "wg0" ip saddr 10.10.0.1 tcp dport 6379 accept
 }
 chain forward {
 type filter hook forward priority filter; policy drop;
 }
 chain output {
 type filter hook output priority filter;
 }
}

Auf Server A trägst Du in der WireGuard-Zeile ip saddr 203.0.113.20 ein und lässt die Zeile mit Port 6379 weg.

Ich verwende iifname statt iif, weil iif nicht den Namen der Schnittstelle speichert, sondern ihre interne Nummer. Wird die Firewall beim Booten geladen, existiert wg0 noch nicht, und der gesamte Regelsatz bricht mit einer Fehlermeldung ab. Ein Neustart des Tunnels mit systemctl restart wg-quick@wg0 ist nicht hilfreich. wg0 bekommt dabei eine neue Nummer, und die Regel greift nicht mehr, ohne dass eine Meldung erscheint. iifname vergleicht den Namen und funktioniert in beiden Fällen.

Bevor Du die Regeln aktivierst, prüfst Du die Syntax und lässt eine zweite SSH-Sitzung offen. Stimmt etwas nicht, kommst Du so noch auf den Server.

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

flush ruleset löscht beim Laden alle bestehenden Regeln, auch die anderer Programme. Läuft auf dem Server Docker, ergänzt Du die Regeln deshalb besser einzeln in Deiner vorhandenen Konfiguration.

Variante 2: ufw unter Ubuntu

Auf Server B sind es diese Befehle:

ufw allow OpenSSH
ufw allow from 203.0.113.10 to any port 51820 proto udp
ufw allow in on wg0 from 10.10.0.1 to any port 6379 proto tcp
ufw enable

Auf Server A genügen die erste Zeile, die zweite mit from 203.0.113.20 und ufw enable. Ping erlaubt ufw von Haus aus.

5. Tunnel starten und prüfen (auf beiden Servern)

systemctl enable --now wg-quick@wg0
wg show

Beim ersten Mal hat mich irritiert, dass wg show keinen Handshake anzeigt. Das ist Absicht, denn WireGuard bleibt stumm, bis tatsächlich ein Paket durch den Tunnel soll. Auf Server A schicke ich deshalb einen Ping los:

ping -c 3 10.10.0.2
wg show

Jetzt zeigt wg show beim Peer den Zeitpunkt des letzten Handshakes, und die Zähler für gesendete und empfangene Daten laufen hoch. Bleibt der Handshake aus, findest Du die häufigsten Ursachen in der Tabelle: Typische Fehler und schnelle Lösungen weiter unten.

6. Redis an den Tunnel binden (auf Server B)

apt install redis-server

Unter Debian lauscht Redis nach der Installation nur auf localhost, in der Konfiguration steht dafür bind 127.0.0.1 -::1. Damit Server A es über den Tunnel erreicht, ersetzt Du diese Zeile in /etc/redis/redis.conf und setzt ein Passwort:

bind 127.0.0.1 -::1 10.10.0.2
requirepass DEIN_LANGES_PASSWORT

Das Minus vor ::1 bedeutet, dass Redis auch dann startet, wenn es die Adresse ::1 auf dem Server nicht gibt, etwa weil IPv6 abgeschaltet ist. Vor 10.10.0.2 steht bewusst kein Minus, denn fehlt die Tunneladresse, soll Redis nicht still ohne sie starten. Ein zufälliges Passwort erzeugst Du mit openssl rand -hex 32.

Das Passwort ist Pflicht. Seit Redis 7 lässt der Protected Mode ohne Passwort nur Verbindungen von localhost zu, auch wenn Redis auf der Tunneladresse lauscht. Server A bekäme sonst die Fehlermeldung DENIED Redis is running in protected mode.

Achte außerdem auf die Startreihenfolge. Ist wg0 beim Booten noch nicht aktiv, kann Redis die Tunneladresse nicht binden und startet nicht. Mit systemctl edit redis-server legst Du deshalb einen Drop-in an. Den Inhalt schreibst Du in den freien Bereich direkt unter der Zeile ### Anything between here and the comment below will become the contents of the drop-in file. Alles unterhalb von ### Edits below this comment will be discarded verwirft systemd beim Speichern.

[Unit]
After=wg-quick@wg0.service
Wants=wg-quick@wg0.service

Danach startest Du Redis neu und prüfst, auf welchen Adressen es lauscht:

systemctl restart redis-server
ss -tlnp | grep 6379

In der Ausgabe sollten 127.0.0.1:6379, [::1]:6379 und 10.10.0.2:6379 stehen, aber keine öffentliche Adresse und keine Wildcard wie 0.0.0.0, * oder [::]. Ist IPv6 abgeschaltet, fehlt die Zeile mit [::1], das ist in Ordnung.

Diese Anleitung geht davon aus, dass Redis direkt auf dem Server läuft. Startest Du Redis in einem Docker-Container mit -p 6379:6379, leitet Docker den Verkehr per DNAT über die Forward-Kette an den Container weiter. Die Input-Regel für Port 6379 greift dann nicht, und Redis kann trotz Firewall aus dem Internet erreichbar sein. Veröffentliche den Port in diesem Fall nur auf der Tunneladresse, etwa mit -p 10.10.0.2:6379:6379. Damit der Container erst startet, wenn die Tunneladresse existiert, bekommt docker.service denselben Drop-in mit After= und Wants=.

Auf Server A teste ich die Verbindung mit dem Redis-Client. –askpass fragt das Passwort ab, ohne dass es in der Shell-Historie landet:

apt install redis-tools
redis-cli -h 10.10.0.2 --askpass ping

Kommt PONG zurück, steht die Verbindung. In Deiner Anwendung trägst Du als Host 10.10.0.2, Port 6379 und das Passwort ein.

Weitere Server hinzufügen

Kommt ein dritter Server C mit der öffentlichen Adresse 203.0.113.30 und der Tunneladresse 10.10.0.3 dazu, kommt es auf die Reihenfolge an. Startest Du den Tunnel auf C, bevor A und B den neuen Peer kennen, schlägt der Ping fehl, und Du suchst den Fehler an der falschen Stelle.

Jeder Server hat dann zwei Gegenstellen. In nftables fasst Du die WireGuard-Regel deshalb als Set zusammen. Auf Server C sieht sie so aus:

ip saddr { 203.0.113.10, 203.0.113.20 } udp dport 51820 accept

Auf A stehen im Set 203.0.113.20 und 203.0.113.30, auf B 203.0.113.10 und 203.0.113.30. Unter ufw legst Du pro Gegenstelle eine eigene ufw allow-Zeile an. So gehe ich vor:

1. Auf Server C führst Du die Schritte 1 bis 4 aus. In wg0.conf trägst Du A und B als Peers ein, in der Firewall verwendest Du das Set von oben. Die Redis-Regel brauchst Du auf C nicht. Den Tunnel startest Du noch nicht.
2. Auf A und B ergänzt Du je einen [Peer]-Block für C mit Endpoint = 203.0.113.30:51820 und AllowedIPs = 10.10.0.3/32 und nimmst 203.0.113.30 in das Set der Firewall auf. Soll C auch auf Redis zugreifen, erweiterst Du auf Server B die Redis-Regel zu iifname “wg0” ip saddr { 10.10.0.1, 10.10.0.3 } tcp dport 6379 accept.
3. Auf A und B lädst Du die geänderte Konfiguration ohne Verbindungsabbruch neu:

 wg syncconf wg0 <(wg-quick strip wg0)
 nft -f /etc/nftables.conf

4. Erst jetzt startest Du auf C den Tunnel wie in Schritt 5 und testest mit ping -c 3 10.10.0.1 und ping -c 3 10.10.0.2.

Die Schreibweise <(…) funktioniert nur in der Bash, nicht in der einfachen sh. wg syncconf übernimmt außerdem nur die Peers, keine Adressen und Routen. Solange der neue Server im Netz 10.10.0.0/24 liegt, reicht das, weil die Route dafür schon existiert. Mit ufw entfällt die nft-Zeile, eine Regel mit ufw allow gilt sofort.

Jeder Server muss jeden anderen kennen. Bei zehn Servern sind das 45 Verbindungen und damit 90 [Peer]-Blöcke, jeder mit passender Firewall-Regel. Spätestens dann lohnen sich Werkzeuge wie Headscale oder NetBird, die WireGuard-Netze zentral verwalten. Möchtest Du statt Servern Laptops und Smartphones anbinden, inklusive Internetzugang über den Server, findest Du die passende Schritt-für-Schritt-Anleitung in unserem Helpdesk.

Typische Fehler und schnelle Lösungen

Den letzten Fall beschreibt ein Nutzer in den Play-Store-Rezensionen der Android-App, nachdem er eine Portnummer an der falschen Stelle eingetragen hatte.

Wann WireGuard nicht die richtige Wahl ist

Blockiert ein Netzwerk UDP, kommt WireGuard nicht durch. In solchen Umgebungen ist OpenVPN über TCP 443 zuverlässiger. Varianten wie AmneziaWG tarnen den Verkehr zwar, funktionieren aber nicht mehr mit normalen WireGuard-Clients zusammen.

Benutzerverwaltung, Single Sign-on und automatisch vergebene Adressen fehlen im Protokoll. Das übernehmen die oben genannten Verwaltungswerkzeuge, die WireGuard als Unterbau nutzen.

Außerdem merkt sich jeder Server die letzte öffentliche IP-Adresse seiner Peers, bis das Interface neu startet. Zwischen Deinen eigenen Servern spielt das keine Rolle, für einen Dienst mit No-Log-Versprechen schon.

WireGuard auf Deinem Server bei hosting.de

Auf unseren Cloud Servern und VPS wählst Du das Betriebssystem selbst. Mit Debian oder Ubuntu ist WireGuard nach dem apt install aus Schritt 1 einsatzbereit. Wenn Du Dich lieber um Dein Projekt als um Firewallregeln kümmerst, sieh Dir unsere Managed Server an und frag unseren Support, wie wir die Verbindung Deiner Server umsetzen.

Bevor Du einen Tunnel baust, lohnt sich ein Befehl. Ich starte auf jedem Server mit ss -tulpn und sehe mir an, welche Dienste auf öffentlichen Adressen lauschen. Alles in dieser Liste, das nur für andere Server gedacht ist, gehört hinter WireGuard.

Häufige Fragen

Ist WireGuard sicher? WireGuard nutzt ausschließlich moderne, fest vorgegebene Verfahren wie Curve25519 und ChaCha20-Poly1305. Der kleine Code lässt sich vollständig prüfen, und das Protokoll wurde formal verifiziert. Nicht quantensicher ist der Schlüsselaustausch, dafür gibt es den optionalen PresharedKey.

Welchen Port nutzt WireGuard? Üblich ist UDP-Port 51820. Der Port ist nur eine Konvention, Du kannst unter ListenPort jeden freien UDP-Port eintragen.

Ist WireGuard schneller als OpenVPN? In der Regel ja. WireGuard läuft unter Linux direkt im Kernel und verschlüsselt mit schlanken Verfahren, OpenVPN arbeitet überwiegend im Userspace. Wie groß der Unterschied ist, hängt von Prozessor und Leitung ab.

Funktioniert WireGuard mit der FRITZ!Box? Ja, seit FRITZ!OS 7.50. Die FRITZ!Box erzeugt eine Konfigurationsdatei, die Du in die WireGuard-App importierst. Steht dort AllowedIPs = 0.0.0.0/0, läuft Dein gesamter Verkehr über den Tunnel. Soll nur das Heimnetz erreichbar sein, trägst Du stattdessen dessen Adressbereich ein.

Ist WireGuard kostenlos? Ja. Die Kernelkomponenten stehen unter der GPLv2, die übrigen Teile unter freien Lizenzen wie MIT oder Apache 2.0.

Quellen: wireguard.com, Ankündigung „WireGuard for Windows and WireGuardNT, Version 1.0“ vom 18. April 2026 auf lists.zx2c4.com, git.zx2c4.com/wireguard-tools.

Artikel von

Frederick Schiwek

Hallo! Ich bin Freddy, Autor und Mitglied des Teams von hosting.de. Mit über 20 Jahren Erfahrung im Hosting-Business schreibe ich über Technologie, das Internet und die Zukunft der digitalen Infrastruktur. Ob Domains, Hosting oder Cloud-Dienste – ich bin hier, um Einblicke und Ideen zu teilen!