VPN bloqué sur le Wi-Fi Proximus mais fonctionnel en 4G : j’ai changé de transport avant de changer de serveur

Le détail qui m’a empêché de croire que mon VPN était simplement « en panne » tenait à un seul bouton. Sur le Wi-Fi Proximus de l’appartement, l’application restait sur Connexion… J’ai attendu. Annulé. Relancé. Toujours rien. Puis j’ai désactivé le Wi-Fi du téléphone. La 4G a pris le relais.

Même téléphone. Même application. Même compte. Même serveur VPN. Connexion presque immédiate. J’ai remis le Wi-Fi. Bloqué de nouveau. À partir de là, redémarrer encore l’application ne m’apprenait plus rien. Je devais comprendre ce que la connexion fixe faisait différemment.

Le premier test utile n’était pas de changer de serveur

J’avais un fichier de presque 2 Go à envoyer avant de quitter la maison. Le partage 4G aurait pu me dépanner, mais utiliser les données mobiles alors que j’avais une excellente connexion fixe sous la main me paraissait absurde.

J’ai donc commencé sans VPN. Wi-Fi Proximus. Navigateur. Quelques pages. Test de débit. Upload du fichier pendant une minute. Tout fonctionnait normalement. Puis VPN activé. De nouveau : Connexion… Cette séquence très simple éliminait déjà une bonne partie des fausses pistes. Le Wi-Fi fonctionnait.

Internet fonctionnait. Le VPN fonctionnait sur un autre réseau. Ce qui échouait était la rencontre entre ce tunnel précis et ce chemin fixe précis.

C’est une distinction que les incidents récents chez Proximus ont rendue assez concrète. Le 19 mars 2026, l’opérateur a connu sa deuxième panne importante en quelques jours. Proximus a ensuite indiqué qu’un problème technique sur un routeur de son réseau avait perturbé l’accès Internet d’une partie des clients. Ce n’était évidemment pas une preuve que mon problème actuel venait du même équipement. Mais cela rappelait quelque chose d’utile : « Internet Proximus » n’est pas un tuyau abstrait. Entre mon téléphone et un serveur VPN se trouvent des routeurs, des politiques réseau, du DNS, du NAT et plusieurs chemins possibles.

Et il existait déjà un témoignage public presque caricatural de cette différence.

En juillet 2025, un utilisateur du forum Proximus expliquait que certains sites et applications ne fonctionnaient plus chez lui ni en Ethernet ni en Wi-Fi, alors que les mêmes services redevenaient accessibles dès qu’il coupait le Wi-Fi de son smartphone et passait en 5G. Redémarrer la B-box n’avait rien changé ; le problème avait finalement été attribué à un équipement réseau après des travaux planifiés. Autrement dit : 4G oui, connexion fixe non ne signifie pas automatiquement « téléphone cassé », « application cassée » ou même « VPN interdit ».

Cela signifie d’abord : le chemin a changé.

J’ai arrêté de déplacer le tunnel et j’ai changé sa forme

Mon VPN habituel était un grand fournisseur. Beaucoup de serveurs. Une application mature. Plusieurs protocoles. Dans la plupart des situations, c’est plutôt rassurant. J’ai quand même fait l’erreur classique. Serveur Belgique. Échec. Pays-Bas. Échec. France. Échec.

Au troisième essai, j’ai réalisé que je ne modifiais probablement pas la bonne variable. Le tunnel utilisait toujours le même protocole. Je suis donc allé voir ce que l’application avait choisi automatiquement : WireGuard.

WireGuard est conçu autour d’UDP ; sa documentation officielle est très nette sur ce point, puisque ses paquets sont envoyés sur UDP. Cela ne rend pas WireGuard mauvais. Sur la 4G, il venait précisément de fonctionner très bien. Mais si un chemin réseau traite mal ce flux, changer Paris pour Amsterdam tout en conservant exactement le même transport peut simplement reproduire le même échec avec une autre adresse IP.

Mon fournisseur proposait aussi OpenVPN. J’ai choisi sa variante TCP. Connexion. Cette fois, elle est passée. Ce seul résultat valait davantage que mes trois changements de pays.

OpenVPN peut fonctionner sur UDP ou TCP, et sa propre documentation indique que le mode TCP peut servir dans les situations où UDP ne peut pas être utilisé correctement. Je n’avais toujours pas identifié le composant précis qui faisait échouer WireGuard sur cette connexion. Mais je n’en avais plus besoin pour prendre la décision suivante. Le compte n’était pas bloqué. Les serveurs VPN n’étaient pas tous injoignables.

Proximus ne semblait pas couper indistinctement tout trafic VPN.

Changer le transport changeait le résultat.

C’était désormais le test important.

Le contournement fonctionnait, mais je ne voulais pas refaire ce diagnostic chaque fois

Avec OpenVPN TCP, mon fichier a commencé à partir. Le compteur avançait. C’était déjà une solution parfaitement acceptable. Si mon objectif avait uniquement été de résoudre cette panne une fois, j’aurais pu m’arrêter là.

Mais j’avais maintenant une autre irritation : j’avais passé presque vingt minutes à naviguer dans des serveurs et des protocoles pour découvrir manuellement quelle combinaison traversait correctement mon propre Wi-Fi.

C’est à ce moment-là que j’ai ressorti la petite application que je gardais surtout pour les réseaux capricieux.

Je n’ai pas choisi trois pays. Je n’ai pas cherché un port. Je n’ai pas essayé de deviner si la Belgique ou les Pays-Bas avaient la meilleure route. J’ai lancé la connexion. Même Wi-Fi Proximus. Quelques secondes. Connecté. J’ai rouvert l’upload. Le débit est monté.

Puis il est resté suffisamment stable pour que j’arrête enfin de regarder le compteur toutes les trente secondes.

25 %. 51 %. 78 %. 100 %. Le fichier était envoyé. C’était le résultat que je cherchais depuis le début.

HTTP/3 n’est pas une baguette magique — et c’est justement ce qui rendait le test intéressant

L’application utilise un transport fondé sur HTTP/3 avec une couche supplémentaire d’obfuscation. À première vue, j’aurais pu raconter l’histoire trop facilement : « mon premier VPN utilisait UDP, le second utilise HTTP/3, donc HTTP/3 contourne le blocage ».

Ce serait faux. HTTP/3 repose sur QUIC, et QUIC fonctionne lui aussi sur UDP. Le standard HTTP/3 précise même qu’un réseau qui bloque UDP peut empêcher complètement l’établissement d’une connexion QUIC. Le succès du deuxième tunnel m’apprenait donc quelque chose de plus intéressant. Mon Wi-Fi Proximus ne semblait pas simplement rejeter tout UDP. Quelque chose de plus précis distinguait le premier flux du second : port utilisé, signature du protocole, route choisie, traitement intermédiaire ou combinaison de plusieurs de ces éléments.

Je ne pouvais pas voir depuis mon salon lequel était responsable. En revanche, la couche d’obfuscation du second service était directement pertinente dans ce genre de situation : son intérêt est justement d’éviter qu’un tunnel ressemble aussi clairement au trafic VPN classique auquel un réseau peut appliquer un traitement particulier.

Je ne pouvais pas prouver que l’obfuscation, seule, expliquait le résultat. Mais je pouvais prouver ce qui comptait davantage à cet instant : le même Wi-Fi qui refusait mon premier tunnel transportait correctement le second.

J’ai refait le test 4G une dernière fois

Une fois le fichier envoyé, j’aurais normalement fermé l’application. Cette fois, j’ai fait l’inverse. Wi-Fi désactivé. 4G. Une page s’est rechargée. Puis j’ai remis le Wi-Fi Proximus. La connexion a repris sans me demander de sélectionner un autre serveur ou de relancer manuellement le tunnel.

C’était un avantage plus petit, mais directement lié au problème qui m’avait amené là.

QUIC a notamment été conçu pour mieux supporter certains changements de chemin et d’adresse réseau grâce à ses identifiants de connexion. Cela ne garantit pas qu’un VPN survivra à chaque transition Wi-Fi–4G, mais le mécanisme existe précisément pour éviter qu’un changement de réseau signifie systématiquement repartir de zéro. Dans mon test, le résultat était très simple : Wi-Fi, 4G, retour au Wi-Fi, et je n’avais plus besoin de m’occuper du VPN.

C’était une bonne raison de conserver l’application après avoir terminé l’upload.

Ce que je testerais maintenant, dans cet ordre

Si le même VPN fonctionne en 4G mais reste bloqué uniquement sur un Wi-Fi Proximus, je ne commencerais plus par parcourir dix serveurs.

Je couperais d’abord le VPN tout en restant sur le Wi-Fi. Si Internet fonctionne normalement, la ligne elle-même n’est probablement pas le premier problème.

Je réactiverais ensuite exactement le même VPN sur la 4G. S’il se connecte, l’application, le compte et au moins cette route VPN savent encore fonctionner.

À partir de là, je regarderais où l’échec se produit. Si l’application reste sur « Connexion… », je testerais en priorité un autre transport ou protocole : WireGuard vers OpenVPN TCP, par exemple, si le fournisseur le permet.

Si le VPN affiche déjà « Connecté » mais que certaines pages seulement ne chargent plus, je déplacerais le diagnostic vers le DNS, le routage ou la taille des paquets avant d’accuser le protocole lui-même.

Et je ne redémarrerais la box qu’une fois. Si le même contraste Wi-Fi/4G revient immédiatement après, répéter cinq fois le redémarrage ne crée pas une nouvelle information.

C’est seulement après cela que je testerais un second VPN utilisant réellement un autre transport ou une couche d’obfuscation.

Pas parce qu’un service plus petit serait automatiquement meilleur qu’un acteur installé.

Celui que j’ai utilisé ici possède moins de régions, une histoire publique plus courte et nettement moins d’avis indépendants que les grands fournisseurs. Pour choisir manuellement des sorties dans beaucoup de pays, je préférerais encore l’infrastructure plus large.

Mais ce n’était pas mon problème ce soir-là. J’avais déjà beaucoup de serveurs. Ce qu’il me manquait était une façon différente de traverser le réseau sur lequel j’étais déjà connecté.

Mon premier fournisseur m’a finalement donné une issue grâce à son mode TCP, mais après plusieurs manipulations. La seconde application a rendu le même Wi-Fi utilisable avec un tunnel différent, puis a continué à fonctionner quand j’ai refait le passage 4G–Wi-Fi.

C’est ce qui a changé mon critère. Quand un VPN fonctionne en 4G mais pas sur mon Wi-Fi Proximus, je ne demande plus d’abord quel serveur essayer.

Je demande quelle forme de tunnel ce réseau laisse réellement sortir. Ce soir-là, ce n’était pas une autre destination qui manquait à mon VPN : c’était un autre moyen de franchir ma propre box.