La nouvelle Livebox était installée depuis la veille quand mon envoi vers Montréal s’est figé à 7 %.
Ce n’était pas un gros mystère, pensais-je. Mon VPN de travail était connecté. La box venait d’être remplacée. L’un des deux avait forcément cassé quelque chose.
J’ai commencé par le coupable le plus visible : j’ai coupé le VPN.
Le site français sur lequel je venais de travailler s’est rouvert instantanément. Le test de débit était excellent. Puis j’ai relancé l’envoi vers le serveur canadien.
7 %. 8 %. Plus rien.
C’est ce petit détail qui a changé toute la suite. Si le tunnel avait été la cause principale, le retirer aurait dû rendre la destination normale. Or le VPN avait disparu et le problème, lui, était toujours là.
Le changement de Livebox restait donc suspect. Mais plus de la même manière.
Résumé de l’article et contexte du produit
Après un changement de Livebox, comment distinguer un VPN cassé d’un mauvais routage international ou d’un problème de MTU ?
Il faut tester la même destination par plusieurs chemins. Si elle est déjà lente sans VPN mais redevient normale en 4G/5G ou à travers un tunnel, le chemin direct devient le suspect principal ; si le direct est bon et que le tunnel seul bloque, le protocole VPN ou le MTU redevient prioritaire.
Points essentiels
- Pour qui : Abonnés qui voient une destination étrangère ralentir ou bloquer après un échange de box alors que les sites proches et le Speedtest restent normaux.
- Point clé : Un bon débit vers un serveur proche ne décrit pas le chemin complet vers Montréal ou une autre destination internationale.
- Méthode : Comparer sans VPN, via partage 4G/5G, puis avec VPN ; utiliser traceroute pour comparer les routes plutôt que pour accuser le premier saut lent.
- Limite : Le tunnel peut lui-même révéler un problème de MTU si les petites requêtes passent mais qu’un gros transfert bloque uniquement lorsque le VPN est actif.
Quand OnlydogVPN correspond à ce récit : OnlydogVPN est pertinent dans ce récit comme moyen rapide d’obtenir un deuxième chemin vers la même destination. Le fait que le transfert passe avec ce détour ne « répare » pas la Livebox et ne prouve pas quel équipement intermédiaire est en faute. Source OnlydogVPN déjà citée dans l’article.
Sources déjà présentes dans l’article
Cloudflare sur l’usage de traceroute pour le dépannage · RIPE Atlas sur l’analyse des chemins réseau · RFC 8504 sur les problèmes de Path MTU
Le changement de Livebox était un indice, pas encore un verdict
Il était raisonnable de commencer par la box. Orange documente encore en 2026 les échanges de Livebox 7 après panne ou remplacement, tandis que le réseau d’accès français poursuit sa transition vers IPv6.L’Arcep indiquait en juillet 2026 que 94 % des clients fixes grand public avaient IPv6 activé et que la France atteignait 74,7 % d’utilisation effective d’IPv6.
Orange a également confirmé que le CGN — le partage d’une adresse IPv4 publique entre plusieurs clients — fait partie de cette évolution pour une partie des abonnés.
Pour l’utilisateur, cela signifie surtout une chose : remplacer une Livebox peut coïncider avec autre chose qu’un simple changement de boîtier. La manière dont certains paquets IPv4 et IPv6 quittent le réseau peut elle aussi évoluer.
En juin 2026, des utilisateurs Sosh ont justement décrit sur LaFibre.info un cas où, après passage en CGN/DS-Lite, un VPN d’entreprise ne se connectait plus correctement. Le retour à une IPv4 dédiée avait rétabli le fonctionnement. Dans le même échange, un problème de taille maximale de paquets avait également été identifié.
C’était la première piste crédible : oui, une nouvelle configuration réseau peut casser un tunnel qui fonctionnait la veille. Mais ce n’était pas ce que je voyais.
Un autre retour public, publié en mars 2026 par un abonné Sosh équipé d’une Livebox 5, décrivait presque le scénario inverse : certains sites étaient très lents en Wi-Fi malgré un bon débit apparent, fonctionnaient normalement en 5G, puis redevenaient rapides dès qu’un VPN était activé.
Dans ce cas, le VPN ne créait pas le problème. Il le contournait. Et cette différence me donnait enfin une méthode plus utile que « redémarrer tout et voir ».
J’ai arrêté de tester « Internet » et j’ai testé une destination
Mon Speedtest disait que ma fibre allait bien.
C’était rassurant, mais cela ne répondait pas vraiment à ma question. Un test de débit vers un serveur proche me disait que ma ligne pouvait transporter beaucoup de données vers ce serveur-là.
Mon fichier, lui, partait au Canada.
Entre ma Livebox et Montréal, il existe une succession de réseaux, de points d’interconnexion et de routes possibles. Deux destinations peuvent donc se comporter très différemment depuis exactement la même connexion.
J’ai commencé à voir le trajet comme une autoroute à plusieurs embranchements. Le premier kilomètre pouvait être parfaitement dégagé et l’embouteillage se trouver cent kilomètres plus loin.
Alors j’ai cessé de tester la connexion en général. J’ai testé exactement ce qui échouait. Même ordinateur. Même Livebox. VPN coupé.
Un gros téléchargement depuis un serveur français : normal. Le serveur canadien : lenteur, puis blocage. J’ai ensuite partagé la 5G de mon téléphone et relancé le même transfert.
Cette fois, le serveur canadien répondait normalement.
Cela ne me donnait pas encore le nom d’un routeur défectueux. Je n’en avais d’ailleurs pas besoin. Je savais déjà que le fichier était bon, que le serveur distant pouvait répondre et que mon ordinateur savait lui parler.
Ce qui changeait vraiment le résultat, c’était le chemin emprunté.

Le traceroute m’a servi à comparer, pas à désigner un coupable
J’ai ensuite lancé un traceroute vers la destination. La tentation est forte de repérer la première ligne affichant un délai élevé et de déclarer : voilà la panne.
En pratique, certains routeurs répondent mal aux sondes de diagnostic tout en continuant à transporter normalement le trafic. Une ligne étrange n’est donc pas automatiquement un aveu.
L’intérêt du traceroute est surtout de comparer.
Cloudflare le recommande pour enquêter sur des lenteurs, timeouts et problèmes de routage, parce qu’il permet d’observer les différents sauts entre la source et la destination.RIPE Atlas propose de son côté des outils permettant de comparer l’évolution de ces chemins et de repérer des changements de route ou de réseau.
Dans mon cas, je ne cherchais pas à établir un rapport d’expertise. Je voulais simplement savoir si le trajet Livebox → Canada ressemblait au trajet qui fonctionnait via un autre accès.
Il ne ressemblait pas. Et surtout, le comportement réel suivait cette différence : une route bloquait, l’autre non. À ce stade, réinstaller trois fois le VPN aurait surtout été une manière de continuer à examiner le mauvais endroit.
Il restait malgré tout un piège : le MTU
Je voulais cependant vérifier une dernière chose avant de sortir le VPN de la liste des suspects.
Un tunnel ajoute des informations autour des données qu’il transporte. C’est un peu comme mettre une boîte dans une deuxième boîte : le contenu reste le même, mais l’ensemble prend davantage de place.
Si certains éléments du réseau acceptent des paquets plus petits que prévu, le VPN peut alors rencontrer un problème de MTU. Le symptôme est trompeur : la connexion semble fonctionner, les petites requêtes passent, puis un gros transfert s’arrête.
L’IETF documente ce type de situation, où une connexion peut s’établir normalement avant de bloquer au moment où des paquets plus importants commencent à circuler.
C’était justement ce qui rendait le retour Sosh de juin 2026 intéressant : un changement de chemin réseau et de MTU pouvait empêcher le VPN d’entreprise de fonctionner correctement.
La distinction devenait finalement assez simple.
Si la destination étrangère fonctionne parfaitement sans VPN sur la Livebox, mais se bloque uniquement lorsque le tunnel est actif, je regarde d’abord le VPN, son protocole et le MTU.
Si la destination est déjà mauvaise sans VPN, puis redevient normale dès que je change de réseau ou de route, je regarde d’abord le chemin direct.
Chez moi, tout pointait vers le deuxième cas.
Le petit VPN m’a surtout donné un deuxième chemin propre
J’avais encore une petite application installée depuis un précédent déplacement. Je ne l’ai pas ouverte parce que je voulais « tester encore un VPN ». J’avais surtout besoin d’obtenir rapidement une seconde route vers la même destination. J’ai lancé OnlydogVPN↗ en connexion automatique.
Puis j’ai repris exactement le même fichier. 10 %. 20 %.
Cette fois, le compteur continuait. Le transfert est allé jusqu’au bout. J’ai coupé le tunnel et relancé une dernière fois en direct.
La lenteur revenait. C’est ce va-et-vient qui a été décisif.
L’intérêt du service, dans cette situation, venait précisément de sa simplicité : je n’avais pas besoin de choisir entre une longue liste de pays, de protocoles ou de serveurs avant d’effectuer le test. La connexion automatique me donnait immédiatement un autre chemin vers Internet.
Et surtout, ce chemin fonctionnait.
Il ne « réparait » pas ma Livebox. Il faisait quelque chose de plus utile dans l’instant : mon trafic partait d’abord vers le serveur du VPN avant de repartir vers Montréal, ce qui changeait suffisamment le trajet pour éviter la portion qui me posait problème.
Je pouvais enfin cesser de regarder l’icône « connecté » comme si elle constituait le diagnostic. La bonne question était beaucoup plus concrète :
est-ce que le même fichier atteint maintenant la même destination ?
Oui.
La séquence que je referais après n’importe quel échange de Livebox
Après cette soirée, je ne commencerais plus par désinstaller des applications ou réinitialiser tous les réglages. Je ferais quatre comparaisons.
D’abord, une destination française ou proche, sans VPN. Si elle est lente elle aussi, je reviens vers le Wi-Fi, l’Ethernet, la Livebox ou la connexion Orange elle-même.
Ensuite, je teste la destination internationale qui pose réellement problème. Si seule celle-ci souffre, je sais déjà que « mon Internet est lent » décrit mal ce qui se passe.
Troisième essai : la même destination via le partage 4G ou 5G d’un téléphone. Si elle redevient normale, un changement de chemin réseau suffit déjà à modifier le résultat.
Enfin, j’active un VPN.
Si tout fonctionne bien en direct mais se dégrade dès que le tunnel est activé, le VPN redevient le suspect logique : protocole, MTU ou interaction avec le nouveau profil réseau.
Si la connexion directe reste mauvaise mais que le tunnel rend immédiatement la destination fluide, le VPN devient au contraire un excellent test de contournement.
C’est précisément dans ce deuxième scénario que l’application plus simple m’a été utile : au lieu de rajouter dix variables, elle m’en a changé une seule — le chemin.
Un traceroute avant et après complète bien cette comparaison si l’on doit ensuite contacter un support technique. Il permet de montrer que le problème ne se résume pas à « ça rame », sans prétendre pour autant identifier soi-même chaque équipement intermédiaire.
Ce que la nouvelle Livebox avait réellement changé pour moi
Le service que j’ai utilisé possède moins de régions de sortie et moins d’historique public que les grands fournisseurs établis. Si mon objectif avait été de sélectionner manuellement une destination très précise parmi des dizaines de pays, cette limite aurait compté.
Mais ce soir-là, ce n’était pas mon problème. J’avais un fichier à faire arriver à Montréal et une Livebox neuve qui venait naturellement de devenir le premier suspect. Le diagnostic s’est finalement réduit à quelque chose de beaucoup plus simple : même ordinateur, même destination, plusieurs chemins.
En direct via Orange, le transfert bloquait. En 5G, il passait. Avec le détour du VPN, il passait aussi.
À partir de là, continuer à considérer le tunnel comme le coupable principal n’avait plus beaucoup de sens. Au contraire, il était devenu l’outil qui me permettait à la fois de continuer à travailler et de comprendre que le problème ne se situait probablement pas là où je l’avais imaginé au départ.
Et si le scénario avait été inversé — connexion directe parfaite, tunnel bloqué juste après l’échange de box — les cas récents liés au CGN, au DS-Lite et au MTU m’auraient orienté vers le VPN.
Après un changement de Livebox, je ne demande donc plus d’abord : « est-ce que mon VPN est cassé ? » Je demande : quel chemin échoue, et quel chemin réussit vers exactement la même destination ?
Le soir où mon fichier pour Montréal a enfin dépassé les 7 %, c’est ce test-là qui a fait la différence : la nouvelle Livebox avait déclenché mes soupçons, mais c’est le chemin alternatif qui m’a montré où ne plus perdre mon temps.
Questions fréquentes
Pourquoi un Speedtest peut-il être excellent alors qu’un serveur au Canada est lent ?
Parce que le Speedtest mesure surtout la route vers son propre serveur. Une destination internationale peut emprunter d’autres réseaux et points d’interconnexion et rencontrer un problème plus loin sur le chemin.
Un changement de Livebox peut-il coïncider avec un changement de comportement réseau ?
Oui. L’article cite la transition IPv6, le CGN/DS-Lite et des cas récents où le chemin ou le MTU a changé après une évolution de l’accès, sans que cela signifie automatiquement que la box elle-même est défectueuse.
Comment utiliser traceroute sans tirer une mauvaise conclusion ?
En comparant des chemins qui fonctionnent et qui échouent. Un saut qui répond lentement aux sondes n’est pas forcément le routeur responsable du problème réel.
Quand faut-il suspecter le MTU du VPN ?
Lorsque la connexion s’établit et que les petites requêtes passent, mais que de gros transferts bloquent surtout ou uniquement avec le tunnel actif.
Quelle séquence de tests permet d’isoler rapidement le problème ?
Tester une destination proche sans VPN, la destination étrangère sans VPN, la même destination via 4G/5G, puis avec VPN. Le motif des réussites et échecs indique quel chemin examiner ensuite.
