Pourquoi WireGuard peut-il rester en boucle sur une Proximus TV Box alors qu’OpenVPN fonctionne ? Le protocole le plus rapide n’était pas le bon critère

OpenVPN venait de fonctionner.

C’est précisément ce qui m’agaçait.

Pendant les vingt minutes précédentes, le même VPN était resté en boucle sur ma Proximus TV Box: je choisissais une localisation, l’animation de connexion démarrait, tournait, puis continuait à tourner comme si la télécommande avait cessé d’exister.

J’avais changé de serveur.

Redémarré l’application.

Redémarré la TV Box.

Puis désinstallé et réinstallé le VPN.

Même boucle.

Par curiosité, j’avais finalement ouvert les paramètres avancés et remplacé le mode automatique par OpenVPN.

Connexion.

Quelques secondes.

Connecté.

L’application vidéo que je voulais utiliser s’est ouverte.

Pendant un instant, j’ai considéré l’affaire comme réglée.

Puis une question beaucoup plus intéressante m’est venue: si mon compte, le serveur, ma connexion Proximus et la TV Box fonctionnaient tous, qu’est-ce qu’OpenVPN venait de changer que WireGuard n’arrivait pas à faire ?

La TV Box ressemble à un appareil Android normal — jusqu’au moment où le réseau entre en jeu

Proximus présente sa TV Box actuelle comme une plateforme Android capable d’exécuter des applications et d’intégrer Chromecast. L’opérateur a aussi progressivement remplacé d’anciens décodeurs par des modèles Android V7 et V7c.

C’est justement ce qui rend mon raisonnement initial si naturel.

Si je peux installer Netflix, YouTube et d’autres applications Android sur la box, pourquoi un VPN ne se comporterait-il pas comme sur mon téléphone ?

Parce qu’un VPN ne se contente pas d’afficher une application supplémentaire.

Sous Android, il crée une interface réseau virtuelle et récupère le trafic que le système lui confie avant de l’envoyer dans son tunnel.

En pratique, c’est un peu comme si l’application installait temporairement une nouvelle sortie derrière la TV Box.

Si cette sortie ne s’établit pas correctement, l’application peut rester bloquée sur « Connexion… » alors que la box elle-même continue à avoir Internet.

Autrement dit, la roue qui tournait devant moi ne prouvait pas que la TV Box était cassée.

Elle disait surtout que le tunnel n’arrivait pas jusqu’à son état utilisable.

Et puisque OpenVPN venait de fonctionner sur le même appareil, je pouvais déjà réduire fortement le nombre de suspects.

Le fait qu’OpenVPN fonctionne changeait complètement le diagnostic

WireGuard transporte son trafic en UDP.

OpenVPN peut utiliser UDP, mais aussi TCP. Sa documentation explique justement que TCP peut être utile lorsque le chemin réseau laisse mal passer certains flux UDP; TCP 443 présente en plus l’avantage de ressembler davantage au trafic HTTPS ordinaire du point de vue du port utilisé.

Je n’avais donc plus besoin de soupçonner vingt choses à la fois.

Le compte fonctionnait.

La connexion Internet fonctionnait.

La TV Box savait faire fonctionner un VPN.

Le serveur était joignable par une autre méthode.

Ce qui changeait était surtout la manière dont le tunnel essayait de traverser le réseau.

Et je n’étais visiblement pas le premier à tomber sur ce comportement.

Sur le forum Proximus, un utilisateur de TV Box V7 racontait que CyberGhost avait fonctionné pendant des mois avant de se mettre à boucler au moment de la connexion. Réinstallation: aucun changement. Après plusieurs essais, le passage forcé à OpenVPN au lieu du mode utilisant WireGuard avait rétabli la connexion. Un autre utilisateur signalait un comportement comparable.

Ce témoignage ne permet pas de conclure que Proximus « bloque WireGuard ».

Il montre quelque chose de plus utile: sur cette combinaison TV Box, application et réseau, changer de transport peut suffire à faire passer une connexion qui restait jusque-là bloquée.

C’était exactement ce que je venais d’observer.

J’ai failli conclure trop vite que « Proximus bloque l’UDP »

Le raisonnement semblait presque parfait.

WireGuard utilise UDP.

OpenVPN fonctionne.

Donc UDP est bloqué.

Fin de l’enquête.

Sauf que cette conclusion allait tomber quelques minutes plus tard.

En attendant, j’avais au moins une solution fonctionnelle.

J’ai laissé OpenVPN activé et lancé le programme.

L’image est apparue.

Le son aussi.

Je me suis assis.

Puis j’ai avancé de quelques minutes.

Chargement.

Reprise.

Un peu plus tard, nouvelle hésitation.

Ce n’était pas inutilisable. Et OpenVPN avait déjà rendu un vrai service: il m’avait sorti immédiatement de la boucle WireGuard.

Mais mon problème n’était plus exactement celui du début.

Je ne cherchais plus seulement un protocole capable d’afficher « Connecté ».

Je voulais arrêter de retourner dans les paramètres chaque fois que la combinaison par défaut décidait de ne plus passer.

C’est là que mon critère de comparaison a changé.

Je n’ai pas cherché un « WireGuard encore plus rapide »

Mon premier réflexe aurait normalement été de chercher un autre fournisseur connu pour ses performances avec WireGuard.

Mais cela aurait répondu à la mauvaise question.

Le problème devant moi n’était pas que WireGuard manquait de débit.

Il n’arrivait même pas jusqu’au moment où le débit pouvait devenir intéressant.

Quelques dizaines de mégabits supplémentaires dans un benchmark n’avaient aucune valeur pendant que l’écran continuait à tourner.

J’ai donc essayé la petite application utilisée pour les tests de cet article sur une TV Box compatible.

Au lieu d’ouvrir une liste de protocoles et de recommencer mes essais, j’ai choisi le mode destiné au streaming et lancé la connexion.

Puis j’ai quitté immédiatement l’application.

Accueil.

Programme.

Play.

L’image est partie.

J’ai avancé dans la lecture.

Reprise.

J’ai changé de programme.

Lecture.

Puis j’ai mis la TV Box en veille quelques instants, rallumé l’écran et repris.

Toujours là.

Ce n’était pas la comparaison que j’avais imaginée au départ.

Je pensais comparer WireGuard à OpenVPN.

J’étais finalement en train de comparer le nombre de fois où je devais quitter ce que je regardais pour m’occuper du VPN.

Et à ce moment-là, la petite application commençait à résoudre un problème plus intéressant que la vitesse brute.

HTTP/3 m’a surtout empêché de raconter la mauvaise histoire

Le service utilise dans ce mode un transport basé sur HTTP/3 avec une couche supplémentaire d’obfuscation.

C’est là que mon hypothèse « l’UDP est bloqué » a cessé de tenir.

HTTP/3 repose sur QUIC, et QUIC transporte lui aussi ses paquets sur UDP.

Si tout trafic UDP avait simplement été refusé, voir ce transport fonctionner aurait été difficile à expliquer.

La situation était donc plus fine:

WireGuard échouait dans cette configuration.

OpenVPN passait.

Le transport HTTP/3 de la petite application passait également.

Le problème n’était donc pas « UDP contre TCP » de manière absolue.

C’était plutôt la forme concrète du trafic et la manière dont chaque tunnel traversait le chemin entre la TV Box et son serveur.

Je pouvais comparer cela à trois véhicules essayant de franchir le même contrôle.

Le premier se présente d’une manière qui pose problème.

Le deuxième passe par une autre voie.

Le troisième utilise encore une autre forme de transport.

Ce qui compte depuis mon canapé n’est pas que leurs moteurs soient construits différemment.

C’est de savoir lequel franchit réellement la barrière.

Je pouvais évidemment pousser le diagnostic plus loin: capture de paquets, comparaison de ports, plusieurs implémentations WireGuard, tests depuis un routeur intermédiaire.

Mais à ce stade, cela n’aurait plus amélioré mon expérience devant la télévision.

Le programme était déjà en train de jouer.

OpenVPN n’avait pas perdu — il m’avait montré ce qui comptait vraiment

Au début de la soirée, lorsque OpenVPN s’était connecté, j’avais pensé:

« Voilà. WireGuard est le problème et OpenVPN est la solution. »

Après les essais suivants, mon verdict était différent.

OpenVPN avait joué le rôle du test décisif.

Il avait prouvé que la TV Box pouvait établir un VPN et que continuer à changer aveuglément de serveur WireGuard n’avait probablement aucun intérêt.

C’était précieux.

Mais une fois ce diagnostic obtenu, mon besoin était devenu plus simple:

je voulais lancer une connexion et revenir à la vidéo.

Avec le premier fournisseur, je disposais d’une boîte à outils très complète: plusieurs protocoles, beaucoup de serveurs, davantage de réglages et suffisamment d’ancienneté pour trouver énormément de documentation publique.

Avec la petite application, j’avais moins de décisions à prendre.

Sur cette TV Box, c’était exactement ce que je voulais.

Elle propose aussi moins de régions de sortie et possède moins d’historique public et d’avis indépendants que les grands fournisseurs établis. Si mon objectif était de choisir précisément parmi de nombreux pays ou de contrôler manuellement chaque protocole, cette différence compterait.

Devant cette TV Box, ce n’était pas ce qui me faisait perdre du temps.

Ce qui me faisait perdre du temps était la roue qui tournait.

Ce que je testerais d’abord la prochaine fois

Je ne commence plus par demander quel VPN devrait être le plus rapide avec WireGuard.

Je lance celui que j’ai déjà.

S’il reste bloqué en mode automatique ou WireGuard, je force OpenVPN une fois.

S’il se connecte immédiatement, j’ai déjà appris quelque chose d’important: la TV Box, le compte et la connexion Internet savent fonctionner; c’est la manière dont le premier tunnel traverse le réseau qui pose problème.

Ensuite seulement, je juge ce que je voulais réellement faire.

L’application vidéo s’ouvre-t-elle ?

Le programme démarre-t-il ?

Puis-je avancer, changer de vidéo, mettre la box en veille et revenir sans repartir dans les réglages ?

C’est ce test qui a séparé mes deux solutions.

OpenVPN m’a sorti de la boucle.

La petite application m’a évité d’y retourner.

Et c’est finalement ce que cette Proximus TV Box m’a appris: lorsque WireGuard tourne encore pendant que le film attend, le meilleur protocole n’est pas celui qui gagne sur le papier.

C’est celui qui me ramène jusqu’au bouton Play sans me renvoyer une nouvelle fois dans Paramètres.