VPN : quand le split tunnel devient un risque

On parle beaucoup de VPN. C’est devenu un réflexe presque automatique en entreprise, et même à la maison, surtout depuis que le télétravail est passé de « exception » à « normalité ».

Mais il y a un réglage, une option, un simple choix d’architecture qui peut transformer un VPN en truc… un peu bancal. Voire franchement dangereux si on ne sait pas exactement ce qu’on fait.

Ce réglage, c’est le split tunneling.

Je vais expliquer simplement ce que c’est, pourquoi on l’active, et surtout comment ça peut déraper. Avec des exemples concrets, des scénarios réalistes, et des pistes de mitigation qui tiennent la route.

Split tunneling : c’est quoi exactement

Un VPN classique, en mode « full tunnel », fait passer tout le trafic réseau du poste dans le tunnel VPN. Tout.

Donc même quand tu vas sur un site web public, la requête sort par l’entreprise, via le VPN. Tu es « virtuellement » dans le réseau de la boîte.

En split tunneling, on coupe le trafic en deux :

• le trafic destiné au réseau de l’entreprise passe dans le tunnel
• le reste sort directement sur Internet, via la connexion locale

Sur le papier, c’est séduisant. Et parfois même nécessaire.

Pourquoi des équipes l’activent

Quelques raisons qu’on voit souvent :

• Performance : éviter d’envoyer YouTube, Teams, Windows Update ou le cloud perso via le VPN de l’entreprise.
• Bande passante : quand le concentrateur VPN ou la sortie Internet du siège est déjà chargée.
• Accès local : pouvoir imprimer sur l’imprimante de la maison, accéder à une box, un NAS local, ou des outils internes au site distant.
• SaaS : laisser les accès Microsoft 365, Google, Salesforce sortir en direct.

En vrai, dans certains environnements, le split tunnel est presque une rustine indispensable. Surtout quand l’infra VPN n’a pas été dimensionnée pour du « full tunnel » massif.

Le problème ? C’est que tu crées une machine avec deux mondes réseau en parallèle. Et ça, c’est exactement le genre de truc que les attaquants adorent.

Le risque principal : faire du poste un pont involontaire

Avec le split tunnel, le poste est à la fois :

• connecté à Internet « normalement »
• connecté au réseau interne via le VPN

Donc si ce poste se fait compromettre, l’attaquant peut potentiellement utiliser la session VPN comme un accès indirect au réseau interne.

Ce n’est pas nouveau, mais c’est brutal dans les faits.

En full tunnel, au moins, on force souvent des contrôles : DNS d’entreprise, proxy, filtrage web, inspection, logs centralisés, egress contrôlé.

En split tunnel, une partie du trafic échappe à tout ça. Et le poste devient une zone grise.

Scénario 1 : malware sur un Wi‑Fi public

Tu es en déplacement, tu te connectes à un Wi‑Fi d’hôtel ou de café. VPN actif en split tunnel. Tu chopes un malware via une pièce jointe, une extension navigateur, un faux update, peu importe.

À ce moment là, le malware a une machine qui peut parler à Internet directement, mais aussi accéder au réseau interne.

Il peut :

• scanner des sous réseaux internes
• tenter du mouvement latéral
• récupérer des ressources internes (partages, intranet, RDP, SSH…)
• exfiltrer des données via la sortie Internet directe, en contournant la supervision centrale

Et ça, c’est une combinaison assez classique en incident.

Scénario 2 : détournement DNS et accès à des ressources internes

Autre cas fréquent : le poste utilise un DNS public ou celui de la box (parce que split tunnel), mais accède à des noms internes via le VPN.

Résultat : ambiguïtés, fuites de requêtes DNS, voire attaques de type DNS spoofing sur le réseau local.

Dans certains cas, un attaquant sur le même LAN peut influencer la résolution et rediriger du trafic vers un serveur malveillant. Si derrière tu as des applis internes pas parfaitement sécurisées, tu peux te retrouver avec un vol d’identifiants, ou un proxying de session.

Oui, même en 2026, ça arrive. Souvent via des applis internes anciennes, ou des habitudes du style « certificat auto signé accepté parce que flemme ».

Scénario 3 : l’exfiltration « invisible »

En split tunnel, l’exfiltration de données peut sortir directement sur Internet, sans passer par les contrôles réseau de l’entreprise.

Et même si tu as un EDR, ce n’est pas pareil que d’avoir aussi du contrôle egress, du proxy, du DLP, des logs réseau.

C’est typiquement le genre de situation où l’attaque est détectée… mais trop tard. Parce que les données sont déjà parties.

Le split tunnel et la surface d’attaque : ça grossit vite

Ce qui change concrètement quand on active le split tunneling :

• Deux routes réseau sur le poste, donc plus de complexité.
• Deux périmètres de confiance : un réseau local potentiellement hostile, et le réseau interne.
• Des exceptions dans la sécurité : DNS, proxy, règles firewall, routage, segmentation.
• Des logs incomplets côté entreprise, parce que tout ne passe plus par elle.

Et ensuite, ça se combine avec la réalité du terrain :

• PC perso qui sert parfois « un peu » pour bosser
• droits admin locaux (ou contournements)
• mises à jour pas toujours au top
• Wi‑Fi domestique non segmenté
• IoT sur le même réseau (caméras, TV, domotique…)
• partage de connexion via smartphone

Ça fait beaucoup.

Les erreurs courantes qui rendent ça pire

On voit souvent les mêmes pièges.

Mettre des exceptions trop larges

Exemple : « Tout ce qui n’est pas 10.0.0.0/8 sort en direct ».

Sauf que ton réseau interne ne se limite pas forcément à 10.0.0.0/8. Il y a peut être du 172.16.0.0/12, du 192.168.0.0/16, des réseaux cloud, des partenaires, etc.

Et même si c’est « juste » 10/8, il suffit d’une interco oubliée, d’un subnet pas documenté, et tu crées des accès bizarres.

Laisser passer des protocoles sensibles

Si un poste en split tunnel peut atteindre des services internes, mais que ces services acceptent des protocoles faibles ou mal filtrés, tu offres un terrain de jeu :

• SMB non durci
• RDP exposé sur trop de machines
• WinRM ouvert
• SSH avec auth faible
• interfaces web d’admin internes
• bases de données accessibles « parce que c’est interne »

Le split tunnel n’est pas la cause unique. Mais il rend l’exploitation plus probable, plus rapide.

Oublier l’IPv6

Celle là est classique. On configure le split tunnel en IPv4, on oublie l’IPv6.

Résultat : fuites de trafic, DNS leaks, routes inattendues. Et parfois, des applications qui préfèrent IPv6 et contournent les chemins attendus.

Comment réduire le risque sans tout interdire

Bon. Dire « il faut supprimer le split tunnel » c’est facile.

Dans la vraie vie, tu as souvent des contraintes, et tu ne peux pas juste basculer tout en full tunnel du jour au lendemain.

Donc voilà des mesures qui aident, en gardant une approche pragmatique.

1) Appliquer un modèle « least privilege » côté VPN

Même si le poste a accès au réseau interne, il ne doit pas voir grand chose.

• segmentation réseau
• ACL strictes
• accès uniquement aux sous réseaux nécessaires
• pas d’accès « plat » à tout le LAN

Concrètement, un utilisateur VPN n’a pas besoin de scanner des serveurs d’admin, des VLAN serveurs, de la supervision, ou des hyperviseurs. Jamais.

2) Forcer le DNS sécurisé, même en split tunnel

Tu peux garder du split tunneling et quand même contrôler la résolution DNS.

Deux approches fréquentes :

• DNS d’entreprise via le tunnel pour certains suffixes (split DNS)
• DNS sécurisé (DoH/DoT) imposé, avec politique et filtrage

L’objectif : éviter les fuites DNS et réduire le risque de spoofing local.

3) Isoler le poste au niveau pare feu local

Un poste en split tunnel doit être plus strict, pas moins.

• pare feu Windows/Linux durci
• blocage des services d’écoute inutiles
• interdiction de certaines communications entrantes sur réseau public
• profils réseau bien gérés (public vs privé)

Et pas « l’utilisateur peut désactiver le firewall ». Sinon tout ça ne sert à rien.

4) ZTNA ou accès applicatif plutôt que réseau complet

Quand c’est possible, remplacer l’accès réseau par un accès applicatif :

• reverse proxy
• bastion
• portail d’accès
• ZTNA (accès par identité, device posture, règles contextuelles)

C’est souvent plus propre. Et ça réduit l’intérêt du split tunnel, parce que tu n’es plus obligé de mettre le poste « dans » le réseau interne.

5) Posture device et EDR : non négociable

Si split tunnel, alors posture forte :

• EDR actif et surveillé
• chiffrement disque
• mises à jour forcées
• contrôle des applications
• restrictions admin local
• inventaire et conformité

Sinon c’est littéralement une porte avec une serrure jouet.

6) Journaliser autrement

Si le trafic Internet ne passe plus par l’entreprise, il faut compenser :

• logs EDR
• logs DNS
• logs du client VPN
• télémétrie endpoint
• SIEM si possible, même petit

Tu veux pouvoir reconstruire une timeline. Pas juste deviner.

Split tunnel : comment décider si c’est acceptable

Une question simple à se poser :

« Si ce poste est compromis, qu’est ce que l’attaquant peut faire grâce au VPN ? »

Si la réponse ressemble à : « accéder à des serveurs internes critiques » ou « se déplacer facilement », alors split tunnel est probablement une mauvaise idée dans cet environnement.

À l’inverse, si ton VPN ne donne accès qu’à deux applis internes, via des flux strictement filtrés, et que tu as une posture endpoint solide… ok, ça peut se défendre.

Mais ça doit être une décision assumée, documentée, revue. Pas juste un toggle activé parce que « ça rame sinon ».

Mini check list de durcissement (rapide, mais utile)

• split tunnel limité à des besoins identifiés, pas « par défaut »
• routes précises, documentées, revues
• split DNS ou DNS contrôlé
• IPv6 géré ou désactivé proprement selon politique
• ACL VPN strictes, segmentation
• pas de services internes exposés inutilement aux profils VPN
• pare feu endpoint verrouillé
• EDR et patch management imposés
• logs centralisés endpoint + VPN

Oui, c’est plus de boulot. Mais c’est aussi ça, l’admin système et réseau. Les détails qui évitent la semaine infernale.

Un mot pour les étudiants et juniors SISR

Si tu es en BTS SIO option SISR, ou que tu débutes en support / sysadmin, c’est typiquement le genre de sujet qui tombe en entretien, ou qui arrive en stage sans prévenir.

Et c’est un bon thème de mini lab : monter un VPN (WireGuard, OpenVPN, ou un pare feu type pfSense), tester full tunnel vs split tunnel, observer les routes, les DNS leaks, et simuler des règles de filtrage.

Sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), on publie justement ce type de contenus orientés pratique, avec des pas à pas et des retours terrain. Si tu veux, tu peux y jeter un oeil et piocher des idées de labs E4/E5, ou juste renforcer ta culture infra.

Conclusion : le split tunnel n’est pas « mal », mais il est exigeant

Le split tunneling, ce n’est pas le mal incarné. C’est juste un compromis.

Sauf qu’en sécurité, les compromis coûtent toujours quelque chose. Ici, le coût, c’est la perte de contrôle réseau centralisé et l’augmentation du risque qu’un poste devienne un pont entre Internet et le SI interne.

Si tu dois l’activer, fais le proprement. Routes minimales, DNS maîtrisé, segmentation, posture endpoint solide, et supervision.

Sinon, tu auras un VPN qui fonctionne. Jusqu’au jour où il fonctionne aussi pour quelqu’un d’autre.

Questions fréquemment posées

Qu'est-ce que le split tunneling dans un VPN ?

Le split tunneling est une option de configuration d'un VPN qui permet de diviser le trafic réseau en deux : le trafic destiné au réseau de l'entreprise passe par le tunnel VPN sécurisé, tandis que le reste du trafic Internet sort directement via la connexion locale. Cela contraste avec un VPN en mode full tunnel où tout le trafic passe par le VPN.

Pourquoi les équipes informatiques activent-elles le split tunneling ?

Les raisons courantes d'activer le split tunneling incluent l'amélioration des performances en évitant d'envoyer des flux lourds comme YouTube ou Teams via le VPN, la réduction de la charge sur la bande passante du concentrateur VPN, l'accès aux ressources locales comme une imprimante ou un NAS à domicile, et la possibilité d'accéder directement à des services SaaS tels que Microsoft 365 ou Google.

Quels sont les risques liés à l'utilisation du split tunneling ?

Le principal risque est que le poste devienne un pont involontaire entre Internet et le réseau interne de l'entreprise. Si le poste est compromis (par exemple via un malware sur un Wi-Fi public), l'attaquant peut accéder au réseau interne via la session VPN tout en utilisant la connexion Internet locale pour exfiltrer des données, contournant ainsi les contrôles et la supervision centralisée.

Comment un malware peut-il exploiter une configuration en split tunneling ?

Un malware infectant un poste connecté en split tunneling peut scanner et accéder aux sous-réseaux internes grâce au VPN tout en communiquant librement sur Internet via la connexion locale. Cela facilite les mouvements latéraux dans le réseau interne et permet l'exfiltration discrète de données sans passer par les dispositifs de sécurité habituels.

Quels problèmes peuvent survenir avec le DNS lors du split tunneling ?

Lorsque le poste utilise un DNS public ou celui de la box locale tout en accédant à des ressources internes via VPN, cela peut provoquer des fuites de requêtes DNS, des ambiguïtés dans la résolution des noms, voire exposer à des attaques comme le DNS spoofing, compromettant ainsi la sécurité du réseau interne.

Quelles mesures peut-on prendre pour mitiger les risques du split tunneling ?

Pour limiter les risques, il est conseillé d'appliquer des politiques strictes de contrôle d'accès, utiliser des solutions de sécurité avancées sur les postes (antivirus, détection d'intrusion), configurer correctement les règles DNS pour éviter les fuites, restreindre les applications autorisées à sortir hors du tunnel, et surveiller activement les connexions pour détecter toute activité suspecte.