WireGuard „Required key not available“: 4 Ursachen und Lösung

In dmesg oder journalctl -k:

wireguard: wg0: Receiving handshake initiation from peer ... (invalid)
wireguard: wg0: Invalid handshake initiation from 203.0.113.7:51820
wireguard: wg0: Packet has unallowed src IP from peer

oder, am häufigsten zitiert:

Required key not available

Der Kernel sagt genau eine Sache: Auf einer WireGuard-Schnittstelle ist ein Paket angekommen, und kein konfigurierter Schlüssel konnte es entschlüsseln. Das Netzwerk hat funktioniert. Die Kryptografie nicht.

Diese Unterscheidung grenzt das Problem enorm ein, und deshalb helfen die üblichen Reflexe (Firewall oder Port prüfen) hier fast nie. Wäre der Port geschlossen, sähest du überhaupt nichts.

Warum die Meldung keinen Peer nennt, und das auch nie tun wird

Ein WireGuard-Paket, das der Kernel nicht entschlüsseln kann, ist aus seiner Sicht nicht von Rauschen zu unterscheiden. Es gibt kein Absenderfeld im Klartext, das sich lesen ließe. Einen Peer zu nennen hieße raten, und das Protokoll ist so gebaut, dass es nicht rät. Genau das macht WireGuard auch für Portscanner unsichtbar.

Die Meldung ist also ehrlich, für sich allein aber nutzlos. Die Information steckt woanders.

Die drei Befehle, die die Ursache eingrenzen

wg show

Lies für jeden Peer die Zeile latest handshake. Ein Peer ganz ohne Handshake hat nie einen abgeschlossen, das deutet auf die Schlüssel. Ein Peer mit altem Handshake und steigenden transfer-Zählern ist ein anderes Problem.

journalctl -k --since "10 minutes ago" | grep -i wireguard

Gleiche die Zeitstempel mit deinen eigenen Verbindungsversuchen ab. Zeilen, die nur erscheinen, wenn du dich verbinden willst, gehören dir. Zeilen, die ständig hereintröpfeln, kommen aus dem Internet, und sie sind Rauschen.

wg show wg0 public-key

Auf beiden Rechnern. Das ist die Prüfung, die die häufigste Ursache (siehe unten) klärt.

Ursache 1: ein Public Key, der nicht der ist, für den du ihn hältst

Mit Abstand die häufigste. Der Server hat einen Schlüssel, der nicht der des Clients ist, oder der Client hat noch den alten des Servers.

Die Falle hat eine bestimmte Form: PublicKey in einem Peer-Block muss der Public Key des ANDEREN Rechners sein, niemals dein eigener. Kopierst du eine Config zwischen zwei Clients und vergisst, diese Zeile zu ändern, entsteht ein Peer-Eintrag, der auf sich selbst zeigt, und jedes Paket scheitert.

Prüfe es durch direkten Vergleich:

wg show wg0 public-key

Führe den Befehl auf dem Server aus und vergleiche das Ergebnis Zeichen für Zeichen mit dem PublicKey im [Peer]-Block des Clients. Dann umgekehrt. Base64-Strings unterscheiden sich öfter um ein einziges Zeichen, als man erwartet, besonders nach dem Kopieren über einen Chat-Client, der hilfsbereit etwas abgeschnitten hat.

Ursache 2: ein Preshared Key nur auf einer Seite

PresharedKey wird in den Handshake eingemischt. Ist er auf einer Seite vorhanden und fehlt auf der anderen, oder ist er auf beiden mit unterschiedlichen Werten gesetzt, stimmen die abgeleiteten Schlüssel nicht mehr überein.

Das Symptom ist identisch mit einem falschen Public Key, deshalb verbringt man oft eine Stunde mit Ursache 1, bevor man hierauf stößt. Hast du kürzlich einen Preshared Key hinzugefügt, prüfe beide Enden, bevor du irgendetwas anderes prüfst. Wie der Mechanismus funktioniert und wie du einen Preshared Key hinzufügst, ohne dich auszusperren, steht im Leitfaden zum WireGuard Preshared Key.

Ursache 3: der Private Key wurde neu erzeugt

Alles, was das Schlüsselpaar neu erstellt, macht jeden Peer-Eintrag ungültig, der auf den alten Public Key verwies: den Client neu installieren, einen Container aus einem Image wiederherstellen, wg genkey in einem Skript ausführen, das schon einmal gelaufen ist.

Das Erkennungszeichen: Gestern lief es noch, und an der Config hat sich nichts geändert. In der Datei hat sich nichts geändert, aber der Schlüssel dahinter schon. Ein Server, der immer wieder neu aufgebaut wird, etwa eine Heimbox, die nach einem Plattenausfall neu installiert wurde, oder ein aus einem Image neu erstellter Container, ist die übliche Quelle; ein kleiner VPS mit fester öffentlicher IPv4 und Snapshots behält denselben Schlüssel auf demselben Host. Ein Contabo Cloud VPS (Affiliate-Link) kostet 5.50 € im Monat bei 24 Monaten Laufzeit, ein Snapshot inklusive (gelesen am 17. Oktober 2026), und Ultahost VPS Basic (Affiliate-Link) kostet 5.52 $ im Monat bei 24 Monaten Laufzeit, mit dedizierter IPv4 und 30 Tagen Geld-zurück-Garantie (gelesen am 21. Oktober 2026).

Wenn du das Paar ohnehin neu erstellst, erzeuge beide Seiten aus derselben Quelle. Unser kostenloser WireGuard-Config-Generator erstellt jedes Schlüsselpaar in deinem Browser und schreibt die [Peer]-Blöcke des Servers und jede Client-Datei aus demselben Material. Der Public Key, den der Server für einen Client hat, ist also konstruktionsbedingt genau der, der sich aus dem Private Key dieses Clients ableitet. Spiel den neuen [Peer]-Block mit wg set oder wg syncconf auf den laufenden Server ein, wie in WireGuard-Peer hinzufügen beschrieben, und das Schweigen des alten Eintrags hat ein Ende. Der Generator ist bis 10 Geräte kostenlos; darüber hebt WireGuard Pro (unser eigenes Produkt, einmalig 9 EUR, kein Abo) das Limit auf 250 an und liefert ein ZIP mit jeder Client-.conf und ihrem QR-Code als PNG, praktisch, um ein ganzes Büro oder eine ganze Familie in einem Rutsch einzurichten.

Ursache 4: es ist gar nicht dein Verkehr

Ein Server, der auf einem öffentlichen UDP-Port lauscht, empfängt unaufgeforderte Pakete. Scanner schicken sie ständig, und jedes erzeugt eine Zeile.

Das ist normal und erfordert nichts. Es ist Hintergrundrauschen und wird erst dann zum Signal, wenn es mit deinen eigenen Versuchen zusammenfällt. Stört dich das Volumen, senkt ein anderer Listening-Port es, aber die Log-Kategorie stummzuschalten würde die einzige Diagnose entfernen, die du hast, wenn ein echter Peer scheitert.

Die Reihenfolge, die es am schnellsten findet

1. wg show auf beiden Enden. Gar kein Handshake bestätigt ein Schlüsselproblem und kein Routing-Problem.
2. Vergleiche die Public Keys direkt mit wg show wg0 public-key, in beide Richtungen.
3. Prüfe, ob PresharedKey auf einer Seite existiert und auf der anderen nicht.
4. Schau auf die Zeitstempel. Erscheinen die Zeilen, ohne dass du etwas tust, sind es Scanner.

Ist die Schnittstelle gar nicht erst hochgekommen und wurde der Schlüssel abgelehnt, bevor überhaupt ein Handshake versucht wurde, liegt das Problem an der Form des Schlüssels, nicht an seinem Wert: Das ist key is not the correct length or format, ein Parse-Fehler mit ganz anderen Ursachen.

Schließt der Handshake doch ab und der Verkehr scheitert trotzdem, bist du hier falsch: Dann ist es entweder die MTU, wenn Seiten hängen, oder AllowedIPs, wenn das Routing falsch ist. Die umfassendere Checkliste steht in der Handshake-Fehlerbehebung.

Halte das Wesentliche griffbereit: Das kostenlose WireGuard Cheat Sheet (4-seitiges PDF, zahl, was du willst, 0 USD akzeptiert) enthält die Keepalive- und MTU-Tabellen, die Befehle wg genkey/wg pubkey/wg genpsk und die vier einzeiligen Server-Prüfungen, die du zuerst ausführst, wenn ein Tunnel keinen Verkehr durchlässt. Das kostenpflichtige WireGuard Self-Hosting Kit (9 USD) ergänzt eine Checkliste zur Fehlerbehebung mit 12 Ursachen und 11 Config-Vorlagen.