VPN en 4G : pourquoi le tunnel se connecte mais rien ne charge

13 juillet 2026 · 6 min de lecture

C'est l'un des bugs les plus déroutants du monde des VPN, et l'un des plus mal documentés. Votre tunnel WireGuard fonctionne parfaitement en Wi-Fi. Vous sortez de chez vous, vous passez en 4G : le VPN affiche « connecté », la poignée de main réussit, les octets circulent… et pourtant les pages ne s'affichent pas. Ou, plus troublant encore : les petites pages passent, les grosses non.

Rien n'est cassé. C'est une histoire de taille de paquets.

Le MTU, en deux minutes

Chaque paquet qui circule sur un réseau a une taille maximale, le MTU (Maximum Transmission Unit). Sur une ligne fixe ordinaire, c'est 1500 octets. Tout ce qui dépasse doit être découpé.

Un VPN ajoute une enveloppe autour de chaque paquet : en-têtes de chiffrement, adresses du tunnel. Cette enveloppe pèse une soixantaine d'octets avec WireGuard. Un paquet de 1500 octets qui entre dans le tunnel en ressort donc à environ 1560 : trop gros pour la ligne. Il faut le découper — et c'est là que les ennuis commencent.

Pourquoi la 4G aggrave tout

Sur une ligne fixe, le découpage se passe en général bien. Sur un réseau mobile, deux choses se conjuguent :

• Les opérateurs mobiles utilisent souvent un MTU inférieur à 1500 (encapsulation GTP, tunnels internes de l'opérateur…). Le budget réel est parfois de 1400 octets, parfois moins.
• Beaucoup de réseaux mobiles bloquent les messages ICMP qui servent normalement à dire « ton paquet est trop gros, renvoie-le plus petit ». Le mécanisme d'ajustement automatique (Path MTU Discovery) est donc aveugle.

Résultat : vos gros paquets partent, se perdent en silence, et personne ne vous prévient. Les échanges légers (une poignée de main, une requête DNS, une petite page) passent ; dès qu'une réponse dépasse la taille critique — une image, un flux vidéo, une page moderne — elle disparaît dans le vide. D'où l'impression absurde d'un VPN « connecté mais mort ».

Le diagnostic en une commande

Avec le VPN actif, envoyez des paquets de taille décroissante, sans autoriser la fragmentation. Sous Linux :

ping -M do -s 1400 1.1.1.1

Si ça échoue (« Frag needed » ou aucune réponse), réessayez avec -s 1300, -s 1200… La plus grande valeur qui répond, plus 28 octets (en-têtes IP + ICMP), vous donne le MTU réellement praticable. Sous Windows : ping -f -l 1400 1.1.1.1.

Si le tunnel répond en dessous d'une certaine taille et jamais au-dessus : le diagnostic est confirmé.

La solution, en une ligne

Dans la section [Interface] de votre fichier de configuration WireGuard :

MTU = 1280

Pourquoi 1280 ? Parce que c'est le minimum garanti par la norme IPv6 : tout réseau au monde doit savoir acheminer un paquet de cette taille. C'est la valeur qui passe partout, y compris sur les 4G les plus capricieuses. Vous perdez quelques pour cent d'efficacité théorique ; vous gagnez un VPN qui fonctionne réellement en mobilité.

Sous NetworkManager, si le profil est déjà importé : sudo nmcli connection modify mon-vpn wireguard.mtu 1280

Et avec OpenVPN ?

Le même problème existe, avec d'autres mots. Les réglages utiles : tun-mtu 1400, et surtout mssfix 1300, qui demande aux connexions de négocier des segments plus petits. Nous avons vécu exactement cela sur un ancien serveur : sans mssfix, le VPN était inutilisable en 4G.

La morale

Ce réglage devrait être livré d'office par tout fournisseur sérieux. Il ne l'est presque jamais : la plupart des configurations distribuées sur Internet ne contiennent aucune ligne MTU, et des milliers d'utilisateurs en concluent que « le VPN ne marche pas sur mon téléphone ».

Chez VPN Paris, toutes les configurations que nous générons contiennent MTU = 1280, sur toutes les plateformes. Pas parce que nous sommes plus malins : parce que nous avons perdu une semaine dessus, et que nous préférons vous l'épargner.