Deux pare-feu ou deux kill switches peuvent-ils se bloquer mutuellement ? Le jour où mon VPN de secours n’arrivait même plus à se connecter

J’avais installé un deuxième VPN précisément parce que je voulais une solution de secours. J’avais donc fait ce qui me paraissait prudent : laisser le premier installé, conserver son kill switch permanent, garder le pare-feu Windows actif et tester le nouveau sans toucher au reste.

Le résultat ressemblait à une panne du deuxième VPN. « Connexion… » restait affiché, puis expirait. Lorsque je fermais le premier VPN, Internet disparaissait complètement. Lorsque je le reconnectais, Internet revenait. J’ai d’abord pensé que le nouveau client était défectueux.

Le problème était presque l’inverse : l’ancienne protection fonctionnait si strictement qu’elle empêchait sa remplaçante d’établir la connexion dont elle avait besoin pour me protéger.

Mon erreur était de penser que deux blocages formaient automatiquement une protection plus forte

Sur le papier, le raisonnement semblait impeccable.

Le pare-feu Windows filtre le trafic. Le VPN possède son kill switch. Et puisque je voulais simplement essayer un deuxième service sans affaiblir ma protection, garder le kill switch du premier actif me paraissait presque être la précaution évidente.

Si une protection est bonne, deux doivent être meilleures.

Sauf qu’un kill switch n’est pas simplement une alarme qui surveille le VPN. Dans sa version la plus stricte, il devient une règle de circulation : tant que mon tunnel n’est pas actif, rien d’autre ne sort.

Et le mot important est « mon ».

Pour établir un second VPN, celui-ci doit d’abord contacter son propre serveur à travers la connexion disponible. Il envoie quelques premiers paquets, négocie son tunnel, puis crée la route protégée.

Or le premier kill switch peut déjà être posté devant la porte avec une consigne très simple : « rien ne passe en dehors de mon VPN ».

Les premiers paquets du deuxième service sont alors arrêtés avant même que son tunnel existe.

À partir de là, mon écran « Connexion… » devenait beaucoup moins mystérieux.

Deux pare-feu peuvent cohabiter. Deux gardiens qui possèdent chacun l’unique clé, beaucoup moins

C’est là que j’ai cessé de parler vaguement de « conflit de pare-feu ».

Avoir le pare-feu d’une box Internet et celui de Windows est parfaitement banal. Ils n’essaient pas nécessairement de contrôler la même chose de la même manière.

Sur Windows, la Windows Filtering Platform, ou WFP, est justement l’infrastructure qui permet à des pare-feu, antivirus et autres logiciels réseau d’inspecter et de filtrer le trafic à différents endroits de la pile réseau.

Là où cela devient intéressant pour deux VPN, c’est que Windows doit ensuite arbitrer entre les règles qui se rencontrent. Microsoft documente explicitement que plusieurs fournisseurs peuvent examiner le même trafic et que, dans son modèle de filtrage, une règle de blocage peut l’emporter sur une autorisation.

Je n’avais donc pas besoin de comprendre toute la plomberie de WFP pour comprendre mon problème.

Imaginez deux gardiens devant la même sortie. Le premier possède une liste disant « laisser passer uniquement les voitures de l’entreprise A ». Le second arrive avec une voiture de l’entreprise B et promet qu’il aura lui aussi sa propre liste de sécurité une fois dehors.

Il ne sortira jamais du parking.

C’était exactement la question à résoudre sur ma machine : qui avait encore le pouvoir de dire non avant que le nouveau VPN puisse dire oui ?

Le kill switch continuait à travailler même lorsque j’avais fermé l’application

C’était le détail qui m’avait le plus trompé.
Dans ma tête, le kill switch appartenait à la fenêtre du VPN.
Application ouverte : protection active.
Application fermée : protection disparue.

Un mode permanent peut fonctionner autrement.

Proton explique par exemple que son Advanced Kill Switch sous Windows crée des filtres persistants avec WFP. Une fois activé, il bloque les connexions qui ne passent pas par l’interface VPN et reste en place même après un redémarrage. Pour retrouver une connexion Internet normale, il faut désactiver ce mode, pas simplement déconnecter le tunnel.

Et soudain, mon comportement réseau avait une logique.
Le gardien était toujours à la porte alors que j’avais fermé le bureau.

C’est une excellente propriété lorsque je veux qu’une machine ne sorte jamais accidentellement sans VPN. Mais lorsque je remplace ce VPN par un autre, cette même fidélité devient le problème : l’ancien gardien ne reconnaît pas automatiquement le nouveau comme son successeur.

En 2026, les clients VPN détectent encore ce genre de conflit

Ce n’est pas seulement une bizarrerie de vieux logiciels réseau.

Le 13 juillet 2026, Proton a ajouté à son application Windows une détection automatique des conflits réseau. L’application cherche désormais à identifier lorsqu’un autre logiciel présent sur l’appareil interfère avec la connexion VPN. La même version corrigeait aussi un cas où des règles DNS pouvaient rester actives après un crash et continuer à perturber la navigation après la déconnexion.

C’est ce qui a changé ma façon de regarder la panne.

Deux VPN ne sont pas simplement deux applications qui affichent chacune un gros bouton « Connecter ». Ils touchent aux routes, aux interfaces, au DNS et parfois aux filtres qui décident quels paquets ont le droit de sortir.

Le symptôme peut donc être spectaculaire — Wi-Fi connecté, navigateur hors ligne, deuxième VPN incapable de démarrer — alors que la cause tient à une règle parfaitement cohérente qui appartient encore au premier.

Et un utilisateur de Mullvad avait justement reproduit presque exactement ce piège.

Quelqu’un avait déjà réussi à enfermer son deuxième VPN dehors

Dans une discussion publique, un utilisateur voulait essayer Proton tout en conservant Mullvad installé. Lorsqu’il lançait Proton, Mullvad perdait sa connexion ; son réglage « Always require VPN » bloquait alors Internet, et Proton perdait à son tour la connexion dont il avait besoin pour établir son propre tunnel.

La réponse qui a résolu son problème tenait en quelques mots : désactiver « Always require VPN » dans les réglages avancés de Mullvad.

C’était beaucoup plus utile que de lire une nouvelle comparaison de protocoles.
Le VPN A exige que le trafic passe par A.
Le VPN B essaie de créer son tunnel.
Pour créer ce tunnel, B doit d’abord envoyer du trafic.

A bloque ce trafic parce qu’il ne passe pas par A.
B ne devient donc jamais le VPN actif.

J’avais installé un deuxième parachute. Le premier m’empêchait simplement d’ouvrir la porte de l’avion.

J’ai arrêté de désactiver des protections au hasard

Mon premier réflexe avait été de couper temporairement tout ce qui ressemblait à un pare-feu pour voir si le VPN se mettait enfin à fonctionner.

C’était tentant, mais cela répondait à la mauvaise question.

Je n’avais pas besoin de savoir si « zéro protection » fonctionnait. Je devais trouver quelle couche exigeait encore l’ancien tunnel.

J’ai donc fermé le second VPN.

Puis j’ai rouvert le premier et désactivé proprement son mode de blocage permanent au lieu de simplement quitter l’application.

Ensuite seulement, j’ai vérifié la connexion normale.
Un site s’est ouvert sans VPN.
C’était le test décisif.

Le pare-feu Windows était toujours actif. Je n’avais pas démonté toute la sécurité de la machine. J’avais seulement retiré la règle qui disait : « Internet uniquement si l’ancien VPN est connecté. »

Pour la première fois, le deuxième VPN avait réellement une route pour démarrer.

C’est là que j’ai préféré une connexion simple à une deuxième architecture de règles

J’ai ouvert OnlydogVPN^↗.

À ce stade, je ne cherchais plus le VPN proposant le plus de réglages réseau. C’était justement ce raisonnement qui m’avait amené à une machine où je ne savais plus quelle couche décidait de quoi.

Je voulais appuyer sur Connecter et savoir qui contrôlait le tunnel.
J’ai choisi le mode correspondant à mon utilisation et lancé la connexion.
Cette fois, « Connexion… » n’est pas resté figé.
L’état est passé à connecté.

J’ai ouvert le navigateur.
La page s’est chargée.
Une deuxième aussi.

Puis j’ai volontairement coupé la connexion, vérifié le comportement du réseau et reconnecté. Le résultat est resté prévisible : je pouvais identifier le moment où le tunnel prenait la main et celui où il la rendait.

C’est précisément ce que je voulais après avoir passé du temps avec deux mécanismes capables de se marcher dessus.

L’application utilise un transport basé sur HTTP/3 et ajoute ses propres mécanismes destinés à rendre la connexion plus robuste, mais ce n’est pas ce qui m’a convaincu ici. Ce qui comptait dans ce test était beaucoup plus visible : je n’avais pas besoin d’empiler un nouveau pare-feu manuel ou de reconstruire une série d’exceptions simplement pour obtenir un tunnel fonctionnel.

Le problème qui m’avait amené à cette recherche avait disparu.

Le détail que j’ai apprécié ensuite n’avait rien à voir avec le pare-feu

Une fois le navigateur revenu à un fonctionnement normal, j’ai continué à utiliser la machine plutôt que de fermer immédiatement le VPN.

C’est là que la simplicité a eu un deuxième effet, plus discret.

Je n’avais pas dû créer un nouveau compte classique avec une adresse e-mail et un mot de passe simplement pour arriver jusqu’à cette connexion. Après avoir passé la première moitié du test à chercher quelle ancienne configuration survivait encore quelque part sur Windows, avoir une nouvelle application qui me demandait moins de choses à gérer avait quelque chose d’assez cohérent.

Ce n’est pas ce qui a débloqué mon tunnel.

C’est simplement ce qui m’a donné moins envie de supprimer l’application une fois le problème résolu.

Je ne supprimerais pas pour autant tous les autres pare-feu

La leçon n’était pas « un seul pare-feu par ordinateur ».
Le pare-feu du routeur peut rester.
Le pare-feu Windows peut rester.

Une politique de sécurité professionnelle peut évidemment avoir une raison très précise d’exister.

Le nombre de composants n’est pas le vrai problème.

Ce qui m’intéresse désormais, c’est le nombre de mécanismes qui revendiquent simultanément l’autorité exclusive sur la même sortie réseau.

Deux filtres qui remplissent des rôles différents peuvent parfaitement se compléter.

Deux kill switches disant chacun « aucun trafic sauf par mon VPN » créent quelque chose de très différent : chacun attend que son propre tunnel existe, tandis que l’autre peut empêcher ce tunnel de naître.

Et si l’un de ces mécanismes appartient à un VPN professionnel imposé par mon entreprise, je ne chercherais pas à le contourner avec un VPN personnel. Dans ce cas, le conflit est aussi une politique de sécurité, pas seulement un problème technique.

Le choix plus simple a aussi sa limite

Le service que j’ai finalement gardé est plus récent et propose moins de régions que plusieurs grands fournisseurs historiques.

Pour quelqu’un qui veut choisir précisément ses interfaces, construire des règles de routage complexes ou apparaître régulièrement depuis de nombreuses régions différentes, cette simplicité peut devenir une limite.

Mais c’est justement pour cela que le résultat m’a paru cohérent avec mon problème.
Je n’étais pas arrivé ici parce qu’il me manquait des réglages.

J’étais arrivé ici parce que j’en avais suffisamment empilés pour que le deuxième VPN ne puisse même plus envoyer ses premiers paquets.

Oui, deux pare-feu ou deux kill switches peuvent se gêner lorsqu’ils imposent des règles contradictoires, particulièrement lorsque chacun exige que le trafic passe exclusivement par son propre tunnel. La solution n’est donc pas de désactiver aveuglément toutes les protections, mais d’identifier celle qui possède encore l’ancienne route et de lui retirer proprement ce rôle.

Dans mon cas, une fois l’ancien blocage persistant supprimé, je n’avais plus besoin d’une couche de sécurité supplémentaire pour réparer les précédentes.

J’avais besoin d’un tunnel qui démarre, d’un comportement que je pouvais vérifier immédiatement et d’un seul mécanisme responsable de la connexion.

Quand mon VPN de secours n’arrive même pas à envoyer son premier paquet, je préfère désormais savoir exactement quel gardien tient la clé plutôt que d’en poster un deuxième devant la même porte.