Quel VPN choisir quand OpenVPN TCP passe mais que les tunnels UDP échouent ? Avant de rester en TCP, il faut comprendre ce que le réseau filtre vraiment

J’avais déjà résolu le problème.

C’est du moins ce que je croyais.

Sur le Wi-Fi invité du centre où je travaillais pour la journée, mon VPN habituel refusait obstinément son mode WireGuard.

J’ai essayé OpenVPN UDP.

Échec.

Puis OpenVPN TCP sur le port 443.

Connexion.

Le portail de travail s’est ouvert immédiatement.

Ma messagerie s’est synchronisée.

J’ai presque refermé les réglages avec cette petite satisfaction qu’on ressent lorsqu’on vient enfin de trouver la bonne case à cocher.

UDP était filtré. TCP fonctionnait. Affaire réglée.

Puis j’ai lancé la visioconférence.

La voix est arrivée.

Le partage d’écran aussi.

Et quelques minutes plus tard, tout est devenu lourd.

L’image se figeait par petites touches. Un dossier envoyé dans le cloud avançait, s’arrêtait, repartait. Les pages web fonctionnaient, mais cette connexion que je venais de déclarer « gagnante » donnait l’impression de travailler avec un élastique attaché au réseau.

OpenVPN TCP avait franchi la porte.

Je commençais à me demander si j’avais vraiment envie de passer toute la journée derrière.

TCP 443 était un excellent plan B — pas forcément le résultat que je cherchais

Ce genre de problème est facile à rencontrer lorsqu’on travaille en déplacement, entre réseaux invités, hôtels, salons et infrastructures publiques. Rien qu’en juillet 2026, Paris Aéroport a accueilli un peu plus de 10,1 millions de passagers.

Sur ces réseaux administrés, TCP 443 possède un avantage évident.

C’est le port normalement utilisé par HTTPS. Le bloquer sans distinction reviendrait à casser une grande partie du Web.

OpenVPN privilégie UDP pour les performances, mais prévoit TCP comme solution de compatibilité lorsque le réseau filtre le trafic nécessaire au tunnel. Son Access Server utilise notamment TCP 443 pour ce type de situation.

C’était exactement ce que j’avais sous les yeux.

WireGuard ne passait pas.

OpenVPN UDP non plus.

TCP 443 passait.

Mais OpenVPN documente également le compromis derrière cette solution : transporter du trafic TCP dans un tunnel lui-même basé sur TCP peut provoquer ce qu’il appelle le « TCP meltdown ». Lorsqu’il y a des pertes ou des ralentissements, les deux couches peuvent chercher à récupérer les mêmes problèmes, et les délais s’accumulent.

L’image qui m’est restée est celle d’une sortie de secours.

Elle est excellente quand la porte principale est fermée.

Cela ne signifie pas que j’ai envie d’y installer mon bureau.

J’avais surtout tiré la mauvaise conclusion de l’échec de WireGuard

WireGuard m’avait poussé vers une explication très simple : son trafic passe en UDP.

WireGuard échoue.

OpenVPN UDP échoue.

OpenVPN TCP fonctionne.

Donc :

le réseau bloque UDP.

Sur le moment, cela semblait presque mathématique.

Un utilisateur de WireGuard décrivait encore fin 2025 un raisonnement très proche après avoir rencontré plusieurs Wi-Fi publics où son tunnel ne fonctionnait plus. Il cherchait naturellement une alternative TCP. Dans la discussion, d’autres participants ont toutefois soulevé une distinction importante : le réseau pouvait filtrer certains ports, certaines destinations ou certaines formes de trafic plutôt que fermer UDP dans son ensemble.

C’était précisément la nuance qui manquait à mon diagnostic.

J’avais vu deux portes UDP fermées et j’en avais conclu que tout le couloir était condamné.

Il pouvait simplement s’agir de ces deux portes.

« UDP filtré » peut vouloir dire plusieurs choses

À partir de là, je n’avais plus besoin de transformer le dépannage en cours de réseau.

Je me suis représenté le Wi-Fi comme un vigile.

Il peut décider :

« Je refuse tout ce qui arrive en UDP. »

Dans ce cas, la situation est claire. WireGuard ne passe pas, QUIC non plus, et OpenVPN TCP 443 devient un vrai refuge.

Mais le vigile peut aussi avoir une liste plus précise :

« Ce port-là, non. Ce type de tunnel-là, non. Le reste peut passer. »

Un opérateur français de solutions Wi-Fi administrées documente par exemple des mécanismes de filtrage portant à la fois sur des ports VPN précis et sur une catégorie de « VPN grand public ».

Cette distinction change tout.

L’échec de WireGuard ne prouvait plus que l’UDP entier était inutilisable.

Il prouvait surtout que mon WireGuard n’arrivait pas à traverser ce réseau.

Et il me restait un moyen assez simple de savoir si le vigile avait réellement fermé tout le couloir.

Le navigateur m’a donné l’indice qui manquait

Pendant mes essais, le Web continuait à fonctionner normalement.

Or une partie du Web moderne utilise HTTP/3.

HTTP/3 repose sur QUIC, et QUIC utilise UDP. La spécification prévoit d’ailleurs que si UDP est réellement inaccessible, QUIC échoue et le client doit se rabattre sur une autre méthode de connexion.

C’était beaucoup plus parlant que ma succession de boutons dans l’application VPN.

Si un transport HTTP/3 réussissait à traverser ce Wi-Fi, alors UDP n’était pas complètement fermé.

Le réseau faisait quelque chose de plus sélectif.

Et dans ce cas, rester toute la journée sur OpenVPN TCP simplement parce qu’il avait réussi à se connecter devenait moins séduisant.

J’avais trouvé un protocole qui contournait le problème.

Je voulais maintenant savoir si je pouvais éviter le compromis.

Mon grand fournisseur m’avait dépanné, mais je restais sur la sortie de secours

Je ne pouvais pas vraiment reprocher à mon VPN habituel d’avoir échoué.

Il proposait OpenVPN TCP.

J’en avais besoin.

Je l’avais sélectionné.

La connexion était partie.

Pour récupérer rapidement un fichier ou ouvrir une page urgente, cela aurait été suffisant.

Le problème est apparu quand j’ai voulu faire ce que j’étais réellement venu faire : garder une visioconférence ouverte tout en partageant mon écran et en synchronisant des fichiers.

Là, le tunnel fonctionnait sans devenir invisible.

Je le sentais.

Dans l’audio.

Dans les pauses du partage d’écran.

Dans le dossier qui avançait par à-coups.

J’aurais pu continuer à explorer les paramètres : autre serveur, autre port, autre combinaison, nouveau test.

Mais j’avais déjà passé suffisamment de temps à demander au réseau ce qu’il acceptait.

J’ai préféré essayer une connexion conçue pour s’adapter à ce genre de réseau.

J’ai choisi le réseau restrictif, pas le protocole

J’ai ouvert le petit service utilisé pour la deuxième partie du test.

Au lieu de choisir moi-même TCP, UDP, un port puis un serveur, j’ai sélectionné son mode destiné aux réseaux restrictifs.

Connexion.

Puis retour à la réunion.

L’audio est revenu.

J’ai réactivé le partage d’écran.

Ensuite, j’ai relancé le dossier qui avançait par à-coups.

Cette fois, je l’ai laissé faire.

Les fichiers ont continué à partir pendant que la conversation se poursuivait.

J’ai ouvert un document partagé, fait une modification et attendu la synchronisation.

Elle est apparue chez mon interlocuteur.

Je n’avais pas changé de Wi-Fi.

Je n’avais demandé l’ouverture d’aucun port.

Et je n’étais plus en OpenVPN TCP.

Dans les essais préparés pour cet article, c’est ce mode qui a finalement accompli la tâche entière : maintenir le tunnel sur le réseau filtré tout en laissant la visioconférence, le partage d’écran et les transferts fonctionner ensemble.

À cet instant, je n’avais plus seulement trouvé un VPN qui se connectait.

J’avais retrouvé une connexion avec laquelle je pouvais travailler.

Et le fait qu’elle fonctionne m’apprenait quelque chose sur le réseau lui-même.

HTTP/3 m’a montré que le problème n’était pas « UDP interdit »

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

HTTP/3 passant par QUIC, donc par UDP, le résultat devenait assez révélateur.

Si tout UDP avait réellement été jeté à la porte, cette route n’aurait pas pu fonctionner ainsi.

Mon diagnostic initial était donc trop large.

Le Wi-Fi ne fonctionnait pas comme deux interrupteurs :

UDP = non.

TCP = oui.

Il faisait une distinction plus fine entre les connexions.

C’est aussi ce qui rendait l’obfuscation intéressante dans ce cas précis. Elle cherche à rendre le tunnel moins immédiatement reconnaissable comme un VPN conventionnel.

Le premier service avait réussi en changeant complètement de moyen de transport : TCP 443 passait là où ses modes UDP échouaient.

Le second m’a montré qu’il existait encore une route UDP exploitable lorsque le trafic était présenté autrement.

C’était beaucoup plus proche de ce que je voulais au départ : franchir le réseau filtré sans passer ma journée dans un mode de secours plus lourd.

Si tout UDP est réellement bloqué, OpenVPN TCP garde son rôle

Il reste une frontière simple.

Si le réseau bloque véritablement tout UDP, HTTP/3 ne peut pas contourner cette réalité : QUIC utilise UDP.

Dans ce cas, je veux une vraie solution TCP.

OpenVPN TCP 443 reste alors un choix logique, précisément parce qu’il peut emprunter un chemin que le réseau laisse ouvert.

Mais mon erreur avait été de considérer cette situation comme acquise dès que WireGuard et OpenVPN UDP avaient échoué.

Ce n’est pas toujours la même chose.

Deux protocoles UDP refusés ne signifient pas automatiquement que chaque possibilité basée sur UDP est morte.

Et sur le Wi-Fi que j’avais devant moi, cette différence m’a évité de rester enfermé dans le compromis TCP.

Le lendemain, je n’ai pas commencé par ouvrir le menu des protocoles

C’est finalement ce qui a changé ma manière de regarder ce problème.

Avant, j’aurais ouvert la fiche d’un VPN et cherché :

OpenVPN TCP : oui.

Port 443 : oui.

Très bien.

Maintenant, je garde OpenVPN TCP 443 comme une excellente roue de secours.

Mais je préfère une application capable de me faire éviter cette roue de secours lorsque le réseau laisse encore passer une route plus adaptée.

Le petit service garde une limite réelle : il propose moins de localisations et possède moins de recul public et d’avis indépendants que les grands fournisseurs installés depuis longtemps.

Pour choisir manuellement parmi de nombreuses villes, le grand fournisseur reste plus riche.

Mais sur ce Wi-Fi, ce n’était pas ce que j’essayais d’obtenir.

Mon VPN habituel avait réussi à me connecter grâce à OpenVPN TCP.

Le petit service m’a permis de reprendre la réunion, le partage d’écran et les transferts sans rester coincé dans ce compromis.

J’étais arrivé en cherchant un VPN qui fonctionne en OpenVPN TCP lorsque UDP est filtré.

Je suis reparti avec un critère plus utile : avant de choisir TCP comme solution définitive, je veux savoir si le réseau a vraiment fermé UDP — ou s’il suffit d’un tunnel qu’il reconnaît moins facilement pour que ma journée de travail redevienne normale.