Pourquoi le TCP peut cesser de passer en mode bridge alors que WireGuard en UDP continue ? Le tunnel qui survit indique où chercher

À 8 h 07, mon HTTPS ne répondait plus.

Le serveur était toujours allumé. Le routeur aussi. J’ai essayé SSH : timeout. Puis une autre redirection TCP que j’utilisais depuis des mois : même chose.

J’ai immédiatement ouvert WireGuard, davantage par réflexe que par logique. Connexion. Le tunnel vers la maison répondait.

C’est précisément ce résultat qui m’a fait perdre du temps. Si WireGuard traversait toujours la fibre, pensais-je, le mode bridge fonctionnait forcément.

J’ai donc vérifié les règles de pare-feu, les redirections de ports, l’adresse publique et le serveur derrière le routeur.

Tout semblait normal. Puis j’ai redémarré l’équipement placé devant mon routeur. HTTPS est revenu. SSH aussi. Le lendemain, le problème a recommencé. Et WireGuard fonctionnait encore. À ce moment-là, il devenait difficile de continuer à accuser le serveur.

Ce comportement étrange a réellement été signalé sur la fibre Proximus

En février 2026, un abonné fibre Proximus a décrit sur le forum de l’opérateur un scénario étonnamment proche : une Internet Box utilisée en mode bridge devant son propre routeur, des redirections TCP fonctionnelles pendant environ vingt heures, puis HTTP, HTTPS, SSH et d’autres connexions TCP entrantes qui cessent de répondre. Pendant ce temps, son serveur WireGuard reste accessible en UDP. Un redémarrage de l’Internet Box rétablit immédiatement le TCP.

Ce signalement m’intéressait surtout parce qu’il reproduisait la séparation que je voyais devant moi : ce n’était pas « Internet marche » contre « Internet ne marche pas ».

C’était TCP direct ne passe plus, UDP continue.

Le contexte belge rend cette distinction encore plus utile. Depuis le 1er novembre 2024, les utilisateurs peuvent employer leur propre modem ou routeur. Dans son rapport publié en juillet 2026, l’IBPT relevait encore certaines difficultés pratiques autour de ce libre choix, sans constater pour autant de blocage inadmissible généralisé des applications ou des services.

Autrement dit, face à ce symptôme précis, je n’avais pas besoin de partir immédiatement à la recherche d’un blocage volontaire du TCP. Un équipement intermédiaire qui se comporte mal après plusieurs heures était une piste beaucoup plus concrète.

Et surtout, WireGuard qui continuait de répondre ne blanchissait pas cet équipement.

WireGuard qui fonctionne ne signifie pas que le TCP direct fonctionne

C’est la partie qui paraît contre-intuitive jusqu’au moment où l’on regarde simplement l’enveloppe des paquets.

Une connexion TCP commence par un échange : SYN, SYN-ACK, ACK. Une fois cette connexion établie, TCP suit ensuite son état, les numéros de séquence, les accusés de réception et les retransmissions.

UDP demande beaucoup moins de cérémonial : un datagramme part vers sa destination.

WireGuard utilise justement UDP pour transporter ses paquets chiffrés. J’ai fini par me représenter les deux chemins comme deux colis.

Mon HTTPS direct arrive devant le bridge avec une grosse étiquette TCP. Si quelque chose dans ce chemin commence à mal gérer ce trafic, la connexion peut mourir avant d’atteindre correctement mon serveur.

Avec WireGuard, ce même trafic peut être placé à l’intérieur d’une enveloppe chiffrée dont l’extérieur est en UDP.

Pour l’équipement intermédiaire, ce n’est plus mon HTTPS direct qui traverse. Ce sont les paquets UDP du tunnel.

Voilà pourquoi je pouvais parfaitement ouvrir une session TCP à l’intérieur de WireGuard alors que la même connexion TCP, exposée directement à Internet, restait bloquée.

Cette différence m’a évité de faire encore vingt essais inutiles sur le serveur.

Si un redémarrage de l’équipement intermédiaire fait réapparaître tous mes ports TCP sans que je touche à Apache, SSH ou au NAS, le problème commence sérieusement à sentir le chemin réseau plutôt que l’application.

Mon premier « correctif » fonctionnait trop bien

À ce stade, la solution la plus facile était évidente. Redémarrer. TCP revient. Continuer ma journée. J’aurais même pu programmer un redémarrage nocturne et oublier l’affaire.

Le problème, c’est qu’un reboot qui efface le symptôme sans retirer sa cause ne constitue pas vraiment une réparation. Il transforme simplement une panne imprévisible en panne programmée.

Le signalement publié sur le forum Proximus avait justement une suite plus intéressante. Un participant a proposé de retirer complètement l’Internet Box du trajet et de brancher le routeur personnel directement sur l’ONT fibre. Après configuration du VLAN 20 et de DHCP, l’auteur a indiqué que la connexion fonctionnait sans devoir conserver l’Internet Box dans le chemin.

Cette architecture correspond aux indications techniques publiées par Proximus pour l’utilisation d’un routeur tiers : les lignes résidentielles utilisent le VLAN 20, l’IPv4 est obtenue par DHCPv4 et un routeur personnel peut être raccordé derrière l’ONT ou un modem assurant le pontage de niveau 2.

Pour une installation compatible, c’est la correction que j’aurais envie d’examiner plutôt que d’empiler les redémarrages.

Mais refaire proprement le WAN à huit heures du matin, alors que j’avais du travail à terminer, était une autre histoire.

J’avais besoin que mes applications passent maintenant.

J’ai cessé de tester d’autres ports TCP

Mon premier réflexe avait encore été celui d’un administrateur réseau. 443 ne passe pas ? Essayons 22. Puis un autre port. Puis un autre serveur.

Mais si le problème distingue déjà TCP et UDP, multiplier les ports TCP revient surtout à demander cinq fois la même chose au réseau.

J’ai donc changé de question.

Au lieu de chercher quel autre TCP pouvait survivre, j’ai cherché si je pouvais faire sortir mon trafic par la voie qui fonctionnait encore.

J’ai ouvert OnlydogVPN.

Le service utilise un transport basé sur HTTP/3. HTTP/3 repose sur QUIC, lui-même transporté sur UDP.

J’ai appuyé sur connexion.

Puis j’ai rouvert la page HTTPS qui restait suspendue quelques secondes auparavant.

Elle s’est chargée. J’ai relancé le téléchargement dont j’avais besoin. Cette fois, la barre a continué jusqu’au bout.

Enfin, j’ai ouvert l’outil de travail qui établissait normalement plusieurs connexions TCP.

Lui aussi fonctionnait dans le tunnel.

Cette réussite était beaucoup moins mystérieuse une fois le problème compris : mes applications pouvaient toujours utiliser TCP à l’intérieur du VPN, mais l’équipement défaillant ne voyait plus ces connexions sous leur forme TCP directe. L’enveloppe extérieure du tunnel suivait la voie UDP qui, elle, n’avait jamais cessé de passer.

WireGuard m’avait montré la piste. Ce deuxième tunnel m’a permis de m’en servir immédiatement.

Il n’avait pas réparé le bridge — il m’avait rendu ma matinée

Je n’aurais pas laissé la configuration dans cet état en prétendant que le bridge était réparé.

Si je dois rendre mon serveur HTTPS directement accessible depuis Internet, il faut encore corriger l’équipement ou l’architecture qui interrompt ce trafic. Un tunnel sortant ne transforme pas un bridge défaillant en bridge sain.

Mais ce n’était plus le problème urgent.

La page dont j’avais besoin s’ouvrait. Le téléchargement avançait. Mes outils communiquaient de nouveau.

Je pouvais travailler, puis toucher au WAN lorsque je disposerais du temps nécessaire pour le faire correctement.

C’est là que la simplicité du petit service a commencé à compter davantage que je ne l’aurais imaginé. Je connaissais déjà assez bien le problème pour ne pas avoir envie, à ce moment précis, de choisir manuellement un protocole, un pays, un serveur puis trois paramètres avancés. L’application est organisée autour d’actions simples et de scénarios d’usage plutôt que d’une longue exploration de réglages.

Dans un laboratoire, je veux voir chaque couche.

À 8 h 20 avec un fichier à envoyer, je veux surtout que la bonne couche soit choisie sans me faire perdre encore dix minutes.

Il existe évidemment un compromis : le service propose moins de régions et possède un historique public plus court que les grands fournisseurs établis. Si mon objectif principal était de disposer de dizaines de localisations ou d’une très longue accumulation d’évaluations indépendantes, j’aurais davantage de raisons de regarder ailleurs.

Ce matin-là, ce n’était pas le critère qui décidait si je pouvais travailler.

Le protocole qui continue est l’indice le plus utile

J’avais commencé avec une contradiction apparente :

comment le TCP peut-il cesser de passer en mode bridge alors que WireGuard continue sur la même connexion ?

Parce que WireGuard ne prouve pas que le chemin TCP direct est sain. Il montre qu’un chemin UDP vers son pair existe encore.

Et comme ce tunnel peut transporter ensuite du trafic TCP à l’intérieur de son enveloppe UDP, les applications peuvent redevenir utilisables sans que le TCP exposé directement ait retrouvé la moindre santé.

Dans le cas Proximus signalé en février, deux observations étaient particulièrement parlantes : redémarrer l’Internet Box faisait revenir le TCP, puis retirer cette Internet Box du trajet permettait de faire fonctionner la connexion autrement. Ce sont des indices beaucoup plus utiles que de modifier encore une règle NAT sur un serveur qui n’a jamais cessé de fonctionner.

La réparation durable appartient au chemin réseau.

Le tunnel UDP, lui, joue un rôle différent : il permet de ne pas rester bloqué pendant qu’on répare ce chemin.

C’est ce qui a finalement changé mon critère. Je ne cherchais plus le VPN affichant la plus grande carte de serveurs ou le plus joli résultat Speedtest. J’avais besoin d’une deuxième voie de transport au moment précis où le TCP ordinaire cessait d’être fiable.

Quand mon bridge faisait disparaître les connexions TCP alors que l’UDP continuait de passer, cette possibilité valait davantage, pour les vingt prochaines minutes, qu’un quatrième redémarrage.