Pourquoi le split tunneling peut laisser fuir le DNS alors que votre adresse IP paraît parfaitement protégée

J’avais activé le split tunneling précisément parce qu’il fonctionnait.

Depuis un espace de coworking à Paris, je voulais garder Firefox derrière mon VPN tout en laissant Teams et quelques applications locales utiliser directement la connexion. Avec tout le PC dans le tunnel, mes appels avaient parfois plus de latence. Cette séparation semblait donc être le compromis propre.

J’ai ouvert Firefox et vérifié mon adresse IP. Ce n’était plus celle du réseau du coworking. Bon pays. Bonne adresse VPN. Teams fonctionnait normalement à côté.

J’avais exactement ce que je voulais. Puis, avant d’ouvrir l’interface d’administration d’un client, j’ai lancé un test DNS. Le résolveur apparu à l’écran n’avait rien à voir avec celui que j’attendais derrière le VPN. J’ai relancé le test.

Même chose.

C’était le résultat le plus déroutant possible : mon navigateur semblait sortir par le VPN, mais ses questions DNS semblaient emprunter une autre porte.

J’ai d’abord accusé le mauvais serveur

Mon premier réflexe a été de changer de serveur VPN. C’était logique. L’adresse IP était la seule chose visible que je savais manipuler facilement. J’ai changé de sortie, fermé Firefox, rouvert le navigateur et recommencé. Nouvelle IP.

Même résolveur DNS inattendu. J’ai changé encore une fois. L’adresse publique a de nouveau bougé. Le DNS, lui, n’a pratiquement pas bronché.

À ce moment-là, le serveur cessait d’être un bon suspect. Si deux sorties VPN différentes changeaient correctement mon IP mais pas le chemin DNS, quelque chose se passait ailleurs.

C’est aussi un problème très actuel. Les clients VPN sous Windows continuent à ajuster l’interaction entre split tunneling, IPv6, kill switch et règles DNS. En juillet 2026, Proton indiquait par exemple avoir corrigé un problème où certaines règles DNS pouvaient subsister après un crash, tout en ajoutant une détection des conflits réseau.

Autrement dit, je n’étais pas devant une vieille curiosité technique. J’étais devant deux mécanismes réseau capables d’évoluer séparément.

L’IP et le DNS répondaient à deux questions différentes

Le déclic a été de cesser d’imaginer « ma connexion Internet » comme un seul tuyau. Quand je tape un domaine, deux étapes m’intéressent ici. D’abord, mon appareil doit demander : « à quelle adresse correspond ce nom ? » C’est le DNS.

Ensuite, Firefox se connecte à cette adresse et charge le site.

Le test d’IP observe surtout cette seconde partie. Il demande en quelque sorte au site : « de quelle adresse publique vient cette connexion ? »

Si Firefox passe par le VPN, le site voit l’adresse du VPN. Tout paraît donc correct. Mais cela ne dit pas forcément qui a répondu à la question DNS quelques millisecondes auparavant.

Windows possède ses propres règles pour choisir le résolveur DNS, en fonction notamment des interfaces réseau, des politiques de résolution et de leurs priorités.

C’était beaucoup plus simple à comprendre ainsi :

le navigateur pouvait prendre l’autoroute VPN tandis que le DNS demandait encore son chemin à la réception du coworking.

Mon adresse IP n’était pas fausse.

Je lui demandais simplement de prouver quelque chose qu’elle ne pouvait pas prouver.

Split tunneling et split DNS ne sont pas la même décision

C’est là que ma configuration a commencé à avoir du sens.

Le split tunneling sert à décider quel trafic passe dans le VPN et quel trafic emprunte directement la connexion normale. Microsoft donne justement l’exemple d’un utilisateur d’hôtel qui réserve le VPN aux ressources professionnelles tout en laissant le reste d’Internet utiliser la connexion locale.

C’était presque exactement ce que je faisais.

Mais une deuxième question reste ouverte : où partent les requêtes DNS ?

La documentation Cisco distingue clairement les deux mécanismes. Avec du split DNS, certaines recherches de noms peuvent être envoyées vers le DNS du VPN tandis que d’autres continuent à utiliser un résolveur extérieur. Selon la politique appliquée, les requêtes DNS peuvent donc suivre une logique différente de celle que l’on imagine simplement en regardant quelles applications sont incluses ou exclues du tunnel.

Voilà comment mon écran pouvait afficher deux résultats cohérents : Firefox → VPN → site Web. DNS → connexion locale → résolveur extérieur. Une fois cette image en tête, le paradoxe disparaissait.

La liste des applications m’avait donné une fausse impression de propreté

Le plus trompeur dans le split tunneling, c’est son interface. On voit Firefox dans une colonne. Teams dans une autre. On coche quelques cases.

Cela donne l’impression que la connexion entière a été découpée proprement application par application.

Le système d’exploitation, lui, voit davantage de choses : interfaces réseau, routes, DNS, IPv4, IPv6 et parfois des résolveurs propres au navigateur.

Cette différence explique pourquoi des utilisateurs rencontrent des comportements qui semblent absurdes.

En janvier 2026, un utilisateur Windows décrivait publiquement une configuration où seul VLC devait utiliser le VPN. Pourtant, dès l’activation du client, Firefox et Chrome ne suivaient plus correctement les routes DNS configurées sur son réseau UniFi. Les autres appareils continuaient à fonctionner normalement ; le problème concernait le PC où VPN et split tunneling étaient actifs.

Ce qui m’a intéressé dans ce témoignage n’était pas le logiciel utilisé.

C’était l’erreur de raisonnement.

J’avais fait la même : si une application est hors du tunnel, son DNS doit forcément être hors du tunnel ; si elle est dedans, son DNS doit forcément être dedans.

Ce raccourci est pratique.

Il n’est pas toujours vrai.

J’ai arrêté de changer d’IP et j’ai changé une seule variable

J’ai remis ma première sortie VPN. Puis j’ai noté les deux résultats : adresse IP du VPN ; résolveur DNS du réseau que je ne voulais pas voir.

Ensuite, au lieu de changer encore de serveur, j’ai désactivé le split tunneling et reconnecté le VPN en mode complet.

Même test d’IP. Puis même test DNS. L’adresse publique appartenait toujours au VPN. Mais cette fois, le résolveur du coworking avait disparu.

Enfin, j’avais un test qui m’apprenait quelque chose. Changer de serveur modifiait seulement la sortie visible du tunnel. Supprimer temporairement la séparation modifiait la relation entre le tunnel et le DNS. Le vrai problème n’était donc plus « quel serveur dois-je essayer ? »

Il devenait : est-ce que j’ai réellement besoin de séparer ces routes maintenant ?

Je pouvais évidemment reconstruire ensuite une configuration plus fine, vérifier les règles Windows, le DNS du navigateur ou les exclusions une par une.

Mais j’étais devant un portail client que je voulais ouvrir tout de suite.

Et ma priorité venait de changer.

J’avais construit une configuration plus intelligente que nécessaire

Au départ, j’avais activé le split tunneling pour Teams. Je voulais moins de latence. C’était une bonne raison.

Puis ma tâche avait changé. J’allais consulter un tableau de bord client et des documents depuis un réseau partagé.

À ce moment-là, le contrôle précis de la route de chaque application devenait moins important que quelque chose de beaucoup plus simple : je voulais que mon navigateur et son DNS racontent la même histoire.

C’est là que j’ai repris OnlydogVPN^↗.

Je n’ai pas essayé de reconstruire immédiatement le même ensemble d’exclusions. J’ai utilisé l’approche plus simple de l’application, centrée sur le type de connexion plutôt que sur une longue liste de règles, puis je l’ai laissée établir la route.

Pas de nouvelle application à ajouter. Pas de serveur à comparer. Connexion. J’ai ouvert le test d’IP.

La sortie VPN apparaissait. Puis le test DNS. Le résolveur du coworking n’était plus là. Cette fois, j’ai continué au lieu de retourner dans les réglages.

Interface client. Connexion. MFA. Tableau de bord.

Le document dont j’avais besoin s’est ouvert. C’était le résultat concret qui me manquait depuis le début. Je n’avais pas obtenu une configuration plus sophistiquée. J’avais obtenu une configuration que je pouvais comprendre et vérifier.

Le service mise justement sur une connexion simple, en une action, plutôt que sur une longue configuration préalable. Ici, cette simplicité n’était pas seulement plus agréable. Elle supprimait une couche que j’avais ajoutée pour résoudre un problème secondaire et qui compliquait maintenant mon diagnostic.

J’ai laissé Teams ouvert pendant ce temps.

L’appel suivant est resté parfaitement utilisable pour mon usage, donc je n’ai pas ressenti le besoin de recréer immédiatement le split tunneling.

Et c’est ce détail qui m’a finalement fait garder cette configuration pour le reste de la session.

Je n’avais pas besoin de plus de règles, j’avais besoin d’une route que je pouvais vérifier

Le split tunneling reste extrêmement utile.

Si j’avais dû accéder simultanément à un NAS local, à un service professionnel imposant une route spécifique ou à plusieurs applications ayant réellement besoin de chemins différents, j’aurais pris le temps de construire une politique plus précise.

Et le petit service que j’utilisais a ses limites : moins de localisations qu’un grand acteur, un historique public plus court et moins d’évaluations indépendantes. Pour quelqu’un dont la priorité est de manipuler finement beaucoup de routes et de destinations, ces différences comptent.

Mais ce n’était pas ce que j’essayais de résoudre.

Je voulais comprendre pourquoi un écran disait « VPN connecté » pendant qu’un autre semblait révéler mon réseau local.

La réponse était finalement beaucoup plus précise que « fuite VPN ».

Le split tunneling peut envoyer le trafic Web d’une application dans le tunnel tout en laissant la résolution DNS obéir à une autre politique.

Une adresse IP correcte confirme donc que la connexion observée par ce site est sortie par le VPN. Elle ne confirme pas, à elle seule, le trajet du DNS. C’est ce qui a changé mon critère.

Au début, je pensais qu’une configuration plus granulaire était forcément une meilleure configuration.

Pour cette session, c’était l’inverse : une route plus simple que je pouvais vérifier de bout en bout valait davantage qu’un split tunneling élégant dont une partie du DNS continuait à prendre la porte du coworking.