WireGuard « Handshake did not complete after 5 seconds » : 8 causes

Tu tapes wg show, tu vois ton pair, et juste en dessous se trouve la ligne qui gâche ta soirée : latest handshake est vide, ou wg-quick t'avertit handshake did not complete. Ton tunnel est monté sur le papier mais aucun trafic ne passe. La bonne nouvelle : WireGuard échoue pour une liste courte et finie de raisons, et elles arrivent dans un ordre prévisible. Ce guide déroule cet ordre du plus fréquent au plus rare, pour arrêter de deviner et corriger en quelques minutes.

WireGuard est silencieux par conception - il n'envoie rien tant qu'il n'y a pas de données à transporter, et ne logue jamais un gentil « connection refused ». Ce silence rend un handshake raté mystérieux. Presque toujours c'est un problème de joignabilité réseau (pare-feu, port, NAT, routage), pas de cryptographie. Déroule la liste de haut en bas et tu l'attraperas.

Pressé ? Deux causes couvrent la plupart des handshakes ratés : un port UDP qui n'atteint jamais le serveur (pare-feu fermé, redirection absente, ou CGNAT sur votre box), puis, une fois le tunnel monté, un MTU trop élevé. Le vérificateur de port WireGuard vous dit si vous êtes derrière un CGNAT et écrit les règles de redirection et de pare-feu pour votre système ; le calculateur MTU donne la valeur à poser une fois le handshake établi.

Tu ne sais pas lequel des deux ? Notre vérificateur de port WireGuard gratuit compare l'adresse WAN de ta box à ton IP publique : il te dit en moins d'une minute si tu es derrière un CGNAT (aucune redirection ne marchera) ou si une redirection et une règle de pare-feu suffisent.

Derrière un CGNAT ? Aucune redirection de port ni règle de pare-feu de ton côté ne peut ouvrir un chemin vers un serveur à la maison. La sortie habituelle consiste à faire tourner le serveur WireGuard sur un VPS doté de sa propre IPv4 publique, comme un VPS Cloud Contabo (lien affilié), dès 5,50 € par mois sur 24 mois (tarif relevé le 17 octobre 2026). Si vous préférez un hébergeur américain avec 30 jours satisfait ou remboursé, le VPS Basic d'Ultahost coûte 5,52 $ par mois sur 24 mois (1 Go de RAM, IPv4 dédiée, relevé le 21 octobre 2026), assez pour un serveur WireGuard de quelques appareils. Hébergeur pas encore choisi ? Comparatifs : meilleur VPS pour un VPN et Contabo vs Hetzner vs OVH, au prix réellement facturé. Autre option : HostPapa Unmanaged VPS Lite (lien affilié) à 2,95 $ par mois sur un engagement de 3 ans, puis au tarif normal (1 cœur, 1 Go de RAM, 25 Go NVMe, accès root SSH, satisfait ou remboursé 30 jours, relevé le 28 octobre 2026).

Tu n'as pas encore choisi le serveur ? Notre classement des VPS les moins chers pour WireGuard compare ce que chaque hébergeur facture vraiment pour un serveur utilisable.

La ligne de log exacte : "Handshake for peer 1 did not complete after 5 seconds"

Si tu as cherché l'erreur mot pour mot, c'est ce message que tu as sous les yeux. Le module noyau Linux l'affiche (une fois les logs de debug activés), et wireguard-go, l'implémentation en espace utilisateur derrière les applis Windows, macOS et Android, affiche une version quasi identique :

wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 5 seconds, retrying (try 2)
wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 20 attempts, giving up

Comment la lire :

• "after 5 seconds" n'est pas un réglage que tu peux modifier. C'est le délai de nouvelle tentative fixe de WireGuard (REKEY_TIMEOUT, 5 s dans le code source). Ton pair a envoyé une initiation de handshake et n'a reçu aucune réponse valide dans ce délai.
• "retrying (try 2)" signifie qu'il essaie encore. WireGuard continue de renvoyer pendant environ 90 secondes au total.
• "did not complete after 20 attempts, giving up" marque la fin de cette boucle. Le pair se tait jusqu'à ce que du nouveau trafic tente de traverser le tunnel, ce qui relance un nouveau cycle.
• Failed to send handshake initiation: no known endpoint for peer est un cas différent : ce côté n'a pas d'Endpoint = pour le pair, donc il ne peut pas initier du tout et peut seulement attendre d'être contacté. Normal sur un serveur, une erreur de config sur un client.

Sous Linux, le module noyau ne logue rien par défaut. Pour voir ces lignes :

echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo dmesg -w | grep wireguard

Le message ne prouve qu'une chose : l'initiation est partie et rien de valide n'est revenu. Il ne dit pas pourquoi. Les causes ci-dessous, dans l'ordre, sont le pourquoi.

D'abord, lis l'état réel avec wg show

Avant de changer quoi que ce soit, regarde ce que WireGuard te dit déjà. Des deux côtés :

sudo wg show

Tu lis trois choses :

• latest handshake - vide ou plus vieux que ~2 minutes = tunnel tombé. Sain = dans les 120 dernières secondes.
• transfer - 0 B received veut dire que tes paquets ne sont jamais revenus. Envoyé-mais-rien-reçu est la signature d'un pare-feu ou NAT à sens unique.
• endpoint - côté serveur, il doit montrer l'IP:port publique actuelle du client dès qu'un paquet arrive. S'il ne se remplit jamais, l'initiation du client ne t'a pas atteint.

Garde ce terminal ouvert. Après chaque fix ci-dessous, relance wg show et surveille la ligne latest handshake. C'est ta seule source de vérité - pas l'icône de connexion, pas l'appli.

wg show latest-handshakes - la forme lisible par une machine

wg show seul affiche un latest handshake: 1 minute, 12 seconds ago fait pour l'œil humain. Pratique à lire, inutilisable en script. Le manuel wg(8) permet d'ajouter un attribut pour restreindre la sortie :

show { <interface> | all | interfaces } [public-key | private-key | listen-port |
      fwmark | peers | preshared-keys | endpoints | allowed-ips |
      latest-handshakes | persistent-keepalive | transfer | dump]

La forme de référence est donc :

sudo wg show wg0 latest-handshakes

Elle affiche une ligne par pair : la clé publique en base64 du pair, une tabulation, puis la date du dernier handshake en secondes depuis l'epoch Unix. C'est littéralement ce que fait l'outil : dans wireguard-tools, src/show.c contient printf("%s\t%llu\n", key(peer->public_key), peer->last_handshake_time.tv_sec); :

xTIBd0Kx3Hs9tPmVvQ4ZlLxYcE8nRr2A6WKsPqUvT1s=	1750684173
9QzrN7bLyF0mXaHcJdSoEuIgYkTvW3pB5nRfZ1AhQ0M=	0

Deux choses à savoir sur ce nombre :

• 0 signifie que ce pair n'a jamais complété de handshake depuis la montée de l'interface. Pas un horodatage périmé : un horodatage absent. C'est exactement l'état que tu débogues sur cette page.
• C'est un temps epoch absolu, pas un âge. Soustrais-le de date +%s pour obtenir les secondes écoulées depuis le dernier handshake :

now=$(date +%s)
sudo wg show wg0 latest-handshakes | while read -r peer ts; do
  if [ "$ts" -eq 0 ]; then
    echo "$peer jamais"
  else
    echo "$peer $((now - ts))s"
  fi
done

Deux détails qui piègent quand on scripte. wg show all latest-handshakes préfixe le nom de l'interface en première colonne séparée par une tabulation : ton read a besoin d'une troisième variable. Et wg show wg0 dump donne le même horodatage à côté de l'endpoint, des allowed-ips et des compteurs de transfert, en une ligne par pair séparée par des tabulations : c'est la forme à parser pour un vrai moniteur plutôt qu'un one-liner.

Au-delà de ~180 secondes sur un pair censé être actif, le tunnel est tombé. C'est le seuil sur lequel alerter, et le reste de cette page est la liste ordonnée des raisons de la chute.

Cause 1 - Le port UDP est bloqué (le coupable n°1)

WireGuard parle UDP sur un seul port - 51820 par défaut. Si ce port est filtré quelque part sur le chemin, le paquet d'initiation meurt et tu obtiens exactement ton symptôme. Pour comprendre ce défaut, comment le changer et l'ouvrir correctement, vois quel port WireGuard utilise et comment l'ouvrir. Il y a en général deux pare-feu à vérifier, et on oublie souvent le premier :

Pare-feu du fournisseur cloud (le plus souvent oublié). Contabo, Hetzner, OVH, AWS - tous ont un pare-feu réseau ou un groupe de sécurité devant ton VPS. Une règle autorisant UDP 51820 depuis n'importe où doit exister là, séparée du pare-feu système. Sur la plupart des images de VPS Contabo il n'y a pas de pare-feu fournisseur par défaut (tant mieux), mais si tu en as activé un, ajoute la règle UDP.

Pare-feu système sur le serveur. Vérifie et autorise :

# 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

Preuve rapide que le port est joignable de l'extérieur - depuis ta machine client :

# envoie une sonde UDP ; "open|filtered" sans réponse est non concluant,
# mais "open" ou un paquet renvoyé confirme la joignabilité
nc -u -z -v IP_DE_TON_SERVEUR 51820

Test plus propre : lance sudo tcpdump -n -i eth0 udp port 51820 sur le serveur, puis connecte-toi depuis le client. Si tu vois des paquets entrants, le port est ouvert et tu passes à la cause suivante. Si tu ne vois rien, le paquet est jeté avant d'atteindre WireGuard - reste sur cette cause.

Rien n'arrive et le serveur tourne chez toi ? Vérifie le CGNAT

Si le « serveur » est un Raspberry Pi, un NAS ou un PC sur ta connexion à la maison, un tcpdump vide n'a souvent rien à voir avec ton pare-feu. Beaucoup de FAI (la plupart des box 4G/5G, un nombre croissant d'offres fibre) placent leurs clients derrière un CGNAT : ta box partage une seule IPv4 publique avec d'autres abonnés, donc aucune redirection de port ne pourra jamais amener un paquet UDP entrant jusqu'à ta machine. Compare l'adresse WAN affichée par ta box avec ce que renvoie curl -4 ifconfig.me. Si elles diffèrent, ou si la box affiche une adresse en 100.64.0.0/10, tu es derrière un CGNAT et le handshake ne peut pas aboutir avec cette config.

Trois sorties possibles : demander une IPv4 publique à ton FAI (certains la donnent gratuitement, d'autres la facturent, beaucoup refusent), passer en IPv6 de bout en bout si les deux côtés l'ont, ou installer le serveur WireGuard sur un petit VPS doté de sa propre IPv4 publique et, si tu dois encore joindre la machine de la maison, la relier au VPS comme client. Le guide CGNAT détaille le tunnel inversé, et notre générateur de config WireGuard gratuit écrit les fichiers serveur et client avec des clés qui correspondent.

Vous ne savez pas si une redirection de port peut fonctionner sur votre connexion ? Notre vérificateur de port WireGuard gratuit compare l'adresse WAN de votre box à votre IP publique, détecte le CGNAT, écrit les règles de redirection et de pare-feu de votre installation et donne le test tcpdump qui prouve que les paquets arrivent au serveur.

Ça marche chez vous, pas sur le Wi-Fi d'un hôtel, d'un bureau ou d'un campus ?

Le serveur n'y est alors pour rien : le réseau sur lequel vous êtes bloque l'UDP, ou reconnaît WireGuard et le coupe. Le test tcpdump ci-dessus ne montre rien seulement quand vous êtes sur ce réseau. Si le serveur est à vous, passez ListenPort (et l'Endpoint du client) en UDP 443, le port déjà utilisé par HTTP/3, qui franchit la plupart des filtres par port ; notre guide du port WireGuard détaille le changement. Si vous voulez juste un VPN qui fonctionne sur ce réseau sans gérer de serveur, une application VPN avec un mode d'obfuscation emballe le tunnel pour vous : Proton VPN propose Stealth, sur toutes les offres y compris la gratuite, et NordVPN propose NordWhisper, qui fait ressembler le trafic VPN à du trafic web ordinaire (liens affiliés). Face à l'inspection profonde de paquets, voir le guide anti-DPI.

Offre payante, Black Friday 2026 : l'offre partenaire de Proton, relevée le 28 octobre 2026, est VPN Plus à 2,49 $/mois sur 2 ans (59,76 $ pour les 24 premiers mois, puis 83,88 $ par an), avec 30 jours satisfait ou remboursé et 10 appareils. La page de commande affiche le prix de votre pays, et Proton n'annonce pas de date de fin.

Cause 2 - Mauvais Endpoint côté client

Le bloc [Peer] du client a besoin de la vraie IP publique du serveur (ou son nom DNS) et du ListenPort exact :

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

Erreurs fréquentes qui produisent un handshake mort :

• L'Endpoint pointe sur l'IP LAN privée du serveur (10.x / 192.168.x) au lieu de la publique.
• Une faute de frappe dans le port, ou le serveur écoute en réalité sur un autre ListenPort.
• L'IP publique du serveur a changé (certaines réinstallations de VPS la réattribuent). Confirme avec curl -4 ifconfig.co sur le serveur, puis compare à l'Endpoint du client.

Le bloc pair côté serveur n'a pas de ligne Endpoint (le serveur l'apprend quand le paquet du client arrive) - en ajouter une là est une erreur de copier-coller fréquente.

Cause 3 - Des AllowedIPs erronés

AllowedIPs est une table de routage cryptographique, pas une liste de permissions, et une erreur casse en silence le trafic retour :

• Côté serveur, le AllowedIPs du pair doit lister uniquement l'adresse tunnel de ce client, ex. 10.66.66.2/32. Si deux pairs partagent une plage qui se chevauche, le serveur envoie les réponses au mauvais et le handshake « se complète » puis meurt.
• Côté client, AllowedIPs = 0.0.0.0/0 route tout dans le tunnel (VPN complet). Pour du split tunneling, liste seulement les sous-réseaux que tu routes vraiment - voir notre guide de routage en split-tunnel.

Un handshake qui réussit brièvement puis cale est la signature classique d'AllowedIPs côté serveur qui se chevauchent. Rends la plage de chaque pair unique.

Besoin d'exclure votre réseau local ou une seule adresse d'un tunnel complet ? AllowedIPs n'a pas de syntaxe « sauf », donc notre calculateur AllowedIPs gratuit transforme « tout sauf X » en liste minimale de plages IPv4 et IPv6 à coller.

Cause 4 - Timeout NAT (marche 2 minutes puis meurt)

Si ton client est derrière du NAT (box maison, 4G/5G, Wi-Fi d'hôtel) et que le lien devient inactif, le routeur supprime le mapping UDP. Le serveur n'a plus de chemin de retour vers le client et le handshake expire en silence. Le fix vit sur le pair situé derrière le NAT :

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

PersistentKeepalive = 25 envoie un petit paquet toutes les 25 secondes, gardant le mapping NAT ouvert. Vingt-cinq secondes est sous tout timeout NAT courant. Ajoute-le sur les clients nomades et sur tout pair derrière un routeur restrictif. Le pair côté serveur n'en a en général pas besoin.

Cause 5 - Le forwarding IP est coupé sur le serveur

Si le handshake se complète mais que tu n'atteins pas Internet via le tunnel, le serveur ne fait pas suivre les paquets entre l'interface WireGuard et eth0. Active-le :

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

Confirme : sysctl net.ipv4.ip_forward doit renvoyer 1. Associe-le à la règle de masquerade dans ton PostUp (les templates de config prêts à l'emploi embarquent ces lignes correctement) :

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

Cause 6 - Décalage d'horloge

Le handshake de WireGuard utilise des horodatages pour bloquer les attaques par rejeu. Si l'horloge du serveur dévie de plus de quelques minutes - fréquent sur les images de VPS fraîches ou les VM mises en pause - les handshakes sont rejetés comme périmés. Corrige l'horloge :

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

Celle-ci est sournoise car tout le reste a l'air parfait. Si tu as triple-vérifié le port, les clés et le routage et que tu n'as toujours rien, vérifie l'horloge avant de désespérer.

Cause 7 - Clés non concordantes (à vérifier en dernier)

On se rue d'abord sur les clés ; vérifie-les en dernier, car une erreur de clé est plus rare que les six causes précédentes et produit le même symptôme. La règle est simple :

• La [Peer] PublicKey du serveur = la clé publique dérivée de la PrivateKey du client.
• La [Peer] PublicKey du client = la clé publique dérivée de la PrivateKey du serveur.

Régénère et re-dérive pour être sûr :

# sur chaque machine, dérive la clé publique de sa propre clé privée
echo "CLE_PRIVEE_DE_CET_HOTE" | wg pubkey

Compare cette sortie à la PublicKey que l'autre côté a pour toi. Une seule clé inversée ou tronquée casse complètement le handshake. Au passage, une PresharedKey (si utilisée) doit être identique sur les deux pairs - une différence là tue aussi le handshake. Ce que protège vraiment la clé pré-partagée, et comment l'ajouter sans couper un tunnel actif : guide de la clé pré-partagée WireGuard.

Pour écarter les clés d'un coup, notre générateur de config WireGuard gratuit crée dans le navigateur une paire de clés neuve pour chaque côté et place chaque clé publique dans le bloc [Peer] de l'autre, avec une PresharedKey identique des deux côtés.

Cause 8 - Le MTU casse le tunnel juste après le handshake

À proprement parler, le MTU bloque rarement le handshake (ses paquets sont petits). Mais il casse souvent les choses dès que le vrai trafic passe : le handshake se complète, le ping marche, puis les pages web restent bloquées pour toujours. C'est de la fragmentation. Baisse le MTU client :

[Interface]
MTU = 1380

Trouve la bonne valeur avec un ping « do-not-fragment » vers l'IP tunnel du serveur, en réduisant jusqu'à ce que ça passe :

ping -M do -s 1372 10.66.66.1

1420 convient à la plupart des liens fibre ; 1380 est un défaut sûr ; PPPoE et certains opérateurs mobiles exigent 1280. Notre guide des templates de config explique le réglage du MTU par type de lien. Si le tunnel se connecte mais bloque sur les gros transferts, le guide dédié réparer le MTU WireGuard montre comment mesurer la valeur exacte avec un ping sans fragmentation et la régler par type de lien.

Pour obtenir la valeur au lieu de la deviner, le calculateur MTU WireGuard gratuit part de la plus grande charge utile passée par votre ping sans fragmentation (ou simplement de votre type de lien) et écrit la ligne MTU = de votre configuration.

L'ordre de diagnostic en 60 secondes

Quand un handshake échoue, déroule cette séquence exacte et arrête-toi à la première anomalie :

1. wg show des deux côtés - y a-t-il un latest handshake, des octets received ?
2. tcpdump udp port 51820 sur le serveur pendant que le client se connecte - des paquets arrivent-ils ?
3. Si aucun paquet n'arrive → pare-feu / port / Endpoint (causes 1-2).
4. Si des paquets arrivent mais aucune réponse ne revient → AllowedIPs côté serveur, NAT, route de retour (causes 3-4).
5. Si le handshake se complète mais pas d'Internet → ip_forward + masquerade (cause 5).
6. Si tout a l'air bon et toujours rien → décalage d'horloge, puis clés, puis MTU (causes 6-8).

Cet ordre suit le trajet du paquet, de l'accessibilité au routage puis aux causes moins évidentes - déroule-le de haut en bas et tu ne perdras pas de temps.

Envie de cet ordre sur une seule page imprimable ? La check-list de dépannage de notre WireGuard Self-Hosting Kit payant (9 USD, en anglais) l'étend à 12 causes, chacune avec la commande qui la confirme et le correctif, plus une table pour lire la sortie de tcpdump. Les étapes ci-dessus restent gratuites et complètes pour les 8 causes traitées ici.

Bien le construire dès le départ

La plupart des handshakes ratés viennent d'une config recousue à la main depuis trois tutoriels contradictoires. Partir d'une base saine sur un VPS propre supprime la plupart des surprises. Un Contabo Cloud VPS 4 à 5,50 €/mois te donne une IPv4 publique, du root complet, et aucun pare-feu fournisseur à combattre - exactement les conditions où WireGuard « marche tout seul ». Suis le setup Contabo + WireGuard pas-à-pas et colle une config vérifiée depuis le guide des templates, et tu pars de lignes dont on sait qu'elles vont ensemble.

Pour repartir de zéro des deux côtés, notre générateur de config WireGuard gratuit crée les clés dans le navigateur et écrit une config serveur et des configs clients qui concordent : clés publiques, AllowedIPs et Endpoint s'alignent du premier coup.

Un VPN change votre IP. Il ne change pas votre navigateur.

Un tunnel remplace l'adresse que voit un service. Il ne change rien à ce que votre navigateur annonce de lui-même - polices, écran, fuseau, pile graphique - et cette combinaison suffit souvent à vous reconnaître d'une session à l'autre, tunnel ou pas.

Mesurez votre empreinte de navigateur - mesure passive, aucune question, aucun compte, aucune adresse e-mail.

Pour aller plus loin

• PersistentKeepalive : ce que fait vraiment le réglage à 25 secondes
• WireGuard multihop : chaîner deux serveurs auto-hébergés
• WireGuard derrière un CGNAT : pourquoi le handshake n'arrive jamais
• WireGuard sous Windows : configuration pas à pas
• WireGuard sur iPhone et iPad : la configuration iOS complète
• Self-host VPN sur Contabo : guide complet WireGuard 2026
• Templates de configuration WireGuard prêts à l'emploi 2026
• Fuites DNS WireGuard : détecter, diagnostiquer, éliminer
• WireGuard kill-switch sous Linux : iptables + systemd
• VPN en split-tunnel avec tables de routage
• Glossaire VPN auto-hébergé - AllowedIPs, MTU, NAT expliqués
• PiVPN en 2026 : la façon la plus simple d'auto-héberger WireGuard ou OpenVPN

Sources et références :

• Whitepaper WireGuard - Jason A. Donenfeld
• Quickstart WireGuard et docs wg-quick
• Pages de manuel wg(8) et wg-quick(8)
• Arch Wiki - dépannage WireGuard

Publié le 2026-06-23. Commandes écrites pour des serveurs Debian 12 et Ubuntu 24.04 à partir de la documentation officielle de WireGuard ; nous n'avons pas de banc de test multi-clients. Tes conditions de lien peuvent différer - confirme toujours avec wg show et tcpdump avant de considérer un fix comme définitif.

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

Il vaut aussi la peine d'auditer l'endroit où vivent les clés : un avis CISA de juillet 2026 porte sur une faille RouterOS permettant de lire une clé privée WireGuard statique depuis le routeur. Voir pourquoi désactiver l'API n'annule rien.