WireGuard „handshake did not complete“: die komplette Fix-Liste (2026)

Affiliate-Hinweis — Dieser Beitrag enthält Contabo-Affiliate-Links. Wenn du dort einen VPS holst, erhalten wir eine Provision ohne Mehrkosten für dich. Jeder Befehl und jede Konfiguration unten ist aus offiziellen WireGuard-Quellen dokumentiert und so geschrieben, dass sie auf deinem eigenen VPS reproduzierbar ist.

Du tippst wg show, du siehst deinen Peer, und direkt darunter steht die Zeile, die deinen Abend ruiniert: latest handshake ist leer, oder wg-quick warnt handshake did not complete. Dein Tunnel steht auf dem Papier, aber kein Verkehr fließt. Die gute Nachricht: WireGuard scheitert aus einer kurzen, endlichen Liste von Gründen, und sie treten in vorhersehbarer Reihenfolge auf. Dieser Leitfaden geht diese Reihenfolge vom häufigsten zum seltensten durch, damit du aufhörst zu raten und es in Minuten behebst.

WireGuard ist absichtlich stumm — es sendet nichts, solange keine Daten zu transportieren sind, und protokolliert nie ein freundliches „connection refused“. Diese Stille lässt einen fehlgeschlagenen Handshake mysteriös wirken. Fast immer ist es ein Problem der Netzwerk-Erreichbarkeit (Firewall, Port, NAT, Routing), keine Kryptografie. Arbeite die Liste von oben nach unten ab und du erwischst es.

Lies zuerst den echten Zustand mit wg show

Bevor du etwas änderst, schau, was WireGuard dir bereits sagt. Auf beiden Seiten:

sudo wg show

Du liest drei Dinge:

• latest handshake — leer oder älter als ~2 Minuten = Tunnel down. Gesund = in den letzten 120 Sekunden.
• transfer — 0 B received heißt, deine Pakete kamen nie zurück. Gesendet-aber-nichts-empfangen ist die Signatur einer einseitigen Firewall oder NAT-Blockade.
• endpoint — auf dem Server sollte hier die aktuelle öffentliche IP:Port des Clients erscheinen, sobald ein Paket ankommt. Füllt sie sich nie, hat die Initiierung des Clients dich nicht erreicht.

Lass dieses Terminal offen. Führe nach jedem Fix unten erneut wg show aus und beobachte die Zeile latest handshake. Das ist deine einzige Wahrheit — nicht das Verbindungssymbol, nicht die App.

Ursache 1 — Der UDP-Port ist blockiert (der Hauptverdächtige)

WireGuard spricht UDP auf einem einzigen Port — standardmäßig 51820. Ist dieser Port irgendwo auf dem Pfad gefiltert, stirbt das Initiierungspaket und du bekommst genau dein Symptom. Was dieser Standard bedeutet, wie du ihn änderst und korrekt öffnest, zeigt welchen Port WireGuard nutzt und wie du ihn öffnest. Meist sind zwei Firewalls zu prüfen, und man vergisst die erste:

Cloud-Provider-Firewall (die am häufigsten übersehene). Contabo, Hetzner, OVH, AWS — alle haben eine Netzwerk-Firewall oder Security Group vor deinem VPS. Eine Regel, die UDP 51820 von überall erlaubt, muss dort existieren, getrennt von der OS-Firewall. Bei den meisten Contabo-VPS-Images gibt es standardmäßig keine Provider-Firewall (gut), aber wenn du eine aktiviert hast, füge die UDP-Regel hinzu.

OS-Firewall auf dem Server. Prüfe und erlaube:

# ufw (Debian/Ubuntu)
sudo ufw allow 51820/udp
sudo ufw reload

# firewalld (Rocky/Alma/Fedora)
sudo firewall-cmd --add-port=51820/udp --permanent
sudo firewall-cmd --reload

Schneller Nachweis, dass der Port von außen erreichbar ist — von deinem Client-Rechner:

# sendet eine UDP-Sonde; "open|filtered" ohne Antwort ist nicht eindeutig,
# aber "open" oder ein zurückgegebenes Paket bestätigt die Erreichbarkeit
nc -u -z -v DEINE_SERVER_IP 51820

Sauberer Test: Führe sudo tcpdump -n -i eth0 udp port 51820 auf dem Server aus, dann verbinde vom Client. Siehst du eingehende Pakete, ist der Port offen und du gehst zur nächsten Ursache. Siehst du nichts, wird das Paket verworfen, bevor es WireGuard erreicht — bleib bei dieser Ursache.

Ursache 2 — Falscher Endpoint auf dem Client

Der [Peer]-Block des Clients braucht die echte öffentliche IP des Servers (oder den DNS-Namen) und den exakten ListenPort:

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0

Häufige Fehler, die einen toten Handshake erzeugen:

• Der Endpoint zeigt auf die private LAN-IP des Servers (10.x / 192.168.x) statt auf die öffentliche.
• Ein Tippfehler im Port, oder der Server lauscht tatsächlich auf einem anderen ListenPort.
• Die öffentliche IP des Servers hat sich geändert (manche VPS-Neuinstallationen vergeben sie neu). Bestätige mit curl -4 ifconfig.co auf dem Server, dann vergleiche mit dem Endpoint des Clients.

Der Peer-Block auf dem Server hat keine Endpoint-Zeile (der Server lernt sie, wenn das Paket des Clients ankommt) — dort eine hinzuzufügen ist ein häufiger Copy-Paste-Fehler.

Ursache 3 — Falsche AllowedIPs

AllowedIPs ist eine kryptografische Routing-Tabelle, keine Erlaubnisliste, und ein Fehler bricht den Rückverkehr still:

• Auf dem Server muss AllowedIPs des Peers nur die Tunneladresse dieses Clients listen, z. B. 10.66.66.2/32. Teilen sich zwei Peers einen überlappenden Bereich, schickt der Server Antworten an den falschen und der Handshake „schließt ab“ und stirbt dann.
• Auf dem Client routet AllowedIPs = 0.0.0.0/0 alles durch den Tunnel (Voll-VPN). Für Split-Tunneling liste nur die Subnetze, die du wirklich routest — siehe unseren Split-Tunnel-Routing-Leitfaden.

Ein Handshake, der kurz gelingt und dann stockt, ist die klassische Signatur überlappender serverseitiger AllowedIPs. Mach den Bereich jedes Peers eindeutig.

Ursache 4 — NAT-Timeout (läuft 2 Minuten, dann stirbt es)

Steht dein Client hinter NAT (Heim-Router, 4G/5G, Hotel-WLAN) und die Verbindung wird untätig, verwirft der Router das UDP-Mapping. Der Server hat dann keinen Rückweg zum Client und der Handshake läuft still ab. Der Fix liegt auf dem Peer hinter dem NAT:

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

PersistentKeepalive = 25 sendet alle 25 Sekunden ein winziges Paket und hält das NAT-Mapping offen. 25 Sekunden liegen unter jedem üblichen NAT-Timeout. Füge es auf Roadwarrior-Clients und jedem Peer hinter einem restriktiven Router hinzu. Der serverseitige Peer braucht es meist nicht.

Ursache 5 — IP-Forwarding ist auf dem Server aus

Schließt der Handshake ab, aber du erreichst kein Internet durch den Tunnel, leitet der Server keine Pakete zwischen dem WireGuard-Interface und eth0 weiter. Aktiviere es:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

Bestätige: sysctl net.ipv4.ip_forward muss 1 zurückgeben. Kombiniere es mit der Masquerade-Regel in deinem PostUp (die gebrauchsfertigen Konfigurationsvorlagen liefern diese Zeilen korrekt):

PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Ursache 6 — Uhren-Abweichung

Der Handshake von WireGuard nutzt Zeitstempel, um Replay-Angriffe zu blockieren. Weicht die Server-Uhr um mehr als ein paar Minuten ab — häufig bei frischen VPS-Images oder pausierten VMs — werden Handshakes als veraltet abgelehnt. Korrigiere die Uhr:

sudo timedatectl set-ntp true
timedatectl status   # System clock synchronized: yes

Diese ist heimtückisch, weil alles andere perfekt aussieht. Hast du Port, Schlüssel und Routing dreifach geprüft und bekommst immer noch nichts, prüfe die Uhr, bevor du verzweifelst.

Ursache 7 — Schlüssel passen nicht zusammen (prüfe das zuletzt)

Man greift zuerst zu den Schlüsseln; prüfe sie zuletzt, denn ein Schlüsselfehler ist seltener als die sechs Ursachen oben und erzeugt dasselbe Symptom. Die Regel ist einfach:

• Die [Peer] PublicKey des Servers = der öffentliche Schlüssel, abgeleitet aus der PrivateKey des Clients.
• Die [Peer] PublicKey des Clients = der öffentliche Schlüssel, abgeleitet aus der PrivateKey des Servers.

Erzeuge und leite neu ab, um sicherzugehen:

# auf jeder Maschine den öffentlichen Schlüssel aus ihrem eigenen privaten ableiten
echo "PRIVATE_KEY_DIESES_HOSTS" | wg pubkey

Vergleiche diese Ausgabe mit der PublicKey, die die andere Seite für dich hat. Ein einziger vertauschter oder abgeschnittener Schlüssel bricht den Handshake komplett. Und ein PresharedKey (falls genutzt) muss auf beiden Peers identisch sein — eine Abweichung dort tötet den Handshake ebenfalls.

Ursache 8 — MTU bricht den Tunnel direkt nach dem Handshake

Streng genommen blockiert die MTU selten den Handshake (dessen Pakete sind klein). Aber sie zerstört regelmäßig Dinge, sobald echter Verkehr fließt: Handshake schließt ab, Ping funktioniert, dann hängen Webseiten ewig. Das ist Fragmentierung. Senke die Client-MTU:

[Interface]
MTU = 1380

Finde den richtigen Wert mit einem Do-not-fragment-Ping an die Tunnel-IP des Servers und verkleinere, bis er durchgeht:

ping -M do -s 1372 10.66.66.1

1420 passt für die meisten Glasfaser-Verbindungen; 1380 ist ein sicherer Standard; PPPoE und manche Mobilfunkanbieter brauchen 1280. Unser Leitfaden zu Konfigurationsvorlagen erklärt die MTU-Abstimmung je Verbindungstyp.

Die 60-Sekunden-Diagnosereihenfolge

Wenn ein Handshake scheitert, führe genau diese Folge aus und stoppe beim ersten Fehler:

1. wg show auf beiden Seiten — gibt es irgendeinen latest handshake, irgendwelche received-Bytes?
2. tcpdump udp port 51820 auf dem Server, während der Client verbindet — kommen Pakete an?
3. Kommt kein Paket an → Firewall / Port / Endpoint (Ursachen 1-2).
4. Kommen Pakete an, aber keine Antwort zurück → serverseitige AllowedIPs, NAT, Rückroute (Ursachen 3-4).
5. Handshake schließt ab, aber kein Internet → ip_forward + Masquerade (Ursache 5).
6. Alles sieht richtig aus und trotzdem nichts → Uhren-Abweichung, dann Schlüssel, dann MTU (Ursachen 6-8).

Diese Reihenfolge entspricht der echten Häufigkeit jeder Ursache in realen Self-Host-Setups — arbeite sie von oben nach unten ab und du verschwendest keine Zeit.

Bau es von Anfang an richtig

Die meisten fehlgeschlagenen Handshakes entstehen aus einer Konfiguration, die aus drei widersprüchlichen Tutorials zusammengeflickt wurde. Von einer bekannt-guten Basis auf einem sauberen VPS zu starten entfernt 90 % der Überraschungen. Ein Contabo VPS S für 4,99 €/Monat gibt dir eine öffentliche IPv4, vollen Root und keine Provider-Firewall zum Bekämpfen — genau die Bedingungen, unter denen WireGuard „einfach funktioniert“. Folge dem Schritt-für-Schritt-Setup Contabo + WireGuard und füge eine geprüfte Konfiguration aus dem Vorlagen-Leitfaden ein, und der Handshake klappt beim ersten Versuch.

Weiterführend

• Eigenes VPN auf Contabo: vollständiger WireGuard-Leitfaden 2026
• Gebrauchsfertige WireGuard-Konfigurationsvorlagen 2026
• WireGuard-DNS-Lecks: erkennen, diagnostizieren, beseitigen
• WireGuard-Kill-Switch unter Linux: iptables + systemd
• Split-Tunnel-VPN mit Routing-Tabellen
• Glossar für selbstgehostete VPNs — AllowedIPs, MTU, NAT erklärt

Quellen und Referenzen:

• WireGuard-Whitepaper — Jason A. Donenfeld
• WireGuard-Quickstart und wg-quick-Doku
• Manpages wg(8) und wg-quick(8)
• Arch Wiki — WireGuard-Fehlerbehebung

Veröffentlicht am 2026-06-23. Diagnosereihenfolge validiert auf Debian-12- und Ubuntu-24.04-Servern mit einem Contabo VPS S, gegen WireGuard-Clients unter Linux, Windows 11, macOS und Android. Deine Verbindungsbedingungen können abweichen — bestätige immer mit wg show und tcpdump, bevor du einen Fix als endgültig betrachtest.

Hinweis: WireGuard zu betreiben und ein VPN selbst zu hosten ist in der EU, den USA, Kanada und den meisten demokratischen Ländern legal. VPNSmith veröffentlicht diesen Inhalt zu Bildungszwecken.