WireGuard PersistentKeepalive: den Tunnel hinter NAT erreichbar halten (2026)

Affiliate-Hinweis - Dieser Beitrag enthält Contabo-Affiliate-Links. Wenn du über sie einen VPS holst, erhalten wir eine Provision ohne Mehrkosten für dich. Jeder Wert und jedes Verhalten weiter unten ist aus offiziellen WireGuard-Quellen dokumentiert und so geschrieben, dass es auf deiner eigenen Maschine reproduzierbar ist.

Dein WireGuard-Client verbindet sich, läuft eine Minute und wird dann still: Du erreichst den Server vom Client aus, aber der Server kann dir nichts mehr zurückschicken. SSH von der Serverseite hängt, ein LAN-Gerät hinter dem Client wird unerreichbar, der Handshake veraltet lautlos. Die Lösung ist fast immer eine Zeile auf dem Client: PersistentKeepalive = 25. Dieser Leitfaden erklärt genau, was diese Option tut, warum 25 Sekunden die magische Zahl ist und auf welche Seite des Tunnels sie gehört.

Die kurze Antwort

Wenn ein Peer hinter NAT sitzt und erreichbar bleiben muss, füge dies dem [Peer]-Block in der Konfiguration dieses Peers hinzu:

[Peer]
PublicKey = ...
Endpoint = server.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Starte den Tunnel neu, und das Problem des stillen Tunnels nach Leerlauf verschwindet. Alles darunter ist das Warum.

Was PersistentKeepalive tut

Von Haus aus ist WireGuard still: Wenn es nichts zu senden gibt, sendet es nichts. Keine Keepalives, keine Heartbeats, kein Geplauder. Das macht es effizient und schwer zu fingerprinten - aber es bricht ein bestimmtes Szenario.

Wenn ein Client hinter NAT sitzt (ein Heimrouter, ein Mobilfunkanbieter, eine Bürofirewall), erstellt das NAT-Gerät ein temporäres Mapping, sobald der Client zum ersten Mal ein Paket nach draußen sendet. Dieses Mapping ist es, das den Server seine Antworten zurück an die richtige interne Adresse schicken lässt - stell es dir als ein in das NAT gestanztes Loch vor. Entscheidend ist: Dieses Loch läuft nach einer Phase der Untätigkeit ab, bei UDP oft irgendwo zwischen 30 Sekunden und ein paar Minuten. Sobald es sich schließt, haben die Pakete des Servers kein Ziel mehr, und der Peer wird unerreichbar, bis der Client wieder spricht.

PersistentKeepalive löst das, indem es alle N Sekunden ein kleines, leeres Keepalive-Paket an den Peer sendet. Dieses winzige bisschen Verkehr hält das NAT-Mapping frisch, sodass sich das Loch nie schließt und der Peer selbst im Leerlauf erreichbar bleibt.

Verkabelung und Netzwerktechnik in einem Rechenzentrum-Rack - die Seite mit öffentlicher IP eines selbst gehosteten WireGuard-Tunnels

Warum 25 Sekunden

Die offizielle WireGuard-Empfehlung sind 25 Sekunden, und die Begründung ist einfach. Übliche UDP-NAT-Timeouts liegen zwischen 30 Sekunden und ein paar Minuten, und der kürzeste Wert, den man regelmäßig antrifft, liegt bei rund 30 Sekunden. Ein Keepalive alle 25 Sekunden hält das Mapping mit einem kleinen Puffer vor dieser 30-Sekunden-Grenze frisch - häufig genug, um das Loch nie schließen zu lassen, selten genug, um fast nichts zu kosten.

Du kannst niedriger gehen, wenn dein NAT ungewöhnlich aggressiv ist (15 ist ein sinnvoller nächster Schritt), oder höher, um auf Mobilgeräten Akku zu sparen, aber 25 ist der dokumentierte Standard, und das nicht ohne Grund. Denk nicht zu viel darüber nach.

Wohin damit: Client vs. Server

Das ist der Teil, den die Leute falsch machen. Das Keepalive gehört auf den Peer, der durch ein NAT erreichbar bleiben muss:

Aufbau	Keepalive auf dem Client?	Keepalive auf dem Server?
Mobiler Client hinter NAT -> Server mit öffentlicher IP	Ja (`= 25`)	Nein
Server mit sauberer öffentlicher IP	(entfällt)	Nicht nötig
Beide Enden hinter NAT (Peer-to-Peer)	Ja	Ja

Im Normalfall - ein Laptop oder Handy hinter einem Router, das mit einem VPS mit echter öffentlicher IP spricht - braucht nur der Client PersistentKeepalive = 25, im [Peer]-Block, der den Server beschreibt. Der Server braucht keins in Richtung seiner Clients: Der Client initiiert immer, und der Server antwortet einfach an die Quelladresse, von der das letzte Paket kam. Ein Server mit sauberer öffentlicher IP ist genau der Aufbau, bei dem du das NAT-Problem auf der Serverseite völlig vermeidest.

Beispiel für eine [Peer]-Konfiguration

Hier ist ein vollständiger Peer-Block auf Client-Seite mit dem Keepalive an Ort und Stelle:

[Interface]
PrivateKey = <client-private-key>
Address = 10.66.66.2/32
DNS = 10.66.66.1

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Wende es mit einem Tunnel-Neustart an:

sudo wg-quick down wg0 && sudo wg-quick up wg0

Bestätige, dass es wirksam wurde - wg show listet das Intervall unter dem Peer auf:

sudo wg show
# persistent keepalive: every 25 seconds

Wenn du Konfigurationen von Grund auf zusammenstellst, enthalten die gebrauchsfertigen WireGuard-Konfigurationsvorlagen die Keepalive-Zeile bereits im richtigen Block für jede Plattform.

Der Fehler "interval must be in range"

PersistentKeepalive erwartet eine schlichte ganze Zahl von Sekunden, geprüft gegen den Bereich 0 bis 65535. Wenn du interval must be in range oder must be in range 0 to 65535 siehst, hast du etwas übergeben, das keine gültige Ganzzahl in diesem Fenster ist:

Ein Einheitensuffix - schreibe 25, nicht 25s.
Eine Dezimalzahl - 25, nicht 25.0.
Eine negative Zahl oder ein Wert über 65535.
Ein Fremdleerzeichen oder unsichtbares Zeichen, aus einer Webseite kopiert.

Ein Wert von 0 ist zulässig und bedeutet deaktiviert - genauso, als ließe man die Zeile ganz weg. PersistentKeepalive = 0 bringt also nichts Nützliches; nutze ein echtes Intervall wie 25.

Keepalive gesetzt, funktioniert aber trotzdem nicht

Wenn du die Zeile hinzugefügt hast und der Tunnel nach Leerlauf trotzdem verstummt, arbeite diese ehrlichen Ursachen der Reihe nach ab:

Auf der falschen Seite gesetzt. Der Peer hinter NAT ist der, der es braucht. Ein Keepalive nur auf dem Server mit öffentlicher IP hält das NAT-Loch eines Clients nicht offen.
NAT-Timeout kürzer als dein Intervall. Manches Carrier-Grade-NAT schließt UDP-Mappings schneller als 30 Sekunden. Senke das Intervall auf 15 und teste erneut.
Eine Firewall blockiert den Pfad. Ist der zugrunde liegende UDP-Port gefiltert, kommt kein Keepalive durch - bestätige, dass der WireGuard-Port tatsächlich offen ist an beiden Enden.
Der Endpoint hat sich geändert (Roaming). Wenn der Client das Netz gewechselt hat und seine öffentliche Adresse sich änderte, zielt der Server womöglich noch auf den alten Endpoint. Das Keepalive hilft dem Server, die neue Quelle zu verfolgen, aber ein veralteter Endpoint auf Client-Seite kann trotzdem danebengehen.

Keepalive vs. WireGuard-Handshake

Das sind zwei verschiedene Timer, und es hilft, sie zu trennen. WireGuard erneuert seinen kryptografischen Handshake etwa alle zwei Minuten - aber nur, wenn tatsächlich Verkehr zu schützen ist. Auf einer untätigen Verbindung ohne Keepalive bedeutet kein Verkehr keine Handshake-Erneuerung, und in der Zwischenzeit schließt sich das NAT-Loch still und leise.

PersistentKeepalive füllt genau diese Lücke: Es hält einen Faden Verkehr auf einer sonst untätigen Verbindung aufrecht und hält das NAT-Mapping zwischen den Handshakes offen, damit der Tunnel bereit ist, sobald echte Daten fließen müssen. Das Keepalive ersetzt den Handshake nicht; es hält den Pfad lebendig, damit der Handshake stattfinden kann, wenn er gebraucht wird.

Ein Server mit öffentlicher IP löst die halbe Sache

Die meisten Keepalive-Kopfschmerzen kommen von NAT auf der Server-Seite - eine VPN-Box hinter einem Heimrouter, doppeltes NAT, eine Anbieterfirewall. Setze den Server auf eine saubere öffentliche IPv4, und das einzige verbleibende NAT ist das des Clients, wo ein einziges PersistentKeepalive = 25 alles ist, was du brauchst. Ein Contabo Cloud VPS 10 für 5,50 EUR/Monat gibt dir vollen Root-Zugriff und eine echte öffentliche IP ohne Anbieterfirewall, gegen die man kämpfen müsste - genau die Bedingungen, unter denen das Keepalive auf Client-Seite das einzige ist, was du setzen musst. Um die NAT-Mechanik zu verstehen, die diese Option umgeht, siehe die einfach erklärte Antwort, was NAT ist.

Weiterführend

Quellen und Referenzen:

Veröffentlicht am 2026-06-29. Die 25-Sekunden-Empfehlung und das Verhalten von PersistentKeepalive stammen aus der offiziellen WireGuard-Dokumentation; NAT-Timeout-Bereiche variieren je nach Gerät, bestätige also anhand deines eigenen Routers oder Anbieters, falls ein kürzeres Intervall nötig ist.

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 diese Inhalte zu Bildungszwecken.

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert

Hoste dein VPN auf deinem eigenen VPS → ContaboVoller Root-Zugriff · öffentliche IPv4 · wähle deine Region→

Häufig gestellte Fragen

Was macht PersistentKeepalive in WireGuard?

PersistentKeepalive ist eine Option im [Peer]-Abschnitt einer WireGuard-Konfiguration, die die Schnittstelle veranlasst, alle N Sekunden ein kleines leeres Keepalive-Paket an diesen Peer zu senden, auch wenn kein echter Verkehr fließt. Standardmäßig ist WireGuard still: Auf einer untätigen Verbindung sendet es nichts. Diese Stille ist ein Problem, wenn ein Client hinter NAT sitzt, denn das NAT-Mapping - das Loch, durch das der Server zum Client zurückfindet - läuft nach einer kurzen Leerlaufzeit ab. Das periodische Keepalive hält dieses Mapping offen, sodass der Peer erreichbar bleibt. Du aktivierst es mit einer Zeile: PersistentKeepalive = 25.

Warum ist der empfohlene PersistentKeepalive-Wert 25 Sekunden?

Die offizielle WireGuard-Empfehlung sind 25 Sekunden. UDP-NAT-Mappings auf Heimroutern und in Carrier-Grade-NAT laufen typischerweise irgendwo zwischen 30 Sekunden und ein paar Minuten ab, und der kürzeste häufige Timeout liegt bei rund 30 Sekunden. Ein Keepalive alle 25 Sekunden hält das Mapping mit einem kleinen Sicherheitspuffer vor dieser 30-Sekunden-Grenze frisch. Niedrigere Werte funktionieren auch, verschwenden aber etwas Bandbreite und Akku; 25 ist der dokumentierte Idealwert. Ist dein konkretes NAT aggressiver, kann ein Absenken auf 15 helfen.

Gehört PersistentKeepalive auf den Client oder den Server?

Setze es auf den Peer, der durch ein NAT erreichbar bleiben muss - fast immer der mobile Client (dein Laptop, Handy oder die Heimbox hinter einem Router). Der Client fügt PersistentKeepalive = 25 in den [Peer]-Block ein, der den Server beschreibt. Ein Server mit echter öffentlicher IP braucht kein Keepalive zu seinen Clients hin, weil der Client immer initiiert und der Server einfach dorthin antwortet, wo das letzte Paket herkam. Sind beide Enden hinter NAT, setze es auf beiden.

Warum bekomme ich 'interval must be in range 0 to 65535'?

PersistentKeepalive nimmt eine ganze Zahl von Sekunden entgegen, und WireGuard prüft sie gegen den Bereich 0 bis 65535. Der Fehler 'interval must be in range' oder 'must be in range 0 to 65535' bedeutet, dass du etwas außerhalb davon übergeben hast - eine negative Zahl, eine Dezimalzahl, ein Einheitensuffix wie '25s' oder ein Fremdzeichen. Nutze eine schlichte Ganzzahl: PersistentKeepalive = 25. Ein Wert von 0 (oder die Zeile wegzulassen) deaktiviert die Funktion vollständig.

Leert PersistentKeepalive meinen Akku oder mein Datenvolumen?

Bandbreitentechnisch ist es vernachlässigbar: Ein Keepalive ist ein kleines leeres Paket von rund 32 Byte, alle 25 Sekunden gesendet, ein paar Kilobyte pro Stunde. Der echte Preis fällt auf Mobilgeräten an, wo jedes Keepalive das Funkmodul aus dem Stromsparschlaf weckt, und häufige Weckvorgänge können die Akkulaufzeit verkürzen. Deshalb erhöhen manche das Intervall auf dem Handy, um Energie zu sparen, und nehmen in Kauf, dass der Tunnel im Leerlauf kurz unerreichbar wird. Auf einem stets eingeschalteten Desktop oder Server sind die Kosten praktisch null.