WireGuard Roaming : la solution qui empêche les déconnexions VPN mobiles

février 10, 2026 • février 10, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Votre téléphone bascule du Wi‑Fi du bureau vers le LTE, votre VPN se coupe, Slack se reconnecte, votre session SSH se fige, et votre cerveau en astreinte commence à faire des calculs qu’il n’avait pas demandés.
Si vous avez vécu ça, vous n’imaginez pas des choses : la plupart des VPN ont été conçus avec l’idée romantique que les adresses IP restent fixes.

WireGuard est l’un des rares VPN à considérer le roaming comme une réalité de première classe. Ce n’est pas « compatible mobile » au sens marketing.
C’est compatible mobile dans le sens « je peux sortir d’un bâtiment en plein incident et mon tunnel n’implose pas ».

Le vrai problème du roaming : les réseaux mentent

« Roaming » sonne poli. Comme si votre portable se promenait dans un pré et changeait de point d’accès sans y penser.
En production, le roaming signifie que votre IP source et votre port source changent, que les mappings NAT s’évaporent, que les chemins deviennent bizarres, et que l’état UDP est traité comme un gobelet jetable.

La majorité des douleurs liées aux VPN mobiles ne viennent pas de la cryptographie. Elles viennent de l’état. Plus précisément : qui pense que le pair est « à » quelle IP:port en ce moment, et si les dispositifs intermédiaires sont d’accord assez longtemps pour que les paquets arrivent.
Les réseaux cellulaires ajoutent du chaos : NAT de niveau opérateur, timeouts d’inactivité agressifs, et comportements d’économie d’énergie qui mettent votre app et ses sockets en pause.

Les piles VPN classiques lient souvent l’identité à une session qui suppose implicitement un transport stable. Quand le transport change, la session nécessite une renégociation.
La négociation prend du temps. Certaines implémentations le font mal. D’autres le font « correctement » mais exigent des keepalives si fréquents qu’ils consument la batterie et échouent quand même.

L’approche de WireGuard est franche : votre identité est votre clé publique. Les détails du transport sont remplaçables.
Si un paquet authentifié arrive depuis une nouvelle adresse, WireGuard met à jour son idée de l’emplacement du pair.
Voilà le roaming. Ce n’est pas de la magie ; c’est un choix de conception qui opérationnalise l’évidence : les téléphones bougent.

Pourquoi les VPN mobiles « se déconnectent » alors que le tunnel est actif

Beaucoup d’incidents sont mal classés comme « déconnexion VPN ». Le tunnel peut être toujours configuré, l’interface encore présente, et le client afficher « connecté ».
Ce qui se passe réellement est l’un de ces cas :

Mapping NAT expiré : le serveur répond à une adresse/port qui ne correspond plus au client.
MTU du chemin changé : le chemin LTE a réduit le MTU ; paquets perdus ; TCP s’arrête ; les utilisateurs parlent de « déconnexion ».
DNS changé : vous êtes passé sur un réseau avec d’autres résolveurs ; votre DNS VPN n’est pas appliqué ; les recherches de noms échouent.
Politique de routage modifiée : le système d’exploitation décide que la route par défaut a changé ; les règles de split tunnel entrent en conflit ; certains flux échappent ou bouclent.
État du pare‑feu en désaccord : les « sessions » UDP sont indicatives ; en plein roam vous perdez le trafic de retour.

WireGuard ne résout pas tous ces problèmes à lui seul. Mais il règle proprement la question centrale identité/endpoint, ce qui élimine une grande classe d’instabilités.

Comment WireGuard gère réellement le roaming

WireGuard est un tunnel de couche 3 avec un protocole minimal et une idée stricte : les paquets doivent être authentifiés.
Si le serveur reçoit un paquet authentifié pour un pair depuis une nouvelle IP:port, il met à jour l’endpoint de ce pair vers la nouvelle adresse et répond là‑bas.
Pas de cérémonie de « reconnexion » nécessaire.

Cette mise à jour d’endpoint se produit des deux côtés. Le client peut aussi roamer : s’il entend le serveur répondre depuis une nouvelle adresse (moins courant, mais pertinent pour l’anycast ou les serveurs multi‑homés),
il met aussi à jour son endpoint.

Handshake vs paquets de données : ce que met à jour quoi

WireGuard utilise un handshake basé sur Noise. Un paquet de handshake est authentifié. Un paquet de données l’est aussi.
L’apprentissage d’endpoint se produit lorsqu’un paquet est authentifié et déchiffré avec succès.
C’est un détail crucial : du spam UDP aléatoire ne peut pas déplacer votre endpoint. Seul un pair possédant les bonnes clés peut le faire.

Le roaming n’est donc pas « accepter des paquets de n’importe où ». C’est « accepter des paquets de n’importe où si ils prouvent qui ils sont ».
C’est pourquoi vous pouvez en toute sécurité laisser des clients mobiles passer du Wi‑Fi au LTE, des hôtels aux portails captifs, etc.

Pourquoi les keepalives existent si le roaming est si efficace

Le roaming règle le problème du changement d’endpoint. Il ne défait pas les timeouts NAT par simple volonté.
Si un client est derrière un NAT et inactif, le mapping peut expirer. Le serveur enverra toujours des réponses vers le dernier endpoint connu, qui pointe maintenant vers rien.

La solution est PersistentKeepalive côté client derrière NAT (souvent le mobile).
Il envoie périodiquement des paquets vides pour maintenir le mapping NAT vivant.
Vous devriez l’utiliser délibérément, et non par superstition.

Les keepalives ont un coût : batterie, réveils radio, et parfois augmentation de la consommation de données.
Mais l’alternative, c’est que votre tunnel devienne discrètement un élément d’interface décoratif.

Une citation que les équipes d’exploitation devraient tatouer dans leurs runbooks

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Si votre VPN mobile dépend du fait que « le NAT garde généralement les mappings UDP un moment », vous comptez sur l’espoir. L’espoir vous appelle à 2 h du matin.

Faits et historique qui expliquent la conception

WireGuard n’est pas apparu comme une « meilleure interface OpenVPN ». Il est né d’une frustration précise : les piles VPN étaient volumineuses, difficiles à auditer, et toléraient trop les mauvais réglages par défaut.
Voici quelques faits et points de contexte concrets qui rendent le roaming inévitable plutôt que surprenant :

WireGuard a démarré vers 2015 comme projet visant une solution VPN plus simple et auditable avec des choix cryptographiques modernes.
Il utilise le cadre de protocole Noise (notamment une variante du pattern IK) pour structurer les handshakes avec de fortes propriétés de sécurité.
Il vise un codebase réduit comparé aux implémentations VPN historiques, ce qui réduit la surface d’attaque et rend les audits moins pénibles.
Il vivait initialement hors‑arbre pour Linux puis a intégré le noyau Linux (mainline) en 2020, un important vote de confiance et un accélérateur de déploiement.
Il utilise UDP par conception pour éviter le meltdown TCP‑sur‑TCP et parce que UDP tolère mieux les conditions réseau changeantes.
L’identité est une clé publique, pas une adresse IP ; les IP sont routées à l’intérieur du tunnel comme « AllowedIPs ».
Le roaming est un comportement de première classe : les endpoints sont appris dynamiquement sur la base de paquets authentifiés, et non épinglés pour toujours.
Il évite délibérément la négociation cryptographique ; il n’y a pas de menu « choisir parmi 17 chiffrements ». Cela prévient les attaques de rétrogradation et la dérive de configuration.
Il est souvent implémenté sur mobile en utilisant les piles réseau natives de l’OS (par exemple, tunnel providers), ce qui aide la stabilité mais hérite des politiques d’économie d’énergie de l’OS.

Ce qu’il faut configurer (et ce qu’il ne faut pas)

Le roaming « fonctionne tout seul » uniquement si vous ne le sabotez pas avec de mauvaises hypothèses.
WireGuard est simple, mais cette simplicité vous rapproche du matériel. Vous pouvez absolument vous tirer une balle dans le pied.
L’arme est petite. Elle fonctionne quand même.

Décidez l’intention du tunnel : tunnel complet vs split tunnel

Pour les utilisateurs mobiles, le split tunnel est généralement le choix sensé par défaut sauf exigence de conformité spécifique.
Le tunnel complet séduit jusqu’à ce que vous fassiez transiter des appels vidéo via votre datacenter, que vous deveniez involontairement un FAI, et que les utilisateurs vous jugent pour la physique.

Tunnel complet : AllowedIPs du client inclut 0.0.0.0/0, ::/0. Vous devez fournir DNS, NAT de sortie, et gérer le MTU avec soin.
Split tunnel : AllowedIPs du client n’inclut que les sous‑réseaux internes (et peut‑être quelques plages de services). Moins de casse, moins de coûts de bande passante.

Utilisez PersistentKeepalive sur les clients derrière NAT (généralement mobiles)

Si le client mobile est derrière un NAT et que vous avez besoin qu’il soit joignable (pour des réponses, du push, ou simplement des sessions fiables), définissez :
PersistentKeepalive = 25 secondes dans l’entrée peer du client pour le serveur.

Pourquoi 25 ? C’est une valeur pragmatique qui bat de nombreux timeouts NAT sans être absurde. Mais ne l’idolâtrez pas. Mesurez vos réseaux.

MTU : le tueur silencieux des tickets « ça se déconnecte »

Le roaming change les chemins. Les chemins changent le MTU. Le LTE et certaines configurations Wi‑Fi peuvent être allergiques à la fragmentation.
Quand le MTU est faux, vous obtenez des blocages, une connectivité partielle, et des utilisateurs qui décrivent cela comme « le VPN est instable ».

Mon paramètre par défaut pour WireGuard mobile est de commencer autour de 1280 pour la compatibilité IPv6 et moins de surprises.
Sur des réseaux plus propres vous pouvez monter (1420 est courant). Mais si vous dépannez des pertes sur mobile, réduisez le MTU avant de toucher à la crypto.

DNS : choisissez une stratégie et appliquez‑la de façon cohérente

Beaucoup de « déconnexions » sont en réalité des échecs de résolution de noms après un roaming.
Décidez si le DNS est :

À l’intérieur du tunnel : définissez le DNS dans la config client ; assurez‑vous que le serveur DNS est joignable via AllowedIPs ; assurez‑vous que le serveur résout/transfère.
À l’extérieur du tunnel : acceptez le DNS local ; n’attendez pas que les noms internes fonctionnent partout.

Pare‑feu : autorisez ce que vous avez construit

WireGuard utilise UDP. Si votre périmètre considère UDP comme suspect (ce qui arrive souvent), vous devez l’autoriser explicitement.
Aussi : si vous exécutez WireGuard sur un port non standard pour « le cacher », soyez honnête sur ce que vous optimisez.
La sécurité par l’obscurité, c’est comme se déguiser pour une réunion d’équipe ; ça embrouille surtout vos collègues.

Tâches pratiques : commandes, sorties, décisions

Ce sont des tâches réelles que j’exécuterais lors de la configuration ou en déboguant le roaming et la stabilité mobile.
Chacune inclut une commande, une sortie représentative, ce que la sortie signifie, et la décision suivante.

Task 1: Confirm WireGuard interface state on the server

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 6E9q...yZ0=
  private key: (hidden)
  listening port: 51820

peer: oYt9...r3Q=
  allowed ips: 10.6.0.2/32
  latest handshake: 14 seconds ago
  transfer: 22.34 MiB received, 48.11 MiB sent
  persistent keepalive: every 25 seconds

Signification : Le pair a effectué un handshake récemment ; des transferts ont lieu ; le keepalive est configuré.

Décision : Si latest handshake est « never » ou très ancien, arrêtez de blâmer le MTU ou le DNS et concentrez‑vous sur la joignabilité (UDP/port/NAT).

Task 2: Check if the server is actually listening on the expected UDP port

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

Signification : Le noyau écoute sur UDP/51820.

Décision : Si rien n’écoute, votre problème est local (service/config), pas un « roaming ». Réparez le service systemd ou la config d’abord.

Task 3: Verify firewall allows WireGuard UDP

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport 51820 accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }
}

Signification : Politique par défaut drop, mais UDP/51820 est explicitement accepté.

Décision : Si vous ne voyez pas une règle d’acceptation, ajoutez‑en une. Si vous comptez sur « le security group probablement l’autorise », vous externalisez votre disponibilité au feeling.

Task 4: Watch live handshakes to confirm roaming endpoint changes

cr0x@server:~$ sudo wg show wg0 latest-handshakes endpoints
peer: oYt9...r3Q=
  endpoint: 203.0.113.50:49213
  latest handshake: 1707142421

peer: 2xK1...a9c=
  endpoint: 198.51.100.77:61102
  latest handshake: 1707142414

Signification : Vous pouvez voir l’endpoint actuel de chaque peer (IP:port). Sur mobile, ce port change souvent lors du roaming.

Décision : Si l’endpoint ne change jamais même lorsque l’utilisateur roame, vous observez peut‑être du trafic épinglé via un proxy, ou le client n’envoie rien après le roam (sommeil/politique d’énergie).

Task 5: Confirm IP forwarding on the server (for routed traffic)

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Signification : Le serveur routage les paquets entre interfaces.

Décision : Si forwarding vaut 0, les clients peuvent handshake correctement mais ne pas atteindre d’autres réseaux. Réparez le forwarding avant de courir après des « bugs de roaming ».

Task 6: Confirm NAT is configured (for full tunnel or internet egress)

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    oifname "eth0" ip saddr 10.6.0.0/24 masquerade
  }
}

Signification : Le trafic du sous‑réseau VPN est masqué via eth0.

Décision : Si vous faites du tunnel complet et que le NAT manque, les clients se connecteront mais n’accéderont pas à Internet. On vous remontera « le VPN bloque les sites ».

Task 7: Validate routing table for the WireGuard subnet

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

Signification : Le serveur sait que le sous‑réseau VPN est directement sur wg0.

Décision : Si la route du sous‑réseau VPN est manquante, l’interface peut ne pas être up ou avoir la mauvaise adresse. Réparez cela d’abord.

Task 8: Check MTU on wg0 and path MTU symptoms

cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Signification : L’interface a un MTU de 1420 (valeur courante).

Décision : Si des utilisateurs mobiles rapportent des blocages sur LTE, essayez de réduire le MTU (par ex. 1280) sur le client et/ou le serveur. Puis retestez. Les corrections MTU ressemblent à des miracles parce qu’elles sont ennuyeuses.

Task 9: Test “don’t fragment” ping through the tunnel (MTU discovery)

cr0x@server:~$ ping -M do -s 1380 10.6.0.2 -c 3
PING 10.6.0.2 (10.6.0.2) 1380(1408) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

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

Signification : La taille du paquet dépasse les contraintes MTU de l’interface ; cela peut indiquer que votre MTU tunnel ne supporte pas la charge utile sans fragmentation.

Décision : Réduisez le MTU et répétez jusqu’à réussite. Si vous ne pouvez pas obtenir une taille « do not fragment » stable, suspectez un trou noir intermédiaire ou du filtrage ICMP.

Task 10: Capture WireGuard traffic to see if packets arrive during roam

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:13:01.112233 IP 203.0.113.50.49213 > 203.0.113.10.51820: UDP, length 148
12:13:01.113005 IP 203.0.113.10.51820 > 203.0.113.50.49213: UDP, length 92
12:13:26.144990 IP 198.51.100.22.60133 > 203.0.113.10.51820: UDP, length 148
12:13:26.145701 IP 203.0.113.10.51820 > 198.51.100.22.60133: UDP, length 92

Signification : Vous voyez des paquets venant de plusieurs IPs/ports sources. C’est exactement l’apparence du roaming en bordure : même clé de peer, endpoint différent au fil du temps.

Décision : Si vous voyez des paquets entrants mais que wg show n’actualise jamais les temps de handshake, suspectez des clés incorrectes ou des problèmes de rejeu/horloge. Si vous ne voyez rien d’entrant, c’est réseau/pare‑feu/NAT opérateur.

Task 11: Confirm client’s peer settings (on Linux client)

cr0x@server:~$ sudo wg showconf wg0
[Interface]
PrivateKey = (hidden)
Address = 10.6.0.2/32
DNS = 10.6.0.1

[Peer]
PublicKey = 6E9q...yZ0=
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

Signification : Split tunnel configuré (seulement plages RFC1918), DNS pointe à l’intérieur du tunnel, keepalive activé.

Décision : Si AllowedIPs est trop large, vous pourriez détourner des réseaux locaux (imprimantes, portails captifs). Si trop étroit, les services internes ne seront pas routés.

Task 12: Check for conflicting routes and policy routing on the client

cr0x@server:~$ ip rule show
0:      from all lookup local
32764:  from all lookup main
32765:  from all lookup default

cr0x@server:~$ ip route show table main | sed -n '1,12p'
default via 192.168.1.1 dev wlan0 proto dhcp metric 600
10.0.0.0/8 dev wg0 scope link
172.16.0.0/12 dev wg0 scope link

Signification : Les routes pour les sous‑réseaux internes passent par wg0 ; la route par défaut reste sur le Wi‑Fi. C’est le split tunnel en action.

Décision : Si la route par défaut pointe vers wg0 de manière inattendue, vous avez configuré un tunnel complet. Confirmez que c’est bien votre intention avant de blâmer l’instabilité du roaming.

Task 13: Confirm DNS resolver in effect (systemd-resolved example)

cr0x@server:~$ resolvectl status | sed -n '1,80p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 5 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.6.0.1
       DNS Servers: 10.6.0.1

Signification : Le DNS est fixé sur le serveur DNS VPN sur le lien WireGuard.

Décision : Si les serveurs DNS restent ceux du Wi‑Fi alors que vous attendez le DNS interne, corrigez la config client. Beaucoup de rapports « VPN en panne » sont en fait des « DNS incorrects ».

Task 14: Check conntrack timeouts (why your UDP goes missing)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_udp_timeout net.netfilter.nf_conntrack_udp_timeout_stream
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Signification : Les flux UDP peuvent expirer rapidement (30 s). Sur certains pare‑feux/NAT, c’est encore plus court.

Décision : Si vous observez des déconnexions d’inactivité autour de 30 secondes, un keepalive à 25 secondes stabilisera typiquement. Si la batterie est critique, ajustez en fonction des timeouts mesurés.

Task 15: Confirm time sync (handshakes hate time skew)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-04 12:21:42 UTC
           Universal time: Tue 2026-02-04 12:21:42 UTC
                 RTC time: Tue 2026-02-04 12:21:42
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Signification : L’horloge est synchronisée. Bien.

Décision : Si l’horloge système n’est pas synchronisée, vous pouvez voir des comportements étranges de handshake et des rejets de rejeu. Réparez le NTP avant d’inventer de nouvelles théories.

Task 16: Verify packets route between VPN client and internal subnet

cr0x@server:~$ ip route get 10.20.30.40 from 10.6.0.2 iif wg0
10.20.30.40 from 10.6.0.2 iif wg0
    via 10.0.0.1 dev eth0

Signification : Le noyau routerait le trafic du client VPN vers le réseau interne via eth0 (exemple).

Décision : Si cela renvoie vers wg0 ou nulle part, vous avez une asymétrie de routage. Le roaming ne vous sauvera pas d’un mauvais routage.

Méthode de diagnostic rapide

Quand un utilisateur mobile WireGuard dit « le VPN se déconnecte quand je quitte le Wi‑Fi », ne commencez pas par l’idéologie.
Commencez par le chemin le plus court pour isoler le goulot : transport, handshake, routage, MTU, DNS.

Premier point : l’UDP atteint‑il le serveur ?

Sur le serveur : lancez une capture courte sur le port WireGuard pendant que l’utilisateur bascule Wi‑Fi → LTE.

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 20
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:15:01.100001 IP 198.51.100.22.60133 > 203.0.113.10.51820: UDP, length 148
12:15:01.100550 IP 203.0.113.10.51820 > 198.51.100.22.60133: UDP, length 92

Si vous ne voyez rien : pare‑feu, security group, filtrage FAI, endpoint/port incorrect, ou client qui n’envoie pas parce que l’OS l’a suspendu. Réparez la joignabilité.

Si vous voyez des paquets : passez à la validation du handshake.

Second point : WireGuard les accepte‑t‑il (handshake) ?

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 6E9q...yZ0=
  listening port: 51820

peer: oYt9...r3Q=
  endpoint: 198.51.100.22:60133
  latest handshake: 6 seconds ago
  transfer: 4.12 MiB received, 6.88 MiB sent

Si le handshake est récent : le tunnel est vivant. Le « problème » est probablement le routage/MTU/DNS/le comportement de l’app.

Si le handshake reste ancien/never : clés incorrectes, config peer erronée, ou paquets non valides pour cette interface WireGuard. Vérifiez les configurations.

Troisième point : le problème concerne‑t‑il seulement certains flux (MTU/DNS/routage) ?

Testez un ping par IP (contourne le DNS).
Testez la résolution DNS via le serveur DNS du VPN.
Testez une connexion TCP avec une petite charge, puis des charges plus importantes.

Si les petites requêtes fonctionnent mais que les gros téléchargements stagnent, le MTU est le principal suspect.
Si l’IP fonctionne mais que les noms échouent, le DNS.
Si seuls certains sous‑réseaux échouent, AllowedIPs ou routage.

Erreurs courantes : symptôme → cause → correction

Voici les motifs récurrents derrière « le roaming WireGuard ne fonctionne pas », qui signifie généralement « nous avons construit un tunnel parfait dans un réseau imparfait ».

1) Symptom: “It works on Wi‑Fi, fails on LTE”

Cause racine : NAT opérateur et timeouts UDP d’inactivité courts ; le mapping expire pendant l’inactivité, le serveur répond vers un endpoint mort.

Correction : Définissez PersistentKeepalive = 25 dans l’entrée peer du client mobile ; éventuellement baissez à (par ex.) 15 si l’opérateur est particulièrement agressif. Confirmez via les timestamps de handshake.

2) Symptom: “Connected, but nothing loads after roaming”

Cause racine : Le handshake est correct, mais trou noir MTU après changement de chemin.

Correction : Réduisez le MTU sur le client (commencez à 1280) et/ou sur le serveur. Validez avec des tests ping -M do et des transferts applicatifs réels.

3) Symptom: “Some internal services work, others time out”

Cause racine : AllowedIPs manquants ou plages privées qui se chevauchent avec le réseau local (le café utilise 10.0.0.0/8 aussi).

Correction : Utilisez des routes plus spécifiques, évitez de router tout RFC1918 si possible, ou renumérotez les réseaux internes si vous aimez les projets longs. Si vous devez utiliser des plages larges, ajoutez des exceptions de policy routing.

4) Symptom: “VPN says connected, but DNS is broken”

Cause racine : DNS non appliqué par l’OS client, ou serveur DNS non joignable via AllowedIPs, ou serveur DNS n’écoutant que sur le LAN.

Correction : Assurez‑vous que l’IP du serveur DNS est incluse dans AllowedIPs et joignable ; configurez l’intégration du résolveur (systemd-resolved, NetworkManager, champ DNS du client mobile). Vérifiez avec le statut du résolveur.

5) Symptom: “Roaming causes a new handshake, and sessions die anyway”

Cause racine : Les sessions applicatives ne tolèrent pas les changements de chemin (certains TCP sont coupés), ou les pare‑feux stateful réinitialisent les flux.

Correction : Préférez des protocoles applicatifs qui retentent proprement ; évitez les middleboxes stateful entre clients et serveur quand c’est possible ; rapprochez le serveur WireGuard du bord.

6) Symptom: “Multiple clients ‘steal’ each other’s connectivity”

Cause racine : Clés peer dupliquées ou AllowedIPs dupliqués ; WireGuard route par AllowedIPs et attend l’unicité.

Correction : Une paire de clés unique par appareil ; une IP tunnel unique par peer (au moins en /32). Auditez les configs et faites tourner les clés si nécessaire.

7) Symptom: “Handshake is recent, but packets don’t reach the internal network”

Cause racine : Forwarding IP manquant, routes manquantes, NAT manquant, ou routage asymétrique dans le réseau interne (le chemin de retour ne connaît pas 10.6.0.0/24).

Correction : Activez le forwarding ; ajoutez une route interne de retour vers le sous‑réseau VPN ; ou utilisez NAT (moins élégant mais efficace) selon les contraintes réseau.

8) Symptom: “It dies when the phone screen turns off”

Cause racine : La gestion d’énergie de l’OS suspend le processus VPN ou bride le réseau en arrière‑plan ; la cadence des keepalives devient sans objet si le processus n’est pas planifié.

Correction : Utilisez les réglages VPN « toujours actif » spécifiques à la plateforme ; configurez des règles on‑demand ; sur Android, excluez l’app de l’optimisation batterie quand la politique le permet.

Trois mini-récits d’entreprise du terrain

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne a déployé WireGuard pour une équipe d’ingénieurs mobiles. La migration s’est bien passée—jusqu’à ce que ce ne soit plus le cas.
Les utilisateurs se plaignaient que le VPN « se déconnectait aléatoirement » en quittant le bureau. L’équipe a supposé que c’était un bug de WireGuard car l’UI affichait encore « connecté ».

Le premier intervenant a fait ce que tout le monde fait sous pression : redémarrer. Cela a aidé, temporairement.
Le roaming du Wi‑Fi vers le LTE créait de nouveaux ports sources. Le serveur voyait des paquets arriver. Les handshakes s’actualisaient. Mais le trafic applicatif mourait après une minute d’inactivité.

La mauvaise hypothèse était subtile : ils croyaient que le NAT devant le serveur WireGuard était « suffisamment stateful » et garderait les mappings UDP plusieurs minutes.
Dans cet environnement, ce n’était pas le cas. Le timeout UDP du NAT était court, et le comportement de l’opérateur mobile l’était encore davantage lorsqu’il y avait inactivité.

La correction fut ennuyeuse et immédiate : définir PersistentKeepalive pour les clients mobiles. Les « déconnexions » ont disparu.
Le postmortem n’a pas conclu « WireGuard doit être amélioré ». Il a conclu « mesurez le réseau que vous avez, pas celui dont vous vous souvenez ».

Ils ont aussi mis à jour leur runbook : tout rapport de « déconnexion après inactivité » déclenche d’abord une vérification conntrack/keepalive.
L’incident n’a pas été reproduit, ce qui est la meilleure forme de succès en exploitation.

Mini‑récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait réduire la consommation de batterie. Quelqu’un a noté que les keepalives étaient à 25 secondes et a jugé cela « gaspilleur ».
Ils ont poussé un changement pour augmenter le keepalive à 120 secondes pour les mobiles. Au bureau, tout semblait OK ; à la maison sur Wi‑Fi, aussi.

Puis l’équipe commerciale est partie en déplacement. Hôtels, aéroports, tethering, LTE en voiture—exactement les environnements où les timeouts NAT sont les moins prévisibles.
Les tickets ont explosé : le CRM ne chargeait pas, les dashboards internes temps‑outaient, « VPN instable ». Le helpdesk conseillait de basculer le mode avion, ce qui n’est pas une solution mais un rituel.

Le retour de bâton avait deux volets. D’abord, certains réseaux expiraient l’état UDP bien avant deux minutes.
Ensuite, quand les téléphones entraient en veille, le premier paquet après le réveil devait se frayer un chemin à travers de nouveaux mappings NAT et parfois de la perte de paquets ; sans keepalives fréquents, l’apprentissage d’endpoint était en retard par rapport aux attentes utilisateurs.

Ils ont restauré 25 secondes pour ces utilisateurs et introduit une politique : les valeurs de keepalive sont différenciées selon le profil utilisateur.
Les appareils sensibles à la batterie ont 40 secondes après tests ; les rôles à haute mobilité restent à 25. La bonne réponse n’était pas « réduire les keepalives pour toujours ».
C’était « arrêter d’optimiser sans budget d’échec ».

Ils ont aussi appris à tester le roaming en dehors du bureau. Un VPN qui ne marche que sur votre Wi‑Fi corporate est juste un LAN déguisé.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société financière utilisait WireGuard pour l’accès distant. Rien de spécial : port stable, règles de pare‑feu explicites, MTU conservateur, et gestion stricte des peers.
Leur gestion des changements était tout aussi sans glamour : configurations versionnées, déploiement par étapes, et audit hebdomadaire des AllowedIPs dupliqués.

Un lundi, un lot d’appareils a été provisionné par une équipe séparée. Une erreur subtile a introduit des IP tunnel dupliquées pour quelques clients.
Dans WireGuard, AllowedIPs ne sont pas juste « ce qui route vers le peer ». C’est aussi la façon dont WireGuard décide quel peer doit recevoir des paquets.
Les doublons créent le chaos. Pas toujours immédiatement. Le pire type.

Là où les pratiques ennuyeuses ont porté leurs fruits : leur job d’audit a rapidement signalé les doublons.
Leurs logs et snapshots wg show étaient déjà centralisés, si bien que l’astreinte a pu corréler « flaps de peer » et le changement de provisioning.

Ils ont stoppé le provisioning, fait tourner les peers affectés, et récupéré avant que cela ne devienne un incident majeur.
Personne n’a écrit de billet triomphant. Tant mieux. Le résultat n’a pas été une « récupération héroïque ». Le résultat a été « les clients n’ont rien remarqué ».

En exploitation, l’ennuyeux est une fonctionnalité. L’excitation est un indicateur avancé de futures paperasseries.

Listes de contrôle / plan pas à pas

Pas à pas : Déployer WireGuard pour des mobiles en roaming

Choisir le modèle de routage : split tunnel sauf raison réelle pour tunnel complet.
Attribuer un sous‑réseau tunnel stable : par ex. 10.6.0.0/24, un /32 par appareil.
Assurer l’unicité : clé unique par appareil ; IP tunnel unique par appareil ; pas de « clé mobile » partagée.
Définir un MTU conservateur : commencer à 1280 pour des déploiements mobiles ; augmenter uniquement après tests LTE.
Activer keepalive pour les clients derrière NAT : commencer à 25 secondes, ajuster selon timeouts et impact batterie.
Rendre les règles pare‑feu explicites : autoriser UDP vers le port WireGuard ; journaliser les drops pendant le déploiement.
Activer forwarding et routes : ne comptez pas sur le NAT sauf si nécessaire ; si tunnel complet, configurez le NAT intentionnellement.
Décider du comportement DNS : si DNS à l’intérieur, garantir la joignabilité du résolveur et l’intégration client.
Tester le roaming en conditions réelles : Wi‑Fi → LTE, LTE → Wi‑Fi, veille/réveil, tethering, portails captifs.
Instrumenter les bases : stocker des snapshots périodiques wg show, âges de handshake, stats d’interface ; alerter sur « handshake never » pour utilisateurs actifs.

Checklist opérationnelle : Quand quelqu’un rapporte « VPN se déconnecte sur mobile »

Le serveur reçoit‑il de l’UDP pendant la fenêtre d’échec ? (tcpdump)
Les timestamps de handshake avancent‑ils ? (wg show)
L’endpoint change‑t‑il quand l’utilisateur roame ? (wg show endpoints)
Le keepalive est‑il configuré côté NATé ? (wg showconf)
Pouvez‑vous pinguer par IP via le tunnel ? (ping vers IP tunnel / IP interne)
Les résolutions DNS réussissent‑elles via le DNS VPN ? (resolvectl / dig)
Baisser le MTU corrige‑t‑il les gros transferts ? (ip link + ping -M do)
Y a‑t‑il des AllowedIPs dupliqués ou des IP tunnel dupliquées ? (audit de config)

Blague #1 : Si votre plan de dépannage commence par « réinstaller l’app VPN », vous faites essentiellement un on/off avec des étapes supplémentaires.

FAQ

1) Est‑ce que le roaming WireGuard signifie que je n’ai pas besoin de keepalives ?

Non. Le roaming gère les changements d’endpoint quand des paquets circulent. Les keepalives gèrent les timeouts NAT d’inactivité pour que les paquets puissent recirculer quand vous reprenez l’activité.
Si votre client reste inactif derrière un NAT, le keepalive fait souvent la différence entre « stable » et « mystérieusement mort ».

2) Pourquoi mon client WireGuard affiche « connecté » quand rien ne fonctionne ?

Parce que « connecté » signifie souvent « l’interface existe et la config est chargée », pas « des paquets circulent actuellement ».
Vérifiez latest handshake. S’il est ancien, vous n’êtes pas vraiment connecté. S’il est récent, regardez MTU, routes et DNS.

3) Quelle est une bonne valeur PersistentKeepalive pour les téléphones ?

Commencez à 25 secondes. Si vous observez des coupures d’inactivité plus courtes, baissez la valeur. Si l’impact batterie est problématique et que vos réseaux sont tolérants, augmentez prudemment.
Ne la mettez pas aveuglément à 0 en espérant que les opérateurs respectent vos objectifs de disponibilité.

4) WireGuard se reconnecte‑t‑il plus vite qu’IPsec/IKE en roaming ?

Souvent, oui—parce qu’il n’exige pas une renégociation lourde juste pour accepter un nouvel endpoint.
Mais la perception utilisateur dépend aussi du DNS, du MTU, et de la capacité des applications à retenter. WireGuard enlève un gros obstacle ; il ne refait pas toute la route.

5) Changer de réseau en plein SSH casse encore ma session ?

Cela peut arriver. WireGuard peut maintenir le tunnel, mais les sessions TCP peuvent se réinitialiser si des paquets sont perdus ou si des middleboxes suppriment l’état.
Utilisez mosh pour des shells distants quand vous attendez du roaming, ou assurez‑vous que le chemin réseau n’implique pas d’appareils stateful qui paniquent au changement.

6) Dois‑je faire tourner WireGuard sur le port 53/123/443 pour « passer à travers les réseaux » ?

Évitez‑le sauf si vous avez une exigence claire et testée. Déguiser le port peut entrer en conflit avec de vrais services, déclencher du filtrage, et compliquer le débogage.
Si vous avez besoin d’une traversée fiable, résolvez‑le par une politique réseau appropriée ou un port autorisé connu — pas en vous faisant passer pour le DNS.

7) Pourquoi certaines plages IP internes posent problème sur le Wi‑Fi public ?

Chevauchement d’espaces privés. Si votre entreprise route 10.0.0.0/8 via le VPN et que l’hôtel utilise aussi 10.0.0.0/8 localement,
vous avez créé une bagarre de routage. Raffinez vos AllowedIPs ou renumérotez.

8) Le MTU est‑il vraiment si courant comme cause de problème avec WireGuard ?

Oui. Surtout sur mobile. Le roaming change le chemin sous‑jacent, et la découverte automatique du MTU n’est pas fiable sur tous les réseaux.
Si de gros transferts stagnent ou que quelques sites chargent et d’autres non, le MTU est un suspect majeur.

9) WireGuard supporte‑t‑il des « serveurs multi‑endpoint » pour la redondance ?

Pas dans le sens de lister plusieurs endpoints pour un même peer. Vous pouvez bâtir la redondance avec DNS, anycast, outils de basculement, ou tunnels multiples,
mais WireGuard lui‑même attend un endpoint courant par peer qui s’actualise au fil des apprentissages.

10) WireGuard est‑il « sans état » ?

Non. Il garde de l’état pour les peers : clés, compteurs, endpoints, handshake time. Il est juste moins cérémonieux que beaucoup de VPN.
L’essentiel est que l’état s’actualise rapidement et en sécurité lorsque l’endpoint change.

Blague #2 : Les dispositifs NAT ont deux hobbies : expirer les mappings UDP et vous enseigner l’humilité.

Prochaines étapes réalisables cette semaine

Si vous voulez moins de tickets VPN mobiles et moins de plaintes « ça s’est re‑déconnecté », faites ceci dans l’ordre :

Mesurez la santé des handshakes : collectez les âges de handshake wg show pour les utilisateurs actifs ; alertez sur « never » ou handshakes périmés pendant les heures ouvrables.
Standardisez le keepalive pour le mobile : définissez PersistentKeepalive pour les clients derrière NAT, et documentez les déviations par profil.
Fixez un MTU conservateur de base : choisissez 1280 pour mobile‑first ; n’augmentez qu’après tests LTE réels.
Rendez le comportement DNS explicite : possédez le DNS à l’intérieur du tunnel ou cessez de promettre des noms internes hors‑réseau.
Auditez les configurations peer : détectez clés et AllowedIPs dupliqués ; faites tourner tout élément suspect immédiatement.
Entraînez la méthode de diagnostic rapide : tcpdump → handshake → MTU/DNS/routage. Répétez‑la jusqu’à en faire un réflexe.

Le roaming WireGuard est la solution qui élimine toute une catégorie de déconnexions VPN mobiles.
Mais vous devez continuer à l’exploiter comme un système de production : mesurer, tester sur des réseaux hostiles, et garder vos configurations volontairement ennuyeuses.