VPNSmith
self-host-vpnINFO

WireGuard PersistentKeepalive : garder le tunnel joignable derrière un NAT (2026)

Votre pair WireGuard devient muet après une minute derrière un NAT ? Mettez PersistentKeepalive = 25 côté client. Ce que fait l'option, pourquoi 25 s, et où la placer.

Par Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR7 min de lecturePhoto via Unsplash

Transparence affiliation — Cet article contient des liens affiliés Contabo. Si vous prenez un VPS via eux, nous touchons une commission sans surcoût pour vous. Chaque valeur et comportement ci-dessous est documenté à partir des sources officielles WireGuard et écrit pour être reproductible sur votre machine.

Votre client WireGuard se connecte, marche une minute, puis se tait : vous joignez le serveur depuis le client, mais le serveur ne peut plus rien vous renvoyer. Un SSH depuis le serveur gèle, un appareil du LAN derrière le client devient injoignable, le handshake périme en silence. Le correctif est presque toujours une ligne côté client : PersistentKeepalive = 25. Ce guide explique exactement ce que fait cette option, pourquoi 25 secondes est le bon chiffre, et de quel côté du tunnel elle doit se trouver.

La réponse courte

Si un pair est derrière un NAT et doit rester joignable, ajoutez ceci au bloc [Peer] de la config de ce pair :

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

Redémarrez le tunnel et le problème du tunnel muet après inactivité disparaît. Tout ce qui suit explique le pourquoi.

Ce que fait PersistentKeepalive

Par conception, WireGuard est silencieux : quand il n'y a rien à envoyer, il n'envoie rien. Pas de keepalive, pas de battement, pas de bavardage. C'est efficace et difficile à empreinter — mais cela casse un scénario précis.

Quand un client est derrière un NAT (routeur domestique, opérateur mobile, pare-feu de bureau), le boîtier NAT crée un mapping temporaire la première fois que le client émet un paquet. C'est ce mapping qui permet au serveur de renvoyer ses réponses vers la bonne adresse interne — voyez-le comme un trou percé dans le NAT. Surtout, ce trou expire après une période d'inactivité, souvent entre 30 secondes et quelques minutes pour l'UDP. Une fois fermé, les paquets du serveur n'ont plus de destination, et le pair devient injoignable jusqu'à ce que le client reparle.

PersistentKeepalive règle cela en envoyant un petit paquet keepalive vide vers le pair toutes les N secondes. Ce minuscule trafic garde le mapping NAT rafraîchi, donc le trou ne se ferme jamais et le pair reste joignable même au repos.

Câblage et équipements réseau dans une baie de datacenter — le côté IP publique d'un tunnel WireGuard auto-hébergé
Câblage et équipements réseau dans une baie de datacenter — le côté IP publique d'un tunnel WireGuard auto-hébergé

Pourquoi 25 secondes

La recommandation officielle de WireGuard est de 25 secondes, et le raisonnement est simple. Les timeouts NAT UDP courants se situent entre 30 secondes et quelques minutes, et la valeur la plus courte que l'on rencontre régulièrement avoisine 30 secondes. Envoyer un keepalive toutes les 25 secondes rafraîchit le mapping avec une petite marge avant ce plancher de 30 secondes — assez fréquent pour ne jamais laisser le trou se fermer, assez rare pour ne presque rien coûter.

Vous pouvez descendre plus bas si votre NAT est anormalement agressif (15 est l'étape suivante raisonnable), ou monter pour économiser la batterie sur mobile, mais 25 est la valeur documentée par défaut, et ce n'est pas un hasard. N'en faites pas trop.

Où la mettre : client ou serveur

C'est là que les gens se trompent. Le keepalive va sur le pair qui doit rester joignable à travers un NAT :

ConfigurationKeepalive côté client ?Keepalive côté serveur ?
Client nomade derrière NAT → serveur à IP publiqueOui (= 25)Non
Serveur à IP publique propre(sans objet)Inutile
Les deux bouts derrière un NAT (pair-à-pair)OuiOui

Dans le cas normal — un portable ou un téléphone derrière un routeur qui parle à un VPS à IP publique réelle — seul le client a besoin de PersistentKeepalive = 25, dans le bloc [Peer] qui décrit le serveur. Le serveur n'en a pas besoin vers ses clients : le client initie toujours, et le serveur répond simplement vers l'adresse source du dernier paquet reçu. Un serveur à IP publique propre, c'est exactement la configuration où vous évitez tout problème NAT côté serveur.

Exemple de config [Peer]

Voici un bloc pair complet côté client avec le keepalive en place :

[Interface]
PrivateKey = <cle-privee-client>
Address = 10.66.66.2/32
DNS = 10.66.66.1

[Peer]
PublicKey = <cle-publique-serveur>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Appliquez-le avec un redémarrage du tunnel :

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

Vérifiez que c'est pris en compte — wg show liste l'intervalle sous le pair :

sudo wg show
# persistent keepalive: every 25 seconds

Si vous assemblez des configs de zéro, les modèles de configuration WireGuard prêts à l'emploi incluent déjà la ligne keepalive dans le bon bloc pour chaque plateforme.

L'erreur « interval must be in range »

PersistentKeepalive attend un simple nombre entier de secondes, validé contre la plage 0 à 65535. Si vous voyez interval must be in range ou must be in range 0 to 65535, vous avez passé quelque chose qui n'est pas un entier valide dans cette fenêtre :

  • Un suffixe d'unité — écrivez 25, pas 25s.
  • Une décimale — 25, pas 25.0.
  • Un nombre négatif, ou une valeur au-dessus de 65535.
  • Une espace parasite ou un caractère invisible collé depuis une page web.

La valeur 0 est légale et signifie désactivé — comme l'absence totale de la ligne. Donc PersistentKeepalive = 0 ne sert à rien ; utilisez un vrai intervalle comme 25.

Keepalive réglé mais toujours pas fonctionnel

Si vous avez ajouté la ligne et que le tunnel se tait toujours après inactivité, passez en revue ces causes honnêtes dans l'ordre :

  • Réglé du mauvais côté. C'est le pair derrière le NAT qui en a besoin. Un keepalive sur le seul serveur à IP publique ne garde pas ouvert le trou NAT d'un client.
  • Timeout NAT plus court que votre intervalle. Certains CGNAT ferment les mappings UDP plus vite que 30 secondes. Descendez l'intervalle à 15 et re-testez.
  • Un pare-feu bloque le chemin. Si le port UDP sous-jacent est filtré, aucun keepalive ne passera — confirmez que le port WireGuard est bien ouvert des deux côtés.
  • L'endpoint a changé (roaming). Si le client a changé de réseau et d'adresse publique, le serveur peut encore viser l'ancien Endpoint. Le keepalive aide le serveur à suivre la nouvelle source, mais un Endpoint périmé côté client peut quand même échouer.

Keepalive vs handshake WireGuard

Ce sont deux minuteries différentes, et il vaut mieux les distinguer. WireGuard renouvelle son handshake cryptographique environ toutes les deux minutes — mais seulement quand il y a du trafic réel à protéger. Sur un lien inactif sans keepalive, pas de trafic signifie pas de renouvellement de handshake, et pendant ce temps le trou NAT se referme tranquillement.

PersistentKeepalive comble exactement ce vide : il maintient un filet de trafic sur un lien sinon inactif, gardant le mapping NAT ouvert entre les handshakes pour que le tunnel soit prêt dès qu'une vraie donnée doit circuler. Le keepalive ne remplace pas le handshake ; il garde le chemin vivant pour que le handshake puisse se faire au besoin.

Un serveur à IP publique supprime la moitié du problème

La plupart des soucis de keepalive viennent d'un NAT côté serveur — un boîtier VPN derrière un routeur domestique, du double NAT, un pare-feu fournisseur. Mettez le serveur sur une IPv4 publique propre et le seul NAT restant est celui du client, où un unique PersistentKeepalive = 25 suffit. Un Contabo Cloud VPS 10 à 5,50 €/mois vous donne un root complet et une vraie IP publique sans pare-feu fournisseur à combattre — exactement les conditions où le keepalive côté client est la seule chose à régler. Pour comprendre la mécanique NAT que cette option contourne, voyez l'explication simple de ce qu'est le NAT.

Pour aller plus loin

Sources et références :

Publié le 2026-06-29. La recommandation de 25 secondes et le comportement de PersistentKeepalive proviennent de la documentation officielle WireGuard ; les plages de timeout NAT varient selon l'appareil, alors confirmez auprès de votre routeur ou opérateur si un intervalle plus court est nécessaire.

Rappel : faire tourner WireGuard et auto-héberger un VPN est légal dans l'UE, aux États-Unis, au Canada et dans la plupart des pays démocratiques. VPNSmith publie ce contenu à des fins éducatives.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

Que fait PersistentKeepalive dans WireGuard ?
PersistentKeepalive est une option de la section [Peer] d'une config WireGuard qui fait envoyer à l'interface un petit paquet keepalive vide vers ce pair toutes les N secondes, même sans trafic réel. Par défaut WireGuard est silencieux : il n'envoie rien sur un lien inactif. Ce silence pose problème quand un client est derrière un NAT, car le mapping NAT — le trou qui permet au serveur de réémettre vers le client — expire après une courte période d'inactivité. Le keepalive périodique garde ce mapping ouvert, donc le pair reste joignable. On l'active avec une ligne : PersistentKeepalive = 25.
Pourquoi la valeur recommandée de PersistentKeepalive est-elle 25 secondes ?
La recommandation officielle de WireGuard est de 25 secondes. Les mappings NAT UDP des routeurs domestiques et du CGNAT expirent généralement entre 30 secondes et quelques minutes, et le délai le plus court couramment rencontré tourne autour de 30 secondes. Envoyer un keepalive toutes les 25 secondes rafraîchit le mapping avec une petite marge avant ce plancher de 30 secondes. Des valeurs plus basses marchent aussi mais gaspillent un peu de bande passante et de batterie ; 25 est le point d'équilibre documenté. Si votre NAT est plus agressif, descendre à 15 peut aider.
Faut-il mettre PersistentKeepalive côté client ou serveur ?
Mettez-le sur le pair qui doit rester joignable à travers un NAT — presque toujours le client nomade (votre portable, téléphone ou box derrière un routeur). Le client ajoute PersistentKeepalive = 25 dans le bloc [Peer] qui décrit le serveur. Un serveur à IP publique réelle n'a pas besoin de keepalive vers ses clients, car le client initie toujours et le serveur répond simplement vers l'adresse d'où venait le dernier paquet. Si les deux extrémités sont derrière un NAT, mettez-le des deux côtés.
Pourquoi ai-je l'erreur « interval must be in range 0 to 65535 » ?
PersistentKeepalive prend un nombre entier de secondes, et WireGuard le valide contre la plage 0 à 65535. L'erreur « interval must be in range » ou « must be in range 0 to 65535 » signifie que vous avez passé quelque chose hors de cette plage — un nombre négatif, une décimale, un suffixe d'unité comme « 25s », ou un caractère parasite. Utilisez un entier nu : PersistentKeepalive = 25. La valeur 0 (ou l'absence de la ligne) désactive complètement la fonction.
PersistentKeepalive vide-t-il ma batterie ou mes données ?
Côté bande passante c'est négligeable : un keepalive est un petit paquet vide d'environ 32 octets envoyé toutes les 25 secondes, quelques kilooctets par heure. Le vrai coût est sur mobile, où chaque keepalive réveille la radio de sa veille basse consommation, et des réveils fréquents peuvent réduire l'autonomie. C'est pourquoi certains montent l'intervalle sur téléphone pour économiser de l'énergie, acceptant que le tunnel soit brièvement injoignable au repos. Sur un poste ou serveur toujours allumé, le coût est quasi nul.
Articles liés

Pour aller plus loin