Vous perdez Internet dès que vous lancez le VPN d’entreprise sous Windows 10 ? Ce guide concret explique pourquoi cela arrive, comment le corriger (split‑tunneling, routage, DNS), et propose des pas‑à‑pas graphiques et PowerShell, plus une check‑list de diagnostic.
Perte d’accès Internet lorsqu’on se connecte au VPN d’entreprise
Vue d’ensemble de la question
Sur Windows 10 Pro (et souvent Windows 11), certains profils VPN imposés par l’employeur basculent tout le trafic réseau à travers la passerelle distante. Résultat : dès que vous vous connectez, la navigation Web et les applications Internet (navigateurs, Slack, etc.) ne démarrent plus, alors que les sessions déjà établies (Google Meet, Slack Huddle) continuent parfois à fonctionner un moment. C’est typique d’un défaut de routage par défaut et/ou d’une résolution DNS captée par le VPN.
Symptômes fréquents
- Les nouveaux onglets n’affichent rien, mais une visioconférence en cours continue.
- Les pings vers des adresses IP chiffrées (ex.
8.8.8.8) échouent uniquement après connexion VPN. nslookuprésout via des DNS internes non accessibles depuis Internet.- Les outils métier internes répondent, mais Outlook/Teams/Slack ne démarrent plus de nouvelles connexions.
Causes probables (en clair)
- Passerelle par défaut déplacée : l’option « Use default gateway on the remote network » force le default route
0.0.0.0/0vers le tunnel. Si la sortie Internet est filtrée côté entreprise, votre PC n’a plus de route valable vers le Web. - DNS forcés : le client VPN pousse des serveurs DNS internes qui ne résolvent pas les domaines publics (ou ne répondent pas depuis l’extérieur).
- Politiques “Force Tunnel” (MDM, GPO) : la stratégie d’entreprise interdit le split‑tunneling et coupe l’Internet local volontairement.
- Client propriétaire (AnyConnect, GlobalProtect, FortiClient…) : l’application ignore les cases Windows et applique sa propre politique de tunnelisation.
- Saturation/PoP : un point d’accès VPN surchargé provoque des pertes ou des timeouts sur les flux Web.
Réponses & solutions proposées
| Nº | Solution | Quand / Pourquoi l’utiliser | Étapes principales |
|---|---|---|---|
| 1 | Activer le split‑tunneling (désactiver « Use default gateway on the remote network ») | Le VPN force tout le trafic vers la passerelle distante ; si l’entreprise bloque l’accès Internet, votre PC n’a plus de sortie vers le Web. | 1. Panneau de configuration → Centre Réseau & partage → Modifier les paramètres de la carte. 2. Clic droit sur l’adaptateur VPN → Propriétés. 3. Onglet Réseau → double‑clic sur Protocole IPv4 → Avancé… 4. Onglet Paramètres IP → décochez « Utiliser la passerelle par défaut sur le réseau distant ». 5. Validez par OK. |
| 2 | Configurer le split‑tunneling via PowerShell (si l’option graphique n’apparaît pas) | Certains profils IKEv2/Always‑On ou anciennes builds (v1903…) masquent la case. | Exécuter en administrateur :Set-VpnConnection -Name "NomDuVPN" -SplitTunneling $True |
| 3 | Vérifier/mettre à jour Windows et le client VPN | Builds antérieures à 1909 ont parfois un dialogue IPv4 différent ; une mise à jour peut rétablir l’option manquante. | Paramètres → Windows Update → rechercher les mises à jour. |
| 4 | Alternative sans split‑tunneling (full‑tunnel) | Si l’administrateur refuse le split‑tunnel mais qu’Internet reste inaccessible en VPN. | • Demander à l’IT de : ➊ ouvrir la sortie HTTP/HTTPS au pare‑feu distant ; ➋ pousser des DNS publics ou un proxy transparent. • Vérifier localement la table de routage ( route print) et la résolution DNS (nslookup). |
| 5 | Changer de point de présence/port VPN (si disponible) | Peut contourner un point d’accès saturé ou filtré. | Cette option est rarement autorisée sur les VPN d’entreprise, mais à envisager si l’admin propose plusieurs passerelles. |
Tutoriels détaillés
Activer le split‑tunneling (interface graphique)
- Ouvrez le Panneau de configuration → Centre Réseau et partage → Modifier les paramètres de la carte.
- Faites un clic droit sur votre adaptateur VPN (par ex. « Connexion VPN Entreprise ») → Propriétés.
- Dans l’onglet Réseau, double‑cliquez sur Protocole Internet version 4 (TCP/IPv4) → bouton Avancé….
- Onglet Paramètres IP : décochez « Utiliser la passerelle par défaut sur le réseau distant ».
- Validez toutes les boîtes de dialogue par OK, puis Reconnectez le VPN.
Ce réglage supprime l’ajout automatique de la route par défaut 0.0.0.0/0 vers le tunnel. Votre Internet repasse par votre passerelle locale (box/routeur), tandis que seules les sous‑réseaux de l’entreprise utilisent le tunnel.
Activer le split‑tunneling (PowerShell)
Quand l’UI ne propose pas la case (profils IKEv2 Always‑On, builds anciennes, déploiement par GPO/MDM), PowerShell permet parfois de l’appliquer :
# Voir les connexions VPN connues
Get-VpnConnection
# Activer le split-tunneling sur le VPN nommé "NomDuVPN"
Set-VpnConnection -Name "NomDuVPN" -SplitTunneling $True
# (Facultatif) Si la connexion est au niveau machine (toutes sessions)
Set-VpnConnection -Name "NomDuVPN" -AllUserConnection -SplitTunneling $True Note : si la stratégie est verrouillée côté entreprise (GPO/MDM, profils “Force Tunnel”), la commande échouera ou sera ignorée. Dans ce cas, seule l’équipe IT peut modifier la politique.
Vérifier que tout fonctionne après modification
- Routage :
route printdoit montrer0.0.0.0/0vers votre passerelle locale (LAN/Wi‑Fi), et des routes spécifiques vers les sous‑réseaux internes (ex.10.0.0.0/8,172.16.0.0/12,192.168.0.0/16) via l’interface VPN. - DNS :
nslookup www.microsoft.comdoit répondre rapidement via un DNS public. Comparez avant/après :ipconfig /allaffiche les serveurs DNS attribués à chaque interface. - Connectivité IP :
ping 8.8.8.8puisping www.google.com. Le premier teste la route IP, le second ajoute la résolution DNS.
Diagnostic rapide (commandes utiles)
ping 8.8.8.8avant/après la connexion VPN : si le ping échoue seulement après, le routage par défaut via le tunnel est en cause.ipconfig /all: identifie les DNS utilisés sur chaque interface (LAN/Wi‑Fi/VPN).nslookup example.comouResolve-DnsName example.com(PowerShell) : détecte des résolutions lentes/erronées.route printouGet-NetRoute: visualise les routes et leur metric.Get-NetIPInterface: contrôle la priorité d’interface (métrique automatique vs manuelle).
Diagnostic avancé : routage, métriques, IPv6, DNS
Comprendre le « default route » et les métriques
Windows choisit l’interface avec la métrique la plus basse pour la route la plus précise. Quand le VPN ajoute une route par défaut (0.0.0.0/0) et une métrique plus faible que votre Wi‑Fi/Ethernet, tout l’Internet passe par le tunnel. Avec le split‑tunneling, cette route par défaut disparaît et seules des routes spécifiques (sous‑réseaux internes) restent.
Vous pouvez ajuster les métriques si nécessaire :
# Laisser Windows décider (souvent suffisant)
Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AutomaticMetric Enabled
# Forcer une priorité (plus petit = plus prioritaire)
Set-NetIPInterface -InterfaceAlias "Wi-Fi" -InterfaceMetric 25
Set-NetIPInterface -InterfaceAlias "MonVPN" -InterfaceMetric 50 IPv6 et fuites inattendues
Certains clients ajoutent une route par défaut IPv6 ::/0 via le tunnel. Si vous activez le split‑tunnel seulement pour IPv4, l’IPv6 peut continuer à passer par le VPN (ou être coupé). Vérifiez :
# Vérifier la route par défaut IPv6
Get-NetRoute -AddressFamily IPv6 | ? DestinationPrefix -eq '::/0' | ft -AutoSize
# Astuce prudente : si votre entreprise n'utilise pas IPv6 sur le VPN,
# désactivez IPv6 sur l'interface VPN (propriétés de la connexion)
DNS : qui résout quoi ?
Avec un split‑tunnel, il est logique d’utiliser des DNS publics pour Internet et de laisser les DNS internes résoudre les domaines de l’entreprise. Selon les clients, c’est automatique (Suffix Search List) ou à configurer. Vous pouvez définir manuellement des DNS sur l’interface Wi‑Fi/Ethernet (ex. 1.1.1.1, 8.8.8.8) et laisser le VPN pousser ses DNS internes :
# Exemple : définir des DNS publics sur l'interface Wi-Fi
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses 1.1.1.1,8.8.8.8
Important : ne modifiez pas les DNS si votre entreprise impose un proxy ou un filtrage DNS spécifique ; validez avec l’IT.
Cas particuliers selon le client VPN
| Client | Nom d’option pertinent | Comportement | Action conseillée |
|---|---|---|---|
| Cisco AnyConnect | « Allow Local LAN Access », « Tunnel All vs Network List Only » | Remplace les paramètres Windows. En « Tunnel All », Internet local est coupé. | Demander à l’IT un profil « Network List Only » (split) ou autoriser Local LAN. |
| Palo Alto GlobalProtect | « Enforce GlobalProtect for Network Access », « Split Tunnel » (Include/Exclude) | Peut imposer un full‑tunnel + proxy interceptant. | Voir avec l’IT la liste d’inclusion/exclusion et l’ouverture HTTP/HTTPS. |
| FortiClient | « Allow traffic to local LAN », Split‑tunnel par politique | Politique contrôlée par le FortiGate. | Demander un objet d’adresses internes précis pour éviter le full‑tunnel. |
| OpenVPN | Directives redirect-gateway, route, dhcp-option DNS | Le serveur peut pousser le full‑tunnel. | Retirer redirect-gateway côté serveur ou affiner les routes. |
| WireGuard | AllowedIPs | 0.0.0.0/0 = full‑tunnel. | Limiter AllowedIPs aux sous‑réseaux internes. |
Si votre client est géré (profil importé, stratégie verrouillée), toute modification locale peut être écrasée à la prochaine connexion. Dans ce cas, faites valider la solution par votre équipe IT.
Scénarios types & correctifs
Scénario A : Internet coupé, ressources internes OK
Probable : full‑tunnel + filtre sortant / DNS interne non autorisé. Correctifs : activer split‑tunnel (méthode 1/2) ou demander l’ouverture HTTP/HTTPS et/ou des DNS publics côté entreprise (méthode 4).
Scénario B : Les IP publiques répondent mais pas les noms de domaine
Probable : DNS internes poussés par le VPN ne résolvent pas Internet. Correctifs : positionner des DNS publics sur l’interface locale, conserver les DNS internes uniquement pour les domaines de l’entreprise (suffixes de recherche, règles de split‑DNS).
Scénario C : Tout est lent ou intermittent
Probable : PoP VPN saturé, path MTU problématique, inspection TLS. Correctifs : tester un autre point/port (443/UDP vs 1194/UDP vs 443/TCP si proposé), vérifier MTU (ping -f -l 1472 8.8.8.8 pour calibrer), contacter l’IT.
Notes & astuces importantes
- Sécurité : le split‑tunneling laisse sortir le trafic Internet hors du tunnel. Vérifiez qu’aucune politique interne ne l’interdit.
- Scripts automatisés : vous pouvez intégrer
Set-VpnConnection -SplitTunneling $Truedans un script de connexion (rasdial) pour éviter une manipulation manuelle. - Cas où la case est grisée/absente : le profil VPN peut être géré par stratégie de groupe/MDM (Force Tunnel) ou par un client propriétaire (AnyConnect, GlobalProtect, etc.) qui remplace les paramètres Windows. Cherchez l’option « Allow local LAN » ou l’équivalent dans le client, ou contactez le support interne.
- Compatibilité : bien que l’exemple cible Windows 10, les écrans sont similaires sous Windows 11.
Alternative full‑tunnel conforme (sans split)
Si la politique de l’entreprise impose un full‑tunnel (et c’est fréquent), Internet doit rester utilisable à travers l’infrastructure distante. Pour cela, l’équipe IT doit :
- Autoriser la sortie HTTP/HTTPS au pare‑feu distant pour les utilisateurs VPN.
- Fournir des DNS publics (ou un proxy transparent) pour résoudre les domaines Internet.
- Éviter de pousser des DNS internes exclusifs pour tous les suffixes (sinon la résolution publique échoue).
De votre côté, vérifiez avec route print que la route 0.0.0.0/0 pointe sur le tunnel et que la navigation est possible. Si non, seul l’IT peut corriger côté infrastructure.
FAQ
Le split‑tunneling est‑il sécurisé ?
Il réduit l’inspection centralisée du trafic Internet par l’entreprise. Certaines organisations l’interdisent pour limiter les risques (exfiltration, attaques latérales). Demandez la politique sécurité avant d’activer cette option.
Pourquoi mes réunions en cours continuent‑elles à fonctionner ?
Parce que les flux existants restent établis via l’ancienne route/NAT. Les nouveaux flux (onglets, connexions) doivent choisir une route : avec un default route mal configuré ou un DNS non fonctionnel, ils échouent.
Faut‑il désactiver IPv6 ?
Pas forcément. Il suffit souvent de s’assurer que la route ::/0 n’est pas capturée par le VPN si ce n’est pas souhaité, ou que le client gère correctement le split‑DNS v6.
Comment vérifier que je n’ai pas de “DNS leak” ou l’inverse ?
Exécutez nslookup monsite.fr et observez quel serveur répond. Vous pouvez aussi tester un domaine interne (ex. intranet.local) : il doit se résoudre via les DNS internes uniquement.
Mon administrateur refuse le split‑tunnel. Que puis‑je faire ?
Suivez la section « Alternative full‑tunnel conforme ». En tant qu’utilisateur, vous n’avez pas la main sur le pare‑feu distant ni le proxy ; seul l’IT peut corriger.
Modèles de scripts utiles
Activer le split‑tunnel + vérifier les routes (PowerShell)
# 1) Activer le split-tunneling
$vpn = "NomDuVPN"
Set-VpnConnection -Name $vpn -SplitTunneling $True -ErrorAction SilentlyContinue
# 2) Forcer des DNS publics sur l'interface Wi-Fi (adaptez si nécessaire)
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses 1.1.1.1,8.8.8.8
# 3) Afficher les routes pertinentes
"--- Routes par défaut ---"
Get-NetRoute -AddressFamily IPv4 | ? DestinationPrefix -eq "0.0.0.0/0" | ft ifIndex,InterfaceAlias,NextHop,RouteMetric -AutoSize
"--- Routes vers l'interne ---"
Get-NetRoute -AddressFamily IPv4 | ? DestinationPrefix -match "^(10.|172.(1[6-9]|2[0-9]|3[0-1]).|192.168.)" | ft DestinationPrefix,NextHop,InterfaceAlias -AutoSize Ajouter des routes spécifiques si l’IT les fournit
# Exemple : envoyer 10.20.0.0/16 via l'interface VPN
# (récupérez l'Index de l'interface avec Get-NetIPInterface)
$if = (Get-NetIPInterface | ? InterfaceAlias -eq "MonVPN").ifIndex
New-NetRoute -DestinationPrefix "10.20.0.0/16" -InterfaceIndex $if -NextHop 0.0.0.0
Ne créez des routes statiques que si votre équipe IT vous donne les préfixes officiels. Des routes incorrectes peuvent couper l’accès à des services.
Checklist « résoudre vite »
- Avant de connecter le VPN, notez
ipconfig /alletroute print. - Connectez le VPN, refaites
ipconfig /alletroute print; comparez. - Test IP :
ping 8.8.8.8. Si KO, problème de default route. - Test DNS :
nslookup www.google.com. Si KO, basculez des DNS publics sur l’interface locale (si autorisé). - Appliquez le split‑tunneling (UI ou PowerShell) si la politique le permet.
- Si interdit, demandez à l’IT : ouverture HTTP/HTTPS sortante + DNS publics côté tunnel.
- En cas de lenteur, testez un autre PoP/port si l’IT le propose.
Conclusion
Dans la grande majorité des cas, la perte d’Internet après connexion au VPN d’entreprise vient d’un routage par défaut et/ou de DNS mal adaptés à votre usage. Deux approches existent : 1) split‑tunneling côté poste (quand la politique le permet) ; 2) full‑tunnel fonctionnel géré par l’IT (HTTP/HTTPS et DNS publics au pare‑feu distant). Avec les étapes ci‑dessus — UI, PowerShell, vérifications de routes et de DNS — vous pouvez rétablir une navigation normale tout en conservant l’accès aux ressources internes, en conformité avec les règles de l’entreprise.
Informations complémentaires utiles
- Sécurité : le split‑tunneling laisse sortir le trafic Internet en clair hors du tunnel ; assurez‑vous qu’aucune politique interne ne l’interdit.
- Diagnostic rapide :
ping 8.8.8.8avant/après connexion ; si le ping échoue uniquement après connexion, le routage par défaut est bien en cause.ipconfig /allpour comparer les serveurs DNS attribués par le VPN.
- Scripts automatisés : il est possible d’intégrer
Set-VpnConnection -SplitTunneling $Truedans un script de connexion (rasdial) pour éviter une manipulation manuelle. - Cas où la case est grisée ou absente :
- Le profil VPN est géré par une stratégie de groupe ; seul l’administrateur peut activer le split‑tunnel.
- Le client utilise un protocole propriétaire (Cisco AnyConnect, GlobalProtect, etc.) qui remplace les paramètres Windows. Dans ce cas, cherchez l’option « Allow local LAN » ou équivalent dans le client, ou contactez le support interne.
- Retour d’expérience : en appliquant l’une des méthodes 1 ou 2, la plupart des utilisateurs constatent un rétablissement quasi immédiat de l’accès Internet tout en conservant l’accès aux ressources internes.