WireGuard sur Windows ne se connecte pas : 10 correctifs qui résolvent la plupart des cas

Plan de diagnostic rapide (vérifier 1–2–3)

Quand WireGuard sur Windows « ne veut pas se connecter », cessez de le traiter comme un seul problème.
Il s’agit habituellement d’un des trois goulots d’étranglement : handshake, routage ou résolution de nom.
Identifiez lequel en moins de cinq minutes, puis creusez.

1) Y a‑t‑il un handshake ?

• Sur Windows : Interface WireGuard → choisir le tunnel → regarder « Dernier handshake ».
• Sur le serveur : vérifier wg show pour le « latest handshake » et les compteurs RX/TX.

Pas de handshake est généralement un problème de port/pare‑feu/NAT/clé.
Handshake présent mais trafic bloqué est généralement dû au routage, AllowedIPs, NAT/forwarding ou MTU.

2) Si le handshake existe : pouvez‑vous pinguer une IP (pas un nom) ?

• Pinguer l’IP de l’interface WireGuard du serveur (exemple : 10.6.0.1).
• Pinguer l’IP d’une ressource interne (exemple : 10.0.10.25).

Si le ping IP fonctionne mais pas les noms, c’est le DNS. Si aucun ping ne passe, c’est le routage/AllowedIPs/pare‑feu/MTU.

3) Si vous pouvez pinguer des IPs : la table de routage semble‑t‑elle cohérente ?

Sur Windows, de mauvaises routes causent une misère silencieuse : le trafic sort par votre Wi‑Fi, pas par le tunnel, pendant que le tunnel affiche fièrement « Connecté ».
Vérifiez les routes et les métriques d’interface avant de blâmer WireGuard.

Faits et contexte qui expliquent les comportements étranges

• WireGuard est uniquement UDP. Si votre réseau bloque l’UDP sortant ou le limite fortement, vous verrez des handshakes intermittents et une connectivité « fantôme ».
• Il n’y a pas de « session » à maintenir. WireGuard est plutôt sans état : il envoie des paquets chiffrés ; l’état est surtout le matériel de clés et des horodatages de handshake. Les appareils NAT, en revanche, aiment bien conserver de l’état.
• PersistentKeepalive existe surtout pour amadouer le NAT. Ce n’est pas une fonctionnalité de performance ; c’est une tactique de survie pour les clients derrière des pare‑feux stateful.
• AllowedIPs est une politique de routage. Ce n’est pas un ACL au sens traditionnel ; cela indique au pair quoi chiffrer et où router.
• Windows utilise des métriques d’interface pour choisir une route. Un « split tunnel » peut accidentellement devenir un « pas de tunnel » si une autre interface gagne la décision de routage.
• La conception de WireGuard est volontairement minimale. Moins de composants signifie moins de modes de défaillance — sauf si votre environnement apporte la complexité manquante via NAT, DNS et outils de sécurité d’entreprise.
• Les horodatages de handshake peuvent induire en erreur. Un handshake récent ne prouve pas que le chemin de retour fonctionne pour le trafic qui vous importe réellement (penser : routage asymétrique, ICMP bloqué, ou échecs seulement côté DNS).
• Les problèmes de MTU sont plus anciens que la plupart des fournisseurs VPN. Les trous noirs de PMTU existent depuis des décennies ; WireGuard les rend visibles quand vous encapsulez des paquets sur des réseaux fragiles.

Une idée « paraphrasée » qu’il vaut la peine d’avoir collée sur votre écran, attribuée à Werner Vogels (état d’esprit fiabilité) :
paraphrased idea: Everything fails, all the time; design and operate as if failure is normal.

Les 10 correctifs (la plupart des cas, sans drame)

Correctif 1 : Prouvez que le serveur écoute vraiment en UDP (et sur le port que vous pensez)

La moitié des rapports « WireGuard Windows ne se connecte pas » se résument à « le serveur n’écoute plus » ou il écoute sur la mauvaise interface.
Peut‑être que quelqu’un a changé le port. Peut‑être que le service n’a pas redémarré. Peut‑être qu’une règle de sécurité cloud a changé silencieusement.

Ce qu’il faut faire : sur le serveur, vérifier le port d’écoute et que des paquets arrivent.
Si le serveur ne voit jamais d’UDP entrant, arrêtez de bidouiller Windows. Le problème n’est pas là.

Correctif 2 : Confirmez que le tunnel WireGuard sur Windows utilise le point de terminaison attendu

Les utilisateurs Windows copient des configs, puis plus tard quelqu’un met à jour l’IP du serveur, ou le DNS change, ou le point de terminaison se résout différemment sur un réseau d’entreprise.
Si votre endpoint est un nom d’hôte, vous avez invité le DNS dans votre histoire de connectivité. Parfois c’est acceptable. Parfois c’est un appel de nuit.

Correctif 3 : Arrêtez de deviner — validez les clés et l’affectation des peers sur le serveur

WireGuard n’a pas d’authentification par nom d’utilisateur/mot de passe. Ce sont les clés qui gouvernent tout.
Un seul caractère erroné dans une clé publique, ou la réutilisation d’une config client sur plusieurs machines, peut provoquer un bazar « marche parfois » — en particulier quand deux clients partagent la même clé et se battent pour la même entrée de peer.

Correctif 4 : Corrigez AllowedIPs sur le client (la blessure auto‑infligée la plus courante)

AllowedIPs décide quel trafic passe dans le tunnel. Si votre AllowedIPs n’inclut pas la destination que vous essayez d’atteindre, WireGuard se comportera parfaitement pendant que vous expérimentez l’échec parfaitement.

• Tunnel complet : AllowedIPs = 0.0.0.0/0, ::/0
• Split tunnel : n’incluez que les préfixes internes, plus l’IP WG du serveur si nécessaire.

Si votre objectif est « atteindre les sous‑réseaux internes mais garder Internet local », faites un split tunnel délibéré.
Ne faites pas un demi‑tunnel complet et ne vous demandez pas pourquoi les appels Teams deviennent étranges.

Correctif 5 : Corrigez les conflits de routage et les métriques d’interface sur Windows

La sélection de route sur Windows est déterministe, pas forcément utile. Elle choisit la « meilleure » route selon la longueur du préfixe, la métrique et le coût d’interface.
Si vous avez plusieurs VPN, adaptateurs virtuels ou logiciels de sécurité, vous pouvez vous retrouver avec une table de routage qui ressemble à un organigramme d’entreprise : compliquée et parfois imaginaire.

Votre tâche : assurer que l’interface WireGuard a des routes pour les destinations dont vous avez besoin, et qu’aucune autre interface ne les lui vole.

Correctif 6 : Corrigez le DNS (parce que « le VPN est en panne » est souvent « le DNS est en panne »)

Les gens blâment WireGuard quand ping 10.0.0.10 fonctionne mais ping internal-app ne fonctionne pas.
C’est le DNS. Corrigez le DNS d’abord ; c’est moins cher que la panique existentielle.

Si vous poussez des serveurs DNS internes via la configuration WireGuard, assurez‑vous que :
(1) ces serveurs DNS sont atteignables par le tunnel, et
(2) Windows les utilise effectivement sur cette interface.

Correctif 7 : Corrigez le NAT et le forwarding sur le serveur (handshake sans trafic)

Un handshake prouve que le client et le serveur peuvent échanger du trafic de contrôle chiffré.
Il ne prouve pas que le serveur peut transférer les paquets du tunnel vers le LAN ou Internet.

Pour un tunnel complet, le serveur a généralement besoin d’IP forwarding et de NAT (masquerade) sur l’interface de sortie.
Pour un split tunnel vers un LAN interne, vous pourriez avoir besoin de routes sur la passerelle du LAN pour revenir vers le sous‑réseau WireGuard.

Correctif 8 : Corrigez le MTU (le classique « ça se connecte mais tout finit par expirer »)

Les problèmes de MTU se manifestent ainsi : handshake présent, petits pings fonctionnent, sites web bloquent, RDP/SMB patinent, ou seules certaines applications fonctionnent.
L’encapsulation UDP change la taille des paquets. Certains réseaux laissent tomber les fragments ou bloquent les ICMP « fragmentation needed ».
Vous avez un trou noir de PMTU. Joie.

Correctif 9 : Corrigez le pare‑feu Windows et les outils de sécurité qui « inspectent » votre VPN

Windows Defender Firewall peut bloquer l’adaptateur, et les outils endpoint d’entreprise peuvent bloquer ou « optimiser » l’UDP.
Si vous êtes sur un portable géré, supposez que vous n’êtes pas le seul à avoir un avis sur le trafic réseau.

Correctif 10 : Corrigez le décalage horaire et les primitives réseau cassées

WireGuard n’est pas TLS, mais le temps compte encore dans l’écosystème autour : DNS, validation de certificats pour les applications à l’intérieur du tunnel, et corrélation des logs.
De plus, si la pile réseau Windows est dans un état étrange (routes obsolètes, catalogue winsock cassé, adaptateurs virtuels à moitié installés), WireGuard sera accusé de crimes qu’il n’a pas commis.

Blague n°1 : Un indicateur « VPN connecté » est comme la lumière d’un lave‑vaisselle — il vous dit que la machine a des sentiments, pas que la vaisselle est propre.

Tâches pratiques avec commandes (et comment décider)

Ce sont des tâches que j’exécute réellement pendant des incidents. Chacune inclut une commande, ce que signifie la sortie, et la décision à prendre.
Les commandes sont montrées avec une invite de serveur Linux parce que la plupart des serveurs WireGuard sont sous Linux ; pour la validation client Windows nous utilisons l’interface graphique plus la vérité côté serveur.

Tâche 1 : Sur le serveur, confirmer que WireGuard est actif et écoute

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 2y...serverpub...
  private key: (hidden)
  listening port: 51820

peer: 9Z...clientpub...
  endpoint: 203.0.113.55:61644
  allowed ips: 10.6.0.2/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 18.42 MiB received, 31.10 MiB sent

Sens : Si vous voyez un port d’écoute et un handshake récent, WireGuard est vivant.
Si le « listening port » est absent, l’interface peut être down ou mal configurée.

Décision : Pas de handshake et aucun endpoint vu ? Concentrez‑vous sur la portée UDP (pare‑feu/NAT/port). Handshake présent mais transfert bloqué ? Passez au routage/NAT/MTU.

Tâche 2 : Vérifier l’état du service et de l’interface

cr0x@server:~$ sudo systemctl status wg-quick@wg0
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled)
     Active: active (exited) since Sat 2025-12-27 09:11:04 UTC; 2h 13min ago
       Docs: man:wg-quick(8)
             man:wg(8)
    Process: 1234 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)

Sens : Active (exited) est normal pour wg-quick ; il configure puis sort.

Décision : S’il est en failed, corrigez la configuration serveur avant de toucher à Windows. S’il est actif, continuez.

Tâche 3 : Vérifier que la socket UDP est liée (mismatch de port attrapé)

cr0x@server:~$ sudo ss -lunp | grep 51820
UNCONN 0      0           0.0.0.0:51820      0.0.0.0:*    users:(("wireguard",pid=1240,fd=6))

Sens : Le système écoute sur l’UDP 51820 sur toutes les adresses IPv4.

Décision : S’il n’y a pas d’écoute, corrigez wg0 ou changez la config client pour qu’elle corresponde au port réel.

Tâche 4 : Vérifier que des paquets arrivent au serveur (prouver le chemin réseau)

cr0x@server:~$ sudo tcpdump -ni any udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
09:36:11.112233 eth0  IP 198.51.100.44.61644 > 203.0.113.10.51820: UDP, length 148
09:36:16.113901 eth0  IP 198.51.100.44.61644 > 203.0.113.10.51820: UDP, length 148

Sens : Le client atteint le port UDP de votre serveur.

Décision : Si vous ne voyez rien pendant que le client bascule le tunnel, corrigez les règles périmétriques, les groupes de sécurité cloud, les blocages ISP ou l’adresse du endpoint.

Tâche 5 : Confirmer que le forwarding côté serveur est activé

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Sens : Le forwarding IPv4 est activé ; requis pour router depuis wg0 vers une autre interface.

Décision : S’il vaut 0 et que vous attendez du routage depuis le serveur, activez‑le et persistez le réglage (puis retestez le trafic).

Tâche 6 : Vérifier les règles NAT nftables/iptables pour les setups full‑tunnel

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE

Sens : Les clients depuis 10.6.0.0/24 sont NATés sur eth0, donc ils peuvent atteindre Internet (ou l’amont) sans routes de retour explicites.

Décision : Si cette règle manque et que vous voulez un egress full‑tunnel, ajoutez‑la. Si vous voulez un split tunnel vers un LAN, vous pouvez préférer des routes correctes plutôt que du NAT.

Tâche 7 : Vérifier que le serveur a une route vers le sous‑réseau client et que le LAN a une route de retour (split tunnel)

cr0x@server:~$ ip route
default via 203.0.113.1 dev eth0
10.0.10.0/24 dev br0 proto kernel scope link src 10.0.10.1
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1

Sens : Le serveur sait que le sous‑réseau WireGuard est sur wg0.

Décision : Si votre cible est 10.0.10.0/24 et que les clients n’y accèdent pas, assurez‑vous que le côté LAN sait comment renvoyer le trafic vers 10.6.0.0/24 (via ce serveur). Sans cela, vous aurez des flux unidirectionnels et de la tristesse.

Tâche 8 : Confirmer les AllowedIPs du peer côté serveur (mauvais sous‑réseaux, mauvais /32)

cr0x@server:~$ sudo wg show wg0 allowed-ips
9Z...clientpub... 10.6.0.2/32

Sens : Le serveur routage 10.6.0.2 vers ce peer. C’est typique pour l’adressage client.

Décision : Si vous avez accidentellement attribué la même IP client à deux peers, ou donné un /24 à un seul peer, vous causerez du mauvais routage. Corrigez l’adressage et AllowedIPs.

Tâche 9 : Rechercher des clés dupliquées (deux appareils partageant une config)

cr0x@server:~$ sudo wg show wg0 | sed -n '1,120p'
interface: wg0
  public key: 2y...serverpub...
  listening port: 51820

peer: 9Z...clientpub...
  endpoint: 198.51.100.44:61644
  latest handshake: 24 seconds ago
  transfer: 2.10 MiB received, 3.90 MiB sent

peer: 9Z...clientpub...
  endpoint: 203.0.113.200:54321
  latest handshake: 3 seconds ago
  transfer: 2.11 MiB received, 3.91 MiB sent

Sens : Même clé publique apparaissant deux fois est un signal d’alerte. En pratique vous verrez généralement une entrée peer, mais l’endpoint « basculera » entre deux IPs à mesure que les appareils se disputent.

Décision : Émettre des paires de clés uniques par appareil. Ne clonez jamais des configs avec la même clé privée sur plusieurs portables.

Tâche 10 : Tester la connectivité depuis le serveur vers le tunnel (serveur vers client)

cr0x@server:~$ ping -c 3 10.6.0.2
PING 10.6.0.2 (10.6.0.2) 56(84) bytes of data.
64 bytes from 10.6.0.2: icmp_seq=1 ttl=128 time=32.1 ms
64 bytes from 10.6.0.2: icmp_seq=2 ttl=128 time=31.7 ms
64 bytes from 10.6.0.2: icmp_seq=3 ttl=128 time=33.0 ms

--- 10.6.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Sens : Le serveur peut atteindre l’IP tunnel du client. C’est un bon signe pour le routage et le pare‑feu côté client.

Décision : Si ceci échoue mais que le handshake existe, suspectez le pare‑feu Windows sur l’adaptateur tunnel, ou qu’ICMP est bloqué. Testez aussi des flux TCP/UDP.

Tâche 11 : Identifier les trous noirs MTU avec une sonde « ne pas fragmenter » (côté serveur)

cr0x@server:~$ ping -c 3 -M do -s 1360 10.6.0.2
PING 10.6.0.2 (10.6.0.2) 1360(1388) bytes of data.
From 10.6.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
From 10.6.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1420)
From 10.6.0.1 icmp_seq=3 Frag needed and DF set (mtu = 1420)

--- 10.6.0.2 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2046ms

Sens : La PMTU est inférieure à votre taille de charge utile ; l’erreur suggère un MTU autour de 1420.

Décision : Réglage du MTU sur l’interface WireGuard plus bas (souvent 1280–1420 selon le chemin). Retestez jusqu’à ce que la sonde « ne pas fragmenter » réussisse.

Tâche 12 : Vérifier les règles de filtrage du pare‑feu du serveur pour le trafic wg0

cr0x@server:~$ sudo iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p udp --dport 51820 -j ACCEPT
-A FORWARD -i wg0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sens : UDP 51820 est autorisé en entrée, et le forwarding entre wg0 et eth0 est permis.

Décision : Si les règles de forwarding manquent, le handshake peut fonctionner mais le trafic transféré sera rejeté. Corrigez les règles FORWARD (ou l’équivalent nftables) et retestez.

Tâche 13 : Confirmer la reachabilité du serveur DNS via le tunnel (exemple côté serveur)

cr0x@server:~$ dig @10.0.10.53 internal-app.example A +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> @10.0.10.53 internal-app.example A +time=2 +tries=1
;; ANSWER SECTION:
internal-app.example. 60 IN A 10.0.10.25

;; Query time: 34 msec

Sens : Le serveur DNS interne répond rapidement du point de vue réseau du serveur.

Décision : Si le DNS est joignable depuis le serveur mais pas depuis le client, concentrez‑vous sur le routage côté client / l’affectation DNS. Si il n’est pas joignable depuis le serveur non plus, corrigez d’abord le routage/le pare‑feu LAN.

Tâche 14 : Valider que le fichier de config peer du serveur n’a pas dérivé

cr0x@server:~$ sudo grep -nE '^\[Interface\]|\[Peer\]|ListenPort|Address|AllowedIPs|PostUp|PostDown' /etc/wireguard/wg0.conf
1:[Interface]
2:Address = 10.6.0.1/24
3:ListenPort = 51820
4:PostUp = iptables -t nat -A POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE
5:PostDown = iptables -t nat -D POSTROUTING -s 10.6.0.0/24 -o eth0 -j MASQUERADE
7:[Peer]
8:PublicKey = 9Z...clientpub...
9:AllowedIPs = 10.6.0.2/32

Sens : Vous vérifiez les clés exactes et les directives de routage qui importent pour « connectivité vs non connectivité ».

Décision : Si la config contient d’anciens PostUp, un mauvais nom d’interface, ou des AllowedIPs conflictuels, corrigez‑la, redémarrez wg-quick, et retestez.

Blague n°2 : Les bugs MTU sont le genre de problème qui vous fait regretter les jours où votre réseau échouait bruyamment.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le tunnel est actif » mais rien ne fonctionne

Symptôme : L’interface WireGuard affiche Connecté ; pas de sites web, pas d’applis internes, pas de pings.

Cause racine : AllowedIPs n’inclut pas les destinations ; ou la table de routage Windows envoie le trafic ailleurs.

Correctif : Décidez tunnel split vs full, puis configurez AllowedIPs en conséquence. Vérifiez que les routes existent et ne sont pas écrasées par la métrique d’un autre adaptateur.

2) Le handshake n’apparaît jamais (Latest handshake : never)

Symptôme : Le client bascule on/off ; le serveur ne montre ni endpoint ni handshake.

Cause racine : UDP bloqué, mauvais endpoint/port, serveur non à l’écoute, règle firewall cloud manquante, ou NAT non redirigé.

Correctif : Vérifications côté serveur avec ss -lunp et tcpdump. Si les paquets n’arrivent pas, corrigez le périmètre. S’ils arrivent mais pas de handshake, revérifiez les clés et l’affectation des peers.

3) Handshake présent, mais incapacité à atteindre les ressources LAN

Symptôme : Le dernier handshake se met à jour, mais les sous‑réseaux internes sont inaccessibles.

Cause racine : Règles de forwarding/NAT serveur manquantes, ou le LAN ne route pas de retour vers le sous‑réseau WireGuard.

Correctif : Activez l’IP forwarding ; ajoutez du NAT pour le full tunnel, ou ajoutez des routes de retour sur la passerelle LAN pour le split tunnel.

4) La connectivité IP fonctionne ; le DNS échoue

Symptôme : ping 10.0.10.25 fonctionne mais les noms ne se résolvent pas ; les navigateurs tournent en boucle.

Cause racine : Mauvais serveurs DNS dans la config, Windows n’utilise pas le DNS du tunnel, ou les serveurs DNS ne sont pas atteignables via le tunnel.

Correctif : Assurez‑vous que l’IP du serveur DNS est incluse dans AllowedIPs et atteignable ; confirmez que Windows lie le DNS à l’interface WireGuard ; évitez de pousser un DNS public pour des zones internes seulement.

5) Ça marche sur le hotspot du téléphone, échoue sur le réseau d’entreprise / l’hôtel

Symptôme : Même portable, même config ; réseau différent provoque « jamais de handshake » ou instabilité.

Cause racine : UDP sortant restreint, portail captif, NAT symétrique étrange, ou timeout UDP agressif.

Correctif : Mettre PersistentKeepalive = 25 sur le client pour les réseaux NATés ; envisager de déplacer le serveur sur un port plus accessible ; confirmer que le réseau autorise l’UDP sortant.

6) Certains sites s’ouvrent ; d’autres bloquent ; RDP/SMB cale

Symptôme : Succès partiel ; timeouts ; gros téléchargements qui se bloquent.

Cause racine : MTU / fragmentation en trou noir.

Correctif : Baisser le MTU sur le tunnel ; tester avec des pings DF et du trafic applicatif réel.

7) « Ça marchait hier » après une mise à jour Windows

Symptôme : Après la mise à jour, l’adaptateur manque ou le trafic est bloqué.

Cause racine : Problème de pilote, profil de pare‑feu changé, nouvelle catégorie réseau, ou logiciel de sécurité ayant réappliqué des politiques.

Correctif : Réinstaller WireGuard, revérifier les règles pare‑feu pour l’interface WireGuard, confirmer que l’adaptateur existe et est activé.

8) Deux utilisateurs ne peuvent pas se connecter en même temps

Symptôme : L’un se connecte, l’autre tombe ; les endpoints basculent sur le serveur.

Cause racine : Clé privée client partagée (config clonée).

Correctif : Clés uniques par appareil ; IP de tunnel unique par peer ; auditer les configs pour réutilisation.

Listes de contrôle / plan étape par étape

Étape par étape : de « ne se connecte pas » à la cause racine

1. Définir l’échec : « Pas de handshake » vs « handshake mais pas de trafic » vs « trafic mais DNS cassé ». Ne zappez pas cette étape.
2. La vérité côté serveur : exécutez wg show. Confirmez le port d’écoute et si le serveur voit un endpoint.
3. Chemin réseau : tcpdump sur le port UDP en basculant le tunnel Windows.
4. Clés et mapping des peers : vérifiez que la clé publique peer du serveur correspond à la clé publique du client Windows ; confirmez que les AllowedIPs de chaque peer sont corrects et non chevauchants.
5. Politique de routage : décidez split ou full tunnel. Configurez ensuite AllowedIPs et les NAT/routes serveur de façon cohérente avec ce choix.
6. Forwarding/NAT : activer l’IP forwarding ; ajouter le masquerade NAT pour l’egress full tunnel ; ou configurer les routes de retour LAN pour le split tunnel.
7. DNS : confirmez que le serveur DNS est joignable via le tunnel et que Windows l’utilise pour les requêtes vers les zones internes.
8. MTU : si ça « marche presque », testez la MTU avec ping DF et baissez le MTU.
9. Outils de sécurité : si tout est correct mais que ça échoue sur des endpoints gérés, suspectez les politiques pare‑feu/EDR ; impliquez le propriétaire de la politique tôt.
10. Stabiliser : ajoutez keepalive seulement si le NAT l’exige ; documentez ports, sous‑réseaux et responsabilités.

Checklist de sanity configuration (client + serveur)

• L’Endpoint IP/hostname est correct ; le port correspond à l’écoute serveur.
• Le client possède une clé privée unique ; le serveur a la clé publique correspondante du peer.
• AllowedIPs du client inclut les destinations que vous attendez router via le tunnel.
• AllowedIPs du peer sur le serveur inclut l’IP tunnel client (/32) et ne chevauche pas d’autres peers.
• Le serveur a net.ipv4.ip_forward=1 si un routage au‑delà de wg0 est requis.
• Des règles NAT/forwarding existent si vous faites de l’egress full‑tunnel.
• Les serveurs DNS poussés au client sont atteignables via le tunnel.
• Le MTU est ajusté pour le chemin ; évitez de penser « valeur par défaut pour toujours ».

Trois mini‑récits d’entreprise tirés du terrain

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse (le DNS est « toujours joignable »)

Une entreprise de taille moyenne a déployé WireGuard pour permettre aux ingénieurs d’atteindre des tableaux de bord internes. Split tunnel, sous‑réseaux simples, tout était propre.
La configuration poussait deux serveurs DNS internes, parce que les applis internes utilisaient des noms internes. Raisonnable.

Le lundi matin, les tickets ont explosé : « Le VPN se connecte mais rien ne marche. » Le support voyait « Connecté » et a dit aux gens de redémarrer.
Redémarrer n’a rien changé sauf gaspiller la pause café de tout le monde.

La mauvaise hypothèse : croire que les serveurs DNS étaient atteignables depuis le tunnel. Ils ne l’étaient pas.
Un changement réseau la semaine précédente avait déplacé le DNS vers un VLAN différent et resserré les ACL. Le sous‑réseau WireGuard n’était pas inclus.
Les clients pouvaient atteindre des IPs internes s’ils les connaissaient, mais la résolution de noms échouait, et la plupart des applis n’essayaient même pas de fallback IP.

La correction fut ennuyeuse et correcte : soit autoriser le sous‑réseau WireGuard à interroger le DNS (préféré), soit pousser un serveur DNS atteignable depuis le sous‑réseau WireGuard.
Après la mise à jour des ACL, la « panne VPN » a disparu instantanément — sans changement WireGuard nécessaire.

La leçon : traitez le DNS comme une dépendance que vous devez router et autoriser explicitement. Dans les réseaux d’entreprise, le DNS n’est rarement « simplement là » ; il est gardé comme une pièce de musée.

Mini‑récit 2 : L’optimisation qui a mal tourné (raccourcis NAT astucieux)

Une autre équipe voulait un full‑tunnel VPN pour que les portables sortent via une pile de sécurité centrale. Ils ont construit une VM passerelle WireGuard.
Pour « optimiser », ils ont utilisé une règle NAT minimale et supprimé ce qu’ils pensaient être de la logique de forwarding redondante.
Ils ont aussi durci les defaults du pare‑feu pour être restrictifs, parce que les revues de sécurité aiment les defaults restrictifs.

Ça fonctionnait sur un simple test de ping. Ils ont déclaré la victoire et ont déployé.
Puis le trafic applicatif a commencé à échouer de façon étrange : certains sites HTTPS s’ouvraient, d’autres faisaient timeout ; les gros téléchargements s’arrêtaient ; les mises à jour logicielles échouaient de façon aléatoire.
Ça ressemblait à la flakiness Internet aléatoire, ce qui est le genre de flakiness le plus coûteux.

Le retour de bâton était double. D’abord : ils n’avaient pas validé la MTU bout en bout. L’encapsulation plus un chemin cloud avec un comportement MTU étrange a créé un trou noir de fragmentation.
Ensuite : leur ensemble de règles pare‑feu « minimal » n’autorisait le trafic de retour établi que dans une direction d’interface ; certains flux étaient rejetés selon le chemin choisi par le kernel.

La remédiation fut sans élégance : règles FORWARD explicites pour wg0 ↔ egress, gestion correcte du conntrack, et un MTU abaissé à une valeur testée et sûre.
Les performances ne se sont pas dégradées. La fiabilité s’est améliorée radicalement, ce qui est un indicateur de performance que les adultes apprécient.

La leçon : « optimiser » la politique réseau en supprimant des lignes que vous ne comprenez pas, c’est comme « optimiser » un avion en enlevant des boulons dont vous ne connaissez pas le nom.

Mini‑récit 3 : La pratique ennuyeuse qui a sauvé la journée (clés uniques et inventaire des peers)

Une organisation globale avait une flotte d’ordinateurs portables de sous‑traitants. Les sous‑traitants allaient et venaient ; les appareils étaient réinstallés fréquemment.
L’équipe VPN a instauré une règle pénible : chaque appareil reçoit des clés WireGuard uniques, une IP tunnel unique et un enregistrement d’inventaire.
Pas de configs partagées. Pas de « copie le fichier d’Alice ».

Les gens se sont plaints. C’était du travail supplémentaire. Ça ralentissait les demandes d’accès rapides.
Mais cela a rendu le système observable : quand un peer apparaissait sur le serveur, vous saviez quel appareil c’était. Quand il se comportait mal, vous pouviez le désactiver en toute sécurité.

Un vendredi, la connectivité a commencé à osciller pour un sous‑ensemble d’utilisateurs. Les logs serveur n’étaient pas très bavards (WireGuard est notoirement minimaliste),
mais wg show montrait des endpoints « en déplacement » rapidement pour une clé publique particulière.
Ce motif criait « clé dupliquée dans la nature ».

Parce qu’ils avaient un inventaire, ils ont identifié l’appareil, contacté le propriétaire et pivoté les clés sans toucher aux autres utilisateurs.
Pas de panne large, pas de reconfiguration massive, pas de devinettes sur quel peer était lequel.
La pratique ennuyeuse s’est remboursée en une seule après‑midi.

La leçon : l’unicité et l’inventaire sont des fonctionnalités de fiabilité. Elles ne se perçoivent pas comme des fonctionnalités jusqu’au jour où vous en avez besoin.

FAQ

1) Pourquoi WireGuard affiche « Connecté » sur Windows alors que je n’ai pas d’internet ?

« Connecté » signifie seulement que l’interface est up et que la config est chargée. Ça ne garantit pas que le routage est correct.
Vérifiez le handshake, puis vérifiez AllowedIPs et si Windows route 0.0.0.0/0 (tunnel complet) via WireGuard ou pas.

2) J’ai un handshake, mais je n’atteins pas les sous‑réseaux internes. Quelle est l’explication la plus rapide ?

Le serveur ne forwarde pas le trafic depuis wg0 vers le LAN, ou le LAN n’a pas de route de retour vers le sous‑réseau WireGuard.
Le handshake prouve « on peut se parler ». Il ne prouve pas « on peut router ».

3) Ai‑je besoin de PersistentKeepalive sur Windows ?

Seulement si le client Windows est derrière des NAT/pare‑feux qui suppriment les mappings UDP inactifs. Si vous voyez des handshakes seulement après envoi de trafic,
ou la connectivité meurt après quelques minutes d’inactivité, configurez PersistentKeepalive = 25 dans la section peer du client.

4) Quels AllowedIPs utiliser pour un split tunnel ?

Incluez les réseaux internes que vous voulez atteindre (exemple : 10.0.0.0/8 ou des /24s spécifiques), plus tout autre plage privée dont vous avez vraiment besoin.
N’ajoutez pas 0.0.0.0/0 « au cas où ». Ce n’est pas un split tunnel ; c’est confier vos décisions de routage à votre futur‑vous.

5) Pourquoi ça marche sur mon hotspot phone mais pas sur le Wi‑Fi du bureau ?

Les réseaux d’entreprise restreignent souvent l’UDP sortant, imposent des portails captifs, ou font de l’inspection stateful qui termine vite les mappings UDP.
Prouvez‑le avec un tcpdump côté serveur : si les paquets n’arrivent jamais depuis le réseau du bureau, ce n’est pas un problème de config Windows.

6) Deux portables Windows peuvent‑ils utiliser la même config WireGuard ?

Non. Pas en toute sécurité. S’ils partagent la même clé privée, le serveur les traitera comme le même peer et l’endpoint « errera » entre eux.
Vous aurez du flapping, du trafic intermittent, et des reproches qui voyagent plus vite que l’UDP.

7) Quel MTU dois‑je définir pour WireGuard sur Windows ?

Il n’y a pas de valeur universelle. Des points de départ sûrs courants sont 1420 ou 1380 ; pour des chemins hostiles, 1280 est la valeur « faites‑le fonctionner ».
Si vous avez le handshake mais que les applications bloquent, testez la PMTU et baissez le MTU jusqu’à ce que les blocages cessent.

8) Dois‑je utiliser un nom d’hôte ou une IP pour l’Endpoint ?

L’IP est plus déterministe. Les noms d’hôtes vont bien si le DNS est fiable et contrôlé, mais cela ajoute une dépendance.
Si vous devez utiliser des noms d’hôte, assurez‑vous que le client Windows peut les résoudre sur tous les réseaux qui comptent pour vous (y compris les portails captifs et les DNS verrouillés).

9) Pourquoi puis‑je pinguer l’IP WireGuard du serveur mais pas atteindre quoi que ce soit derrière ?

Parce qu’atteindre l’adresse wg0 du serveur est juste un saut tunnel direct. Atteindre quoi que ce soit derrière nécessite du forwarding et souvent du NAT ou des routes de retour.
Corrigez le forwarding serveur, le pare‑feu et le routage en amont.

10) WireGuard est‑il « moins compatible » que d’autres VPN sur les réseaux d’entreprise ?

Il est souvent plus bloqué simplement parce qu’il utilise l’UDP et est facile à identifier par comportement (pas nécessairement par le payload).
De nombreux environnements d’entreprise autorisent explicitement TLS/443 mais considèrent l’UDP arbitraire comme suspect. C’est une politique, pas un bug WireGuard.

Étapes suivantes pour maintenir la stabilité

Si vous voulez que WireGuard sur Windows redevienne ennuyeux, opérez‑le comme n’importe quelle dépendance de production :
mesurez la réalité (handshake, routes, DNS), imposez l’unicité (clés, IPs), et documentez le modèle de routage prévu (split vs full).
La plupart des tickets « ne se connecte pas » disparaissent une fois que vous cessez de traiter l’UI client comme vérité et commencez à traiter le serveur comme la source de vérité.

1. Choisissez une norme : split tunnel ou full tunnel, et faites correspondre AllowedIPs.
2. Côté serveur, conservez une base vérifiée : wg show, vérification de l’écoute, forwarding, règles firewall/NAT.
3. Notez la propriété : qui contrôle le DNS, qui contrôle les règles UDP périmétriques, qui contrôle les politiques de sécurité endpoint.
4. Quand ça tombe en panne : suivez le plan de diagnostic rapide — handshake → reachabilité IP → DNS → MTU.

L’objectif n’est pas « le VPN se connecte ». L’objectif est « les paquets qui comptent atteignent les services pour lesquels vous payez », de façon cohérente, sur les réseaux où vos utilisateurs sont réellement.