Le VPN bloque l’accès LAN local : le split tunneling sur Windows, correctement

février 8, 2026 • février 8, 2026 • Lecture : 28 min • Views: 2

Cet article vous a aidé ?

Tout fonctionnait jusqu’à ce que vous vous connectiez au VPN d’entreprise. Puis votre NAS local disparaît, l’imprimante devient « hors ligne » et cet interrupteur IoT finit par devenir un concept philosophique. Le VPN n’a pas seulement ajouté un chemin sécurisé vers le travail ; il a silencieusement réorganisé votre réseau entier.

Ce n’est presque jamais « un bug Windows ». Ce sont le routage et le DNS qui font exactement ce qu’on leur a dit de faire — juste pas ce à quoi vous vous attendiez. Réparons cela correctement : avec du split tunneling, des routes explicites, des métriques prévisibles et des tests qui vous indiquent la décision suivante.

Ce qui casse réellement quand l’accès LAN disparaît

Quand un VPN « casse l’accès LAN local », les gens blâment le chiffrement, les tunnels, les pare-feu, ou l’atmosphère. En pratique, c’est généralement l’un de ces cas :

Votre route par défaut a changé (0.0.0.0/0 et/ou ::/0) pour pointer vers l’adaptateur VPN. Maintenant « tout ce qui n’est pas explicitement local » passe dans le tunnel — y compris ce que vous pensiez local.
Votre route vers le sous-réseau local a disparu parce que le VPN a injecté une route plus large qui l’emporte. Exemple : vous êtes sur 192.168.1.0/24 à la maison, mais le VPN pousse 192.168.0.0/16 et soudain votre LAN domestique est « corporate ».
La sélection de route est correcte mais les métriques ne le sont pas. Windows choisit la métrique la plus basse, puis le préfixe le plus spécifique. Si l’interface VPN est configurée avec une métrique agressivement basse, elle « gagnera » trop souvent.
Changements DNS. Vos serveurs DNS basculent vers des résolveurs d’entreprise qui ne peuvent pas résoudre les noms locaux (ou qui refusent délibérément), donc « nas » et « imprimante » cessent de se résoudre même si la connectivité IP est bonne.
Politique bloquant le LAN local. Certains clients VPN ajoutent intentionnellement des filtres (règles WFP) pour empêcher l’accès local pendant la connexion. Ce n’est pas du split tunneling ; c’est « pas de breakout local ».
IPv6 s’en est mêlé. Windows préfère IPv6 quand il est disponible. Un VPN qui ne gère que l’IPv4 alors que le LAN annonce IPv6 peut entraîner des comportements surprenants si vous ne savez pas quelles routes existent.

La solution n’est que rarement « activer le split tunneling » comme une case magique. La solution est : définir ce qui doit passer par le tunnel, définir ce qui doit rester local, puis l’appliquer avec des routes et un comportement DNS que vous pouvez expliquer à la prochaine personne de garde.

Neuf faits et anecdotes historiques pour les soirées (ou les appels d’incident)

Le split tunneling était controversé avant d’être tendance. Les premiers VPN d’entreprise préféraient le « full tunnel » parce que cela réduisait le risque de relier des réseaux d’entreprise et non fiables sur le même hôte.
Windows utilise la même logique de sélection de route depuis des décennies. Le match du préfixe le plus long l’emporte ; en cas d’égalité, la métrique la plus basse gagne. Les interfaces graphiques changent. Les règles ne changent pas.
« Utiliser la passerelle par défaut sur le réseau distant » était le piège UX original. Sur les anciens clients Windows, cette case décidait si le VPN installait une route 0.0.0.0/0 via le tunnel.
Les clients VPN d’entreprise ont commencé à pousser des routes agressivement à mesure que les réseaux grossissaient. Quand vous avez des dizaines de préfixes internes, il est plus simple de pousser des « routes de résumé ». C’est aussi ainsi que vous capturez accidentellement les sous-réseaux domestiques.
Always On VPN a transformé le split tunneling en problème de gouvernance. Une fois le VPN « toujours connecté », l’hygiène des routes et du DNS cesse d’être un bonus et devient la routine quotidienne.
Le DNS est le champ de bataille moderne. De nombreux programmes de sécurité se préoccupent davantage des fuites DNS que du routage brut, si bien que les clients VPN manipulent désormais le DNS de façons de plus en plus créatives.
NRPT existe parce que Windows a compris que le DNS a besoin de politique, pas d’espoir. Le Name Resolution Policy Table vous permet de dire « pour ces domaines, utilisez ces serveurs DNS », ce qui équivaut à du split tunneling pour le DNS.
L’auto-ajustement des métriques peut être « utile » jusqu’à ce que ce ne soit plus le cas. Windows peut attribuer automatiquement des métriques d’interface basées sur la vitesse du lien. Votre NIC virtuel VPN peut rapporter n’importe quoi et gagner les guerres de routage.
Le chevauchement des espaces IP privés est la tragédie de bureau qui dure. RFC1918 a donné à tout le monde les mêmes trois plages privées ; sans surprise, tout le monde a réutilisé les mêmes /24. Puis les VPN sont arrivés avec des routes de résumé et ont dévoré les réseaux domestiques au petit déjeuner.

Playbook de diagnostic rapide (vérifier premier/deuxième/troisième)

Si vous devez passer de « le VPN a cassé mon LAN » à la cause racine en cinq minutes, procédez dans cet ordre :

Premier : déterminer si c’est le routage ou le DNS

Tentez d’atteindre un appareil local par adresse IP (pas par nom). Si l’IP fonctionne mais pas le nom, vous êtes en zone DNS.
Si l’IP échoue, vous êtes en zone routage/pare-feu. Ne devinez pas ; lisez la table de routage.

Second : inspecter les routes qui pourraient capturer votre LAN

Cherchez 0.0.0.0/0 via VPN (full tunnel).
Cherchez des routes privées larges/de résumé poussées par le VPN (comme 192.168.0.0/16) qui chevauchent votre sous-réseau domestique.
Confirmez que la route du sous-réseau local existe toujours et a des métriques sensées.

Troisième : vérifier si le client VPN applique un blocage du LAN local

Certains clients installent des règles Windows Filtering Platform. Le routage peut être parfait et les paquets mourir quand même.
Vérifiez les règles de pare-feu actives, les changements de profil et si le profil « Public » s’est soudain appliqué.

Quatrième : vérifier les métriques d’adaptateur et la priorité d’interface

Si deux routes ont une spécificité similaire, la métrique décide. Une métrique VPN de 1 est essentiellement une opinion, et généralement la mauvaise.

Voilà votre échelle de triage : IP vs DNS, puis routes, puis filtres, puis métriques.

Tâches pratiques : commandes, sorties, décisions (12+)

Toutes celles-ci sont des « vraies tâches » : une commande, ce que la sortie signifie, et ce que vous faites ensuite. Utilisez un PowerShell élevé quand nécessaire. Vous n’êtes pas là pour cliquer ; vous êtes là pour contrôler le système.

Task 1: Identify whether name resolution is the only problem

cr0x@server:~$ ping 192.168.1.10
Pinging 192.168.1.10 with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.1.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Ce que cela signifie : La connectivité couche 3 vers l’appareil existe. Le routage vers le LAN est probablement correct.

Décision : Si « ping nas » échoue mais que le ping de son IP fonctionne, sautez les ajustements de route et passez directement aux tâches DNS.

Task 2: Prove the name lookup path (and which DNS server answered)

cr0x@server:~$ nslookup nas
Server:  corp-dns01.example
Address:  10.20.30.40

*** corp-dns01.example can't find nas: Non-existent domain

Ce que cela signifie : Votre système interroge le DNS corporate, qui ne connaît pas le nom « nas » de votre domicile.

Décision : Corrigez le comportement DNS split (NRPT, listes de suffixes, ou serveurs DNS locaux) plutôt que de bricoler les routes.

Task 3: Inspect the active interface configuration (spot the VPN takeover)

cr0x@server:~$ ipconfig /all

Ethernet adapter Ethernet:
   IPv4 Address. . . . . . . . . . : 192.168.1.50
   Default Gateway . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.1

PPP adapter CorpVPN:
   IPv4 Address. . . . . . . . . . : 10.99.12.34
   Default Gateway . . . . . . . . . : 10.99.12.34
   DNS Servers . . . . . . . . . . . : 10.20.30.40
   DNS Suffix Search List. . . . . . : corp.example

Ce que cela signifie : Le VPN s’annonce comme passerelle et pousse le DNS corporate. C’est typique d’un full tunnel (ou d’un split tunnel mal configuré).

Décision : Vérifiez la table de routage ensuite pour voir si 0.0.0.0/0 passe désormais via CorpVPN.

Task 4: Read the routing table like you mean it

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.99.12.34     10.99.12.34     5
        10.0.0.0        255.0.0.0       10.99.12.34     10.99.12.34     5
     192.168.1.0    255.255.255.0      192.168.1.50    192.168.1.50    25
===========================================================================

Ce que cela signifie : La route par défaut est via le VPN. La route du sous-réseau local existe toujours, donc le trafic local devrait rester local — sauf si une route plus large chevauche ou si un filtrage l’empêche.

Décision : Recherchez des routes qui chevauchent votre réseau domestique (comme 192.168.0.0/16) ou vérifiez si le client VPN bloque le LAN via le pare-feu/WFP.

Task 5: Look for the classic overlap route that eats your LAN

cr0x@server:~$ route print | findstr 192.168.
     192.168.0.0    255.255.0.0       10.99.12.34     10.99.12.34     5
     192.168.1.0    255.255.255.0      192.168.1.50    192.168.1.50    25

Ce que cela signifie : Vous avez à la fois 192.168.0.0/16 via le VPN et 192.168.1.0/24 local. Le /24 est plus spécifique, donc il devrait gagner. Mais si votre LAN est réellement 192.168.0.0/24, vous êtes dans l’embarras : le /16 du VPN l’emporte sur votre /24 local seulement si la route locale est manquante ou incorrecte.

Décision : Confirmez votre préfixe local réel et assurez-vous qu’une route locale explicite existe pour celui-ci. Si le VPN pousse une route qui correspond exactement à votre préfixe local, seules des modifications de politique (ou une renumérotation) le corrigeront proprement.

Task 6: Show which interface Windows will use to reach a local IP

cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 192.168.1.10 | ft -AutoSize"
DestinationPrefix NextHop     InterfaceAlias RouteMetric ifIndex PolicyStore
----------------- -------     -------------- ---------- ------ -----------
192.168.1.0/24    0.0.0.0     Ethernet       25         12     ActiveStore

Ce que cela signifie : Pour 192.168.1.10, Windows sélectionne Ethernet (local). Bien.

Décision : Si ceci montre l’interface VPN à la place, vous devez corriger la spécificité des routes ou les métriques (ou supprimer la route conflictuelle que le VPN a installée).

Task 7: Confirm whether the VPN connection is configured for split tunneling

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -Name 'CorpVPN' | Select-Object Name,SplitTunneling,RememberCredential,AuthenticationMethod | Format-List"
Name                 : CorpVPN
SplitTunneling       : False
RememberCredential   : True
AuthenticationMethod : MSChapv2

Ce que cela signifie : Le split tunneling est désactivé. Attendez-vous à une route par défaut via le VPN.

Décision : Si la politique le permet, activez le split tunneling puis ajoutez explicitement des routes corporate (et non l’inverse).

Task 8: Enable split tunneling (Windows built-in VPN)

cr0x@server:~$ powershell -NoProfile -Command "Set-VpnConnection -Name 'CorpVPN' -SplitTunneling $True -PassThru | Select-Object Name,SplitTunneling"
Name    SplitTunneling
----    --------------
CorpVPN True

Ce que cela signifie : Windows arrêtera de forcer une route par défaut via le VPN (selon la façon dont le serveur VPN pousse les routes). Vous devez maintenant ajouter des routes explicites vers les réseaux corporate.

Décision : Ajoutez immédiatement des routes pour les préfixes corporate (ou comptez sur les routes poussées si elles sont correctes). Vérifiez avec route print après reconnexion.

Task 9: Add an explicit route to a corporate subnet via the VPN interface

cr0x@server:~$ powershell -NoProfile -Command "Add-VpnConnectionRoute -ConnectionName 'CorpVPN' -DestinationPrefix '10.20.0.0/16' -PassThru | ft -AutoSize"
ConnectionName DestinationPrefix
-------------- -----------------
CorpVPN        10.20.0.0/16

Ce que cela signifie : Vous faites du split tunneling correctement : seul le trafic corporate va dans le tunnel.

Décision : Répétez pour tous les préfixes internes requis. N’ajoutez pas de grandes routes « au cas où » ; c’est ainsi que vous capturez à nouveau le LAN de l’utilisateur.

Task 10: Validate that default route is back to local gateway (after reconnect)

cr0x@server:~$ route print | findstr /c:" 0.0.0.0"
          0.0.0.0          0.0.0.0        192.168.1.1     192.168.1.50    10

Ce que cela signifie : Le trafic Internet/par défaut est à nouveau local. Le VPN doit uniquement gérer les préfixes que vous lui avez routés.

Décision : Si 0.0.0.0 pointe toujours vers le VPN, votre client/serveur applique le full tunnel. Ne luttez pas contre l’OS et passez à une politique « autoriser LAN local » ou aux paramètres du client (si disponibles).

Task 11: Inspect interface metrics (the silent tie-breaker)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceAlias,InterfaceMetric,NlMtu,ConnectionState | ft -AutoSize"
InterfaceAlias InterfaceMetric NlMtu ConnectionState
-------------- -------------- ----- ---------------
CorpVPN        5              1400  Connected
Ethernet       25             1500  Connected
Wi-Fi          55             1500  Disconnected

Ce que cela signifie : Le VPN a une métrique plus basse, donc s’il installe n’importe quelle route de spécificité similaire, il gagnera probablement.

Décision : Si le routage est instable, définissez des métriques explicites : augmentez la métrique du VPN ou baissez celle du LAN selon le cas. Attention : certains clients VPN réinitialisent les métriques à la connexion.

Task 12: Set an interface metric for the VPN adapter (when you control it)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'CorpVPN' -InterfaceMetric 50"

Ce que cela signifie : Pas de sortie est normale. Vous avez changé l’ordre de préférence.

Décision : Revérifiez avec Get-NetIPInterface puis Find-NetRoute. Si le client VPN continue de le modifier, vous avez besoin d’une politique côté client ou d’une configuration éditeur, pas de métriques bricolées à la main.

Task 13: Trace the packet path to a “local” host that fails

cr0x@server:~$ tracert 192.168.1.10

Tracing route to 192.168.1.10 over a maximum of 30 hops

  1    25 ms    24 ms    25 ms  10.99.12.34
  2     *        *        *     Request timed out.

Ce que cela signifie : Votre trafic « local » va dans le VPN (le premier saut est la passerelle/interface VPN). C’est un problème de routage, pas un problème d’imprimante.

Décision : Corrigez la table de routage : assurez-vous qu’il existe une route explicite « on-link » pour votre sous-réseau local via Ethernet/Wi‑Fi, et supprimez/évitez les routes VPN conflictuelles.

Task 14: Check whether Windows firewall profile flipped (and is blocking discovery/SMB)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | ft -AutoSize"
Name           InterfaceAlias NetworkCategory IPv4Connectivity IPv6Connectivity
----           -------------- --------------- ---------------- ---------------
HomeNetwork    Ethernet       Private         Internet         NoTraffic
CorpVPN        CorpVPN        Public          Internet         NoTraffic

Ce que cela signifie : L’interface VPN est en profil Public. Certains environnements provoquent aussi le passage du profil principal en Public, ce qui casse la découverte de fichiers/imprimantes et les règles entrantes.

Décision : Si votre profil LAN est devenu Public, corrigez la catégorie réseau (si la politique le permet) ou ajustez les règles de pare-feu pour les services requis (SMB, mDNS, LLMNR, WS-Discovery) avec soin.

Task 15: Inspect active firewall rules that might block local subnet while VPN is connected

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Outbound | ? DisplayName -match 'VPN|Block|Local' | Select-Object -First 8 DisplayName,Action,Profile | ft -AutoSize"
DisplayName                          Action Profile
-----------                          ------ -------
Block local subnets when VPN active  Block  Any

Ce que cela signifie : Le client VPN (ou la politique d’entreprise) a installé une règle de blocage explicite. Les ajustements de routage n’aideront pas.

Décision : Vous avez besoin d’une exception de politique (« autoriser l’accès LAN local »), d’une posture VPN différente, ou d’une conception réseau distincte et approuvée. Ne tentez pas d’appliquer des modifications de routes contre un blocage de pare-feu.

Task 16: Verify DNS servers and per-interface DNS assignment

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | ft -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {192.168.1.1}
CorpVPN        {10.20.30.40,10.20.30.41}

Ce que cela signifie : Le DNS est réparti par interface, mais le comportement du résolveur de Windows peut encore préférer le DNS corporate pour les noms à simple étiquette ou certaines recherches de suffixes.

Décision : Utilisez des FQDN pour les services corporate, configurez intentionnellement une liste de suffixes de recherche, ou utilisez NRPT pour que les domaines corporate aillent vers le DNS corporate tandis que tout le reste reste local.

Split tunneling sur Windows : comment ça marche vraiment

Le split tunneling signifie : seul le trafic destiné à des réseaux distants spécifiques passe par le VPN. Tout le reste — votre LAN local, votre sortie Internet domestique, l’interface web de l’imprimante — reste sur le réseau local.

Le full tunnel signifie : le VPN devient votre passerelle par défaut. C’est plus simple pour les équipes de sécurité (un point de contrôle unique), et parfois requis pour la conformité. C’est aussi comme essayer d’imprimer via un centre de données à des centaines de kilomètres.

Sur Windows, le split tunneling s’exprime finalement par des routes :

En full tunnel, vous obtenez 0.0.0.0/0 via VPN.
En split tunnel, vous obtenez seulement les préfixes corporate via VPN.
Les routes du sous-réseau local restent on-link (Ethernet/Wi‑Fi).

Trois modèles que vous verrez dans la nature

VPN intégré Windows (IKEv2/SSTP/L2TP) avec Set-VpnConnection
Fonctionne bien quand vous contrôlez les deux extrémités ou pouvez pousser des routes raisonnables. Bon pour les déploiements Always On VPN.
Client tiers qui injecte des routes et des règles de pare-feu
Vous pouvez parfois configurer le split tunnel dans le client, mais le client peut aussi appliquer un « blocage LAN local » avec des règles WFP. Lisez les paramètres du fournisseur ; n’assumez pas que les réglages Windows s’appliquent.
« Split tunnel » qui n’en est pas un
Certains environnements se disent split tunnel parce qu’ils excluent quelques services internet, mais envoient quand même toutes les plages privées via le tunnel. Ce n’est pas du split tunneling ; c’est de la misère sélective.

Ce que vous devriez faire, de manière opinionnée

Privilégiez le split tunneling basé sur les routes. Déclarez explicitement les préfixes corporate. Gardez-les aussi étroits que possible. Les routes de résumé sont acceptables seulement si vous maîtrisez le plan d’adressage et qu’il n’y a pas de chevauchement avec les utilisateurs.
Ne comptez pas sur la « magie des métriques ». Les métriques sont des départageurs, pas des outils de conception. Utilisez d’abord des préfixes explicites.
Supposez que les plages RFC1918 se chevaucheront. Si votre réseau corporate utilise 192.168.0.0/16, vous avez choisi de vous battre avec tous les routeurs domestiques de la planète.

Une citation à garder en tête lors des revues de conception VPN : idée paraphrasée de John Ousterhout : « La bonne ingénierie, c’est la gestion de la complexité. » La complexité du routage accumule toujours des intérêts.

DNS : la manière plus silencieuse dont les VPN cassent votre LAN

Le routage attire toute l’attention parce qu’il est visible : tables de routage, passerelles, nombres de sauts. Les échecs DNS ressemblent à des fantômes. Vous tapez \\nas et Windows hausse les épaules. Vous essayez \\192.168.1.10 et ça fonctionne. Ce n’est pas surnaturel ; c’est le résolveur qui fait ce pour quoi il est configuré.

Pourquoi le DNS du VPN cause des problèmes locaux

Le DNS corporate ne connaît pas vos noms locaux. Les noms à simple étiquette comme nas ou printer reposent souvent sur la recherche de suffixe locale, mDNS, LLMNR, ou le proxy DNS de votre routeur domestique.
Le DNS corporate peut bloquer volontairement certaines recherches privées. Les équipes de sécurité durcissent parfois les résolveurs pour refuser des requêtes « bizarres » des clients, y compris des patrons de reverse DNS locaux.
Windows peut préférer le DNS d’une interface pour certaines requêtes. Il existe un DNS par interface, mais le comportement de résolution dépend des suffixes, des politiques et si le client VPN règle la priorité d’interface.

Stratégie DNS pratique qui ne vous fera pas pleurer

Utilisez des FQDN pour les services corporate. Ne dépendez pas des recherches de suffixe pour les outils de production. C’est pratique jusqu’à ce que ça casse.
Utilisez NRPT pour envoyer les domaines corporate vers le DNS corporate. C’est un split tunneling propre pour les noms.
Gardez le DNS local pour les noms locaux. Si vous voulez que nas se résolve, votre système a besoin d’un résolveur qui le connaît (routeur domestique, serveur DNS local, fichier hosts en dernier recours).

Blague #1 : Le DNS, c’est comme un annuaire téléphonique, sauf qu’il a plus souvent tort et que vous continuez à l’appeler « infrastructure critique ».

NRPT et stratégies de résolution de noms (astuces Windows Pro)

NRPT (Name Resolution Policy Table) vous permet de dire : « Pour ces espaces de noms, utilisez ces serveurs DNS. » C’est la version adulte d’espérer que Windows choisisse la bonne interface DNS.

Schéma typique :

Pour corp.example et peut-être quelques zones internes, utilisez les serveurs DNS corporate accessibles via le VPN.
Pour tout le reste, continuez d’utiliser le DNS local (routeur domestique, FAI, ce que fournit votre LAN).

NRPT est généralement géré via la stratégie de groupe en entreprise. Mais pour le diagnostic, il est utile d’inspecter ce qui existe déjà.

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object Namespace,NameServers,DirectAccessDnsServers,Comment | ft -AutoSize"
Namespace      NameServers          DirectAccessDnsServers Comment
---------      ----------          ---------------------- -------
.corp.example  {10.20.30.40,10.20.30.41} {}

Ce que cela signifie : Les requêtes pour *.corp.example iront vers les serveurs DNS corporate listés.

Décision : S’il n’y a pas d’NRPT et que votre VPN détourne le DNS globalement, demandez un split DNS basé sur NRPT ou configurez « use default gateway on remote network » plus des politiques DNS explicites — selon la posture de sécurité de votre organisation.

Trois mini-récits d’entreprise depuis la tranchée

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (chevauchement d’espace d’adresses)

Une entreprise de taille moyenne a déployé un nouveau profil client VPN après une fusion. L’équipe réseau avait résumé les routes internes pour garder la configuration propre : un large préfixe privé poussé à tous les clients. Sur le papier, c’était élégant. En réalité, cela supposait que les employés n’avaient pas les mêmes plages RFC1918 chez eux.

Lundi matin, le support a été submergé. « Je ne peux pas imprimer », « je ne peux pas atteindre mon NAS domestique », « Zoom marche mais l’appli du thermostat ne marche plus », et la meilleure : « La console de jeu de mon enfant dit qu’elle est dans un autre pays. » Ce dernier n’était pas strictement la faute du VPN, mais n’aidait pas le moral.

Les premiers intervenants ont cherché des règles de pare-feu et des problèmes de pilote parce que le VPN se connectait et les applications corporate fonctionnaient. L’astuce a été de remarquer un motif : les échecs ciblaient toujours des appareils 192.168.0.0-ish. Les employés avec des réseaux domestiques 10.0.0.0/24 allaient plutôt bien.

Les tables de routage ont raconté l’histoire : une grande route 192.168.0.0/16 via le VPN, « parce que le corporate utilise beaucoup 192.168.* ». Les routeurs domestiques des employés utilisaient aussi… 192.168.*. Les paquets pour l’imprimante domestique passaient dans le tunnel, tombaient sur un routeur corporate qui n’avait aucune idée d’où était « l’HP LaserJet de Bob », et mouraient silencieusement.

La correction n’était pas brillante ; elle était responsable. Ils ont arrêté de pousser le préfixe large et ont poussé à la place des sous-réseaux corporate spécifiques. À plus long terme, ils se sont engagés à un plan d’adressage interne qui ne collide pas avec les defaults consommateurs. L’incident a pris fin quand ils ont remplacé une hypothèse par un inventaire.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (métriques et « VPN plus rapide »)

Une autre organisation avait une plainte de performance : « Le VPN est lent. » Quelqu’un a remarqué que l’interface VPN avait une métrique plus élevée que le Wi‑Fi, et a décidé « d’optimiser » en forçant la métrique du VPN à 1. Le changement a été déployé via un script. C’était rapide. C’était aussi faux.

Pour quelques utilisateurs, les applications corporate semblaient plus réactives. Pour beaucoup d’autres, les services locaux se sont dégradés de manière subtile : les copies de fichiers vers le NAS domestique ont commencé à échouer par timeout, les sauvegardes locales ont stagné, et les imprimantes sont devenues peu fiables. Pas complètement HS — assez pour générer des tickets sans cause évidente.

Ce qui s’est passé est classique : avec une métrique VPN très basse, Windows a préféré le VPN pour des routes qui n’étaient pas strictement définies, surtout quand plusieurs interfaces étaient actives (Ethernet et Wi‑Fi) et que certaines routes avaient la même spécificité. Ajoutez un peu de churn DHCP, et la sélection de route basculait aux pires moments.

Le rollback a corrigé le tir. Puis ils ont fait la version adulte : laisser les métriques principalement automatiques, activer correctement le split tunneling, et pousser des routes corporate explicites. La performance s’est améliorée pour les bonnes raisons : moins de trafic inutile dans le tunnel, moins de retransmissions, moins de flux locaux cassés.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (diagnostics standard et snapshots de routes)

Une équipe de services financiers avait une règle interne : tout incident d’accès distant reçoit un « snapshot réseau » attaché au ticket. Aucune exception. C’était ennuyeux. Les gens se sont plaints. Puis ça a payé encore et encore.

Quand un nouveau profil VPN a déclenché des rapports dispersés de « LAN inaccessible », l’ingénieur de garde n’a pas deviné. Il a comparé deux snapshots d’un utilisateur affecté : avant la connexion VPN et après. Le delta était évident : une route par défaut via le VPN et une nouvelle règle de blocage nommée exactement comme ce qu’elle faisait.

Parce qu’ils avaient des artefacts cohérents — ipconfig /all, route print, métriques d’interface, serveurs DNS — ils ont pu escalader avec précision : « Votre politique client installe des blocs sortants vers les sous-réseaux locaux à la connexion. Ce n’est pas un problème de route utilisateur. »

L’équipe sécurité a reconnu rapidement le problème parce que c’était mesurable, pas émotionnel. Ils ont créé un groupe d’exception approuvé pour les utilisateurs qui avaient besoin d’accès LAN local (environnements de lab, techniciens sur site) et documenté le risque. La pratique ennuyeuse — diagnostics reproductibles — a gardé le débat ancré sur des faits plutôt que des captures d’écran.

Erreurs courantes : symptôme → cause racine → correction

Cette section contient ce qui apparaît dans les tickets, les fils Slack et vos réunions préférées.

1) « VPN connecté, mais je n’accède pas à mon imprimante/NAS »

Symptôme : L’appareil local par nom échoue ; parfois l’IP échoue aussi.

Cause racine : Route par défaut full tunnel via le VPN, ou le VPN bloque le sous-réseau local via pare-feu/WFP.

Correction : Si autorisé, activez le split tunneling et ajoutez des routes corporate explicites. Si la politique bloque le LAN local, demandez le réglage « allow local LAN » ou un profil d’exception. Validez avec tracert et l’inspection des règles de pare-feu.

2) « Par IP ça marche, par nom ça échoue »

Symptôme : ping 192.168.1.10 fonctionne ; ping nas échoue.

Cause racine : Le DNS corporate est maintenant votre résolveur principal, et il ne peut pas résoudre les noms locaux.

Correction : Utilisez NRPT pour diriger les domaines corp vers le DNS corp. Gardez le DNS local pour les noms locaux. Ou utilisez des FQDN / entrées statiques quand c’est approprié.

3) « Certains IP locaux marchent, d’autres non »

Symptôme : On peut atteindre 192.168.1.1 mais pas 192.168.1.10 pendant le VPN.

Cause racine : Routes qui se chevauchent ou un route pushed de résumé capturant une partie du LAN, ou une règle de blocage ciblant des plages spécifiques.

Correction : Comparez Find-NetRoute pour les destinations qui marchent et celles qui ne marchent pas. Supprimez/évitez les routes VPN conflictuelles. Réduisez les préfixes corporate. Si c’est une règle de blocage, corrigez la politique plutôt que les routes.

4) « Les partages locaux disparaissent seulement en Wi‑Fi, pas en Ethernet »

Symptôme : Le comportement change selon le média d’accès.

Cause racine : Différents sous-réseaux locaux, différentes métriques, différents serveurs DNS, ou différents profils de pare-feu par interface.

Correction : Vérifiez Get-NetConnectionProfile et Get-NetIPInterface sur les deux interfaces. Standardisez les métriques et le DNS par interface. Confirmez les routes pour le préfixe local exact sur lequel vous êtes.

5) « Tout est lent après l’activation du split tunneling »

Symptôme : Applications corporate lentes, Internet OK.

Cause racine : Routes corporate manquantes, donc le trafic rebondit incorrectement (par ex. sort localement puis échoue en retour), ou les requêtes DNS pour les domaines corp vont vers des DNS publics puis timeout.

Correction : Ajoutez les bons préfixes corporate avec Add-VpnConnectionRoute et implémentez le split DNS (NRPT). Validez avec tracert vers des points corporate et nslookup pour des FQDN corporate.

6) « Le VPN marche, mais une seule appli interne est inaccessible »

Symptôme : La plupart des ressources corp fonctionnent ; un subnet ne fonctionne pas.

Cause racine : Le route pour ce subnet n’a pas été poussé/ajouté, ou il chevauche une plage locale et perd.

Correction : Find-NetRoute -RemoteIPAddress x.x.x.x pour ce serveur applicatif. Ajoutez une route spécifique via le VPN ou corrigez le chevauchement en renumérotant (oui, vraiment) ou en utilisant du NAT sur le concentrateur VPN.

7) « Après la connexion VPN, Windows dit que le réseau est Public et la découverte meurt »

Symptôme : Les appareils ne sont pas découvrables ; le navigation SMB échoue ; les règles entrantes ne correspondent plus.

Cause racine : La catégorie réseau est passée en Public, souvent déclenchée par le comportement de l’adaptateur VPN ou une confusion NLA.

Correction : Corrigez la catégorie réseau quand c’est permis, ou créez des règles de pare-feu explicites pour les services requis sur le bon profil. Ne désactivez pas simplement le pare-feu à moins d’aimer les audits.

Blague #2 : « Désactive juste le pare-feu » est l’équivalent réseau de réparer une voiture qui cliquette en montant le son de la radio.

Listes de contrôle / plan étape par étape (ennuyeux volontairement)

Étape par étape : corriger un profil VPN intégré Windows pour le split tunneling

Inventoriez ce qui doit passer par le VPN. Listez les préfixes et domaines corporate requis pour le travail. Si votre liste c’est « tout », vous faites du full tunnel et admettez-le.
Activez le split tunneling. Utilisez Set-VpnConnection -SplitTunneling $True.
Ajoutez des routes pour chaque préfixe corporate. Utilisez Add-VpnConnectionRoute par préfixe.
Reconnectez le VPN. Les changements de route s’appliquent souvent proprement après reconnexion.
Validez les routes. Confirmez que la route par défaut est locale et que les préfixes corporate routent vers le VPN.
Corrigez le comportement DNS. Utilisez NRPT pour les zones corporate. Assurez-vous que les noms locaux se résolvent toujours via le DNS local (ou passez aux FQDN).
Verrouillez les métriques uniquement si nécessaire. Si la sélection de route est instable, ajustez les métriques d’interface — mais attention aux réinitialisations par le client.
Documentez la décision. Le split tunneling est une posture de sécurité. Rendre le risque explicite et approuvé.

Checklist : quoi capturer pour un ticket reproductible « VPN casse le LAN »

Sous-réseau local (ex. 192.168.1.0/24), IP de la passerelle, et si Wi‑Fi/Ethernet
ipconfig /all avant et après connexion VPN
route print avant et après connexion VPN
Get-NetIPInterface (métriques) et Get-NetConnectionProfile (profil pare-feu)
Un test qui échoue par nom et par IP (ping nas et ping 192.168.1.10)
nslookup pour un FQDN corporate et un nom local
tracert vers une IP locale et une IP corporate
Toute option du client VPN libellée « block local network » / « allow LAN access »

FAQ

1) Pourquoi mon VPN tue l’accès aux appareils 192.168.1.x ?

Soit le VPN devient votre passerelle par défaut (full tunnel), soit il pousse des routes qui chevauchent votre sous-réseau domestique. Vérifiez route print et cherchez 0.0.0.0/0 via VPN ou de larges routes 192.168.0.0/16.

2) Le split tunneling est-il dangereux ?

Il peut l’être, si votre poste n’est pas géré ou si vous reliez sans contrôles des réseaux non fiables et l’accès corporate. Dans des environnements gérés, le split tunneling est courant avec des contrôles compensatoires (EDR, vérifications de posture, politiques DNS, VPN par application, identité forte). La sécurité est une conception, pas une case à cocher.

3) J’ai activé le split tunneling mais les applis corporate ont arrêté de fonctionner. Qu’ai-je raté ?

Vous avez probablement supprimé la route par défaut via le VPN sans ajouter les routes pour tous les préfixes corporate nécessaires, ou le DNS des domaines corp pointe toujours vers des résolveurs locaux. Ajoutez les routes manquantes et implémentez le split DNS (NRPT) pour les espaces de noms corporate.

4) Pourquoi `\\nas` échoue mais `\\192.168.1.10` fonctionne ?

Le DNS (ou LLMNR/mDNS) en est la cause. Votre VPN a probablement défini le DNS corporate comme prioritaire, et ce DNS ne peut pas résoudre vos noms locaux à simple étiquette. Corrigez avec NRPT, usage de FQDN, ou réglages DNS locaux.

5) Puis-je simplement ajouter une route statique pour mon sous-réseau domestique ?

Parfois. Si le VPN pousse une route conflictuelle, une route locale plus spécifique peut l’emporter. Mais si le VPN installe des blocs pare-feu ou si le conflit est exact (même longueur de préfixe), les routes statiques ne vous sauveront pas. De plus, beaucoup de clients VPN réappliquent les routes à la connexion.

6) Pourquoi le client VPN a-t-il un bouton « Allow LAN access » ?

Parce que certains clients bloquent intentionnellement les sous-réseaux locaux pendant la connexion pour éviter des risques split-horizon (comme un malware atteignant le corporate via un LAN compromis). Ce bouton contrôle généralement le comportement pare-feu/WFP, pas seulement les routes.

7) Qu’en est-il de l’IPv6 — dois-je la désactiver ?

Ne désactivez pas IPv6 comme première action. Inspectez d’abord les routes IPv6 et si le VPN supporte IPv6. Si vous avez de l’IPv6 sur le LAN et que le VPN ne gère que l’IPv4, vous pouvez vous retrouver avec une asymétrie étrange. Corrigez en assurant une politique cohérente : soit supportez IPv6 correctement, soit définissez comment le trafic IPv6 doit être traité.

8) Comment savoir si Windows envoie le trafic vers le VPN ou l’interface locale ?

Utilisez Find-NetRoute -RemoteIPAddress pour voir l’interface choisie pour une destination, et tracert pour confirmer le premier saut. Si le saut 1 est une passerelle/interface VPN, vous ne restez pas local.

9) Mon entreprise interdit le split tunneling. Suis-je coincé ?

Peut-être, mais vous avez des options : demandez une exception officielle « allow local LAN », utilisez un sous-réseau domestique non chevauchant (renumérotez votre LAN), ou utilisez un appareil séparé pour les ressources locales. Combattre la politique avec des routes bricolées perd généralement — et crée des incidents plus laids.

10) Pourquoi cela arrive-t-il plus souvent avec les réseaux domestiques qu’avec les réseaux de bureau ?

Les réseaux domestiques utilisent couramment des sous-réseaux consommateurs par défaut (192.168.0.0/24, 192.168.1.0/24). Les entreprises qui poussent de larges routes privées entrent en collision avec ces defaults. Les bureaux ont généralement des plans d’adressage gérés et moins de chevauchements — idéalement.

Conclusion : prochaines étapes que vous pouvez réellement faire aujourd’hui

Si votre VPN casse l’accès LAN local, arrêtez de le traiter comme un bug client mystérieux. C’est du routage, du DNS, ou de la politique — généralement dans cet ordre.

Exécutez le diagnostic rapide : testez par IP vs nom, puis inspectez les routes, ensuite cherchez des blocs pare-feu/WFP, enfin les métriques.
Prenez une décision : Si la politique le permet, implémentez un vrai split tunneling (routes corporate explicites). Si la politique l’interdit, demandez des exceptions « allow LAN » ou corrigez le chevauchement en renumérotant votre sous-réseau domestique.
Corrigez le DNS intentionnellement : NRPT pour les zones corporate, DNS local pour les noms locaux, et moins de noms à simple étiquette dans les workflows.
Standardisez les preuves : capturez ipconfig /all, route print, et les sorties PowerShell clés avant/après la connexion. Ça transforme les débats en ingénierie.

Faites-le une fois, documentez-le, et la prochaine fois que quelqu’un dira « le VPN a mangé mon imprimante », vous aurez une réponse meilleure qu’un soupir.