VPN connecté mais pas d’accès Internet sous Windows : liste de contrôle des routes et métriques

Playbook de diagnostic rapide

Quand quelqu’un vous dit « VPN connecté mais pas d’Internet », vous ne voulez pas une discussion philosophique sur le tunneling. Vous voulez un arbre de décision qui se termine
par une réparation ou une cause racine escaladable. Voici le chemin rapide.

Première étape : confirmez ce que signifie vraiment « pas d’internet »

• Pouvez‑vous pinguer une IP ? Si ping 1.1.1.1 fonctionne mais les sites web non, vous avez un problème de DNS, pas d’Internet.
• Pouvez‑vous résoudre des noms ? Si nslookup échoue ou résout en adresses internes uniquement, c’est la sélection du serveur DNS, NRPT, ou le suffixe DNS de recherche.
• Pouvez‑vous atteindre des ressources internes ? Si l’interne fonctionne mais l’externe non, vous avez probablement un tunnel forcé / route par défaut via le VPN sans egress.
• Tout échoue ? Si à la fois interne et externe échouent, suspectez la sélection de route, des problèmes de métrique d’interface, ou des blocages par firewall/WFP.

Deuxième étape : vérifiez les routes par défaut et les métriques

La plupart des incidents « connecté mais mort » sur Windows se résument à : la mauvaise route par défaut (0.0.0.0/0) a gagné, ou elle a gagné avec une métrique qui semblait « raisonnable »
pour un ordinateur et insensée pour un humain.

• Inspectez les routes : route print ou Get-NetRoute.
• Identifiez quelle interface possède la route par défaut et quelle métrique elle a.
• Décidez si vous voulez full tunnel (tout le trafic via le VPN) ou split tunnel (seuls les sous‑réseaux d’entreprise via le VPN).

Troisième étape : validez le chemin DNS et la politique

• Quels serveurs DNS sont utilisés ? Get-DnsClientServerAddress.
• NRPT pousse‑t‑il des domaines spécifiques vers le DNS du VPN ? Get-DnsClientNrptPolicy.
• Le serveur DNS du VPN est‑il joignable via la route sélectionnée ? Sinon, la résolution de noms meurt en premier.

Quatrième étape : prouvez le chemin avec tracert et liaisons d’interface

• tracert -d 1.1.1.1 montre quelle passerelle vous utilisez réellement.
• Test-NetConnection vous indique si c’est du routage, du DNS, ou un filtrage spécifique par port.

Cinquième étape : décidez où corriger

Si vous êtes utilisateur : vous pouvez ajuster les métriques, basculer les options de split tunneling, ou corriger le DNS. Si vous êtes l’opérateur du VPN : vous devez livrer une configuration sensée qui
n’usurpe pas les routes par défaut sans fournir d’egress et de DNS.

Votre modèle mental : routes, métriques, DNS et « connecté »

« Connecté » signifie que le tunnel est établi, pas que l’Internet est accessible

Les clients VPN indiquent « connecté » quand le plan de contrôle est heureux : authentification réussie, interface de tunnel existante, échange de clés, keepalives répondus.
Ce n’est pas le plan de données. Le plan de données, c’est là où vos paquets vivent ou meurent.

Windows acceptera volontiers un adaptateur VPN, installera des routes, puis enverra votre trafic dans un trou noir si ces routes pointent vers une passerelle qui ne peut pas ou ne doit pas
transférer vos paquets. Ce n’est pas que Windows soit idiot ; c’est Windows qui obéit.

Windows choisit une route selon la longueur du préfixe, puis la métrique

La sélection de route est en grande partie déterministe :

1. Le préfixe le plus long l’emporte. Un /32 bat un /24 qui bat un /0. Si votre VPN installe des routes spécifiques pour des réseaux d’entreprise, elles doivent l’emporter sur votre route par défaut locale.
2. Puis la métrique l’emporte. Si deux routes ont la même longueur de préfixe, Windows utilise la plus faible route metric, et il prend aussi en compte la métrique d’interface.
3. Puis ça devient corsé. Windows peut considérer « métrique automatique », la vitesse d’interface, et parfois des mises à jour ou des rebinds peuvent réordonner les choses de façon inattendue.

C’est pourquoi « l’internet meurt quand le VPN se connecte » signifie souvent : une nouvelle route 0.0.0.0/0 est arrivée via le VPN avec une métrique plus faible que votre route par défaut Wi‑Fi,
mais votre headend VPN ne fournit pas d’egress Internet (ou le bloque volontairement). Résultat : full‑tunnel sans sortie fonctionnelle.

Le DNS est un plan de panne séparé, et il échoue plus bruyamment

Les humains expérimentent Internet via des noms, pas des IP. Les problèmes DNS apparaissent comme « pas d’internet » même quand le routage est correct. Windows ajoute de la complexité ici :

• Plusieurs interfaces peuvent avoir des serveurs DNS ; Windows choisit selon les métriques d’interface et les politiques de suffixe.
• Les clients VPN peuvent pousser des résolveurs DNS internes et des suffixes de recherche.
• NRPT (Name Resolution Policy Table) peut forcer certains domaines (ou tous) vers des serveurs DNS spécifiques.
• DNS over HTTPS peut contourner votre plan DNS VPN et créer un comportement split‑brain déroutant.

Le split tunneling est une décision de politique, pas une technique de dépannage

Les gens activent/désactivent le split tunneling comme s’il s’agissait d’un « éteindre/rallumer ». Parfois ça marche, mais ce n’est pas magique. Cela change votre table de routage et votre modèle de menace.
Si votre politique de sécurité exige le full tunnel, alors la « correction » consiste à rendre le full tunnel opérationnel (y compris egress Internet ou blocages explicites avec message utilisateur),
pas à activer discrètement le split tunnel parce que ça semble mieux.

Blague n°1 : le routage VPN, c’est comme la politique de bureau : la personne avec la métrique la plus basse gagne, et personne n’admet qui l’a définie.

Faits et historique à connaître (parce que Windows n’a pas inventé le chaos)

• Le leg de PPP et du dial‑up compte toujours. Le comportement VPN de Windows hérite d’hypothèses des liens PPP où « réseau distant » signifiait souvent « l’utiliser comme passerelle par défaut ».
• Les débats sur le split tunneling datent. Les entreprises en discutaient il y a des décennies pour le dial‑up et l’IPSec : la sécurité veut le full tunnel ; les opérations veulent un egress prévisible.
• La métrique automatique était censée aider. Windows a introduit les métriques d’interface automatiques pour privilégier les liens « plus rapides », mais les adaptateurs virtuels peuvent perturber cette heuristique.
• NRPT vient des besoins de l’époque DirectAccess. Microsoft avait besoin d’un moyen de résoudre les domaines d’entreprise via le DNS d’entreprise tout en laissant les domaines publics tranquilles — routage DNS basé sur des règles.
• IPv6 n’a pas « cassé » les VPN ; c’est son adoption partielle qui cause des problèmes. Beaucoup de VPN sont IPv4-only, tandis que Windows préfère IPv6 quand il est disponible ; le décalage crée des connectivités partielles étranges.
• Le suffixe de recherche DNS est plus ancien que le web. Il a été conçu pour le nommage en entreprise, et il est encore responsable de beaucoup d’incidents « pourquoi ça résout mal ? ».
• WFP a rendu le filtrage plus puissant. Windows Filtering Platform permet aux clients VPN et aux agents endpoint d’appliquer des politiques réseau ; cela peut aussi bloquer silencieusement le trafic.
• NCSI n’est pas l’Internet. Le statut « Pas d’accès Internet » de Windows se base sur des probes et des heuristiques ; vos paquets peuvent être corrects pendant que l’icône se plaint, ou l’inverse.

Tâches pratiques : commandes, ce que la sortie signifie, et ce que vous décidez

Ce sont les actions qui séparent « j’ai redémarré » de « j’ai réparé ». Chaque tâche contient :
une commande, un exemple de sortie réaliste, ce que cela signifie, et la décision que vous prenez.

Tâche 1 : Confirmer l’inventaire des interfaces et leur état

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,Name | Format-Table -Auto Name,Status,LinkSpeed,InterfaceDescription"
Name                      Status LinkSpeed  InterfaceDescription
Wi-Fi                     Up     866.7 Mbps Intel(R) Wi-Fi 6 AX201 160MHz
Ethernet                  Down   0 bps      Realtek PCIe GbE Family Controller
Wintun Userspace Tunnel   Up     1 Gbps     WireGuard Tunnel
TAP-Windows Adapter V9    Down   0 bps      TAP-Windows Adapter V9

Sens : Vous avez au moins deux adaptateurs « Up » : le Wi‑Fi et le tunnel VPN.
C’est normal. Ce qui compte, c’est lequel possède la route par défaut et le DNS.

Décision : Si l’adaptateur VPN est Down, stoppez ici : vous avez un problème d’établissement/authentification du tunnel, pas un « pas d’internet ». S’il est Up, poursuivez vers les routes.

Tâche 2 : Afficher la table de routage en termes compréhensibles

cr0x@server:~$ powershell -NoProfile -Command "route print"
===========================================================================
Interface List
 12...18 56 80 1a 2b 3c ......Intel(R) Wi-Fi 6 AX201 160MHz
 34...00 ff 12 34 56 78 ......Wintun Userspace Tunnel
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.8.0.1        10.8.0.2       5
          0.0.0.0          0.0.0.0   192.168.1.1    192.168.1.123    25
        10.8.0.0    255.255.255.0         On-link       10.8.0.2     261
     192.168.1.0    255.255.255.0         On-link   192.168.1.123    281
===========================================================================

Sens : Vous avez deux routes par défaut. La route par défaut du VPN a la métrique 5, donc elle gagne. C’est maintenant du full tunnel.
Si le serveur VPN ne réalise pas de NAT/egress vers Internet, votre Internet est effectivement coupé.

Décision : Décidez la politique : si le full tunnel est prévu, vérifiez que la passerelle VPN fournit un egress Internet et l’autorise. Si le split tunnel est prévu, supprimez la route par défaut VPN et ajoutez seulement les routes corp pour le trafic d’entreprise.

Tâche 3 : Identifier précisément la route par défaut gagnante (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object -Property RouteMetric,InterfaceMetric | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,InterfaceMetric,PolicyStore"
ifIndex InterfaceAlias           NextHop      RouteMetric InterfaceMetric PolicyStore
34      Wintun Userspace Tunnel  10.8.0.1              5             10 ActiveStore
12      Wi-Fi                    192.168.1.1          25             25 ActiveStore

Sens : L’interface VPN (ifIndex 34) est la route par défaut préférée.
La métrique d’interface compte aussi ; Windows additionne/compare d’une manière qui surprend encore les gens.

Décision : Si vous avez besoin d’Internet local quand le VPN est connecté, vous devez soit augmenter les métriques du VPN, désactiver « use default gateway on remote network », ou configurer correctement le split tunneling.

Tâche 4 : Confirmer votre IP d’egress publique avant/après le VPN

cr0x@server:~$ powershell -NoProfile -Command "curl.exe -s ifconfig.me; echo"
203.0.113.44

Sens : C’est votre IP publique d’egress. Exécutez-le à nouveau après la connexion au VPN. Si elle change pour une plage d’egress d’entreprise, le full tunnel est actif et l’egress fonctionne.
Si ça bloque, votre routage envoie le trafic dans un tunnel sans sortie.

Décision : Si la commande bloque seulement quand le VPN est connecté, concentrez‑vous sur la route par défaut et la politique d’egress/NAT du VPN.

Tâche 5 : Prouvez si le problème est DNS ou routage (ping IP vs nom)

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 1.1.1.1"
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=17ms TTL=57
Reply from 1.1.1.1: bytes=32 time=16ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 www.microsoft.com"
Ping request could not find host www.microsoft.com. Please check the name and try again.

Sens : La connectivité IP existe ; la résolution DNS échoue. Ce n’est pas « pas d’internet », c’est « pas de résolveur joignable » ou « la politique envoie le DNS au mauvais endroit ».

Décision : Arrêtez de toucher aux routes pour un moment. Inspectez les serveurs DNS, les règles NRPT, et si les requêtes DNS sortent via l’interface attendue.

Tâche 6 : Inspecter les serveurs DNS par interface

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias           ServerAddresses
Wi-Fi                    {192.168.1.1}
Wintun Userspace Tunnel  {10.8.0.53, 10.8.0.54}

Sens : Le Wi‑Fi utilise le DNS du routeur domestique. Le VPN pousse des résolveurs internes. Selon la politique, Windows peut préférer le DNS VPN pour tout,
ou utiliser un comportement multi‑homing intelligent qui n’est pas toujours si intelligent.

Décision : Si le DNS du VPN est réservé à l’interne et que vous êtes en full‑tunnel sans egress, les noms publics échouent. Soit fournissez l’egress, soit configurez un split DNS (NRPT) pour que les noms publics aillent vers des résolveurs publics.

Tâche 7 : Vérifier les politiques NRPT (routage DNS par domaine)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object -First 5 | Format-List"
NameSpace : .corp.example
NameServers : 10.8.0.53,10.8.0.54
DirectAccessDnsServers :
DnsSecValidationRequired : False
Comment : VPN policy

NameSpace : .
NameServers : 10.8.0.53

Sens : Si vous voyez une règle pour NameSpace : ., c’est « tous les domaines ». Elle force toutes les requêtes DNS vers le résolveur VPN.
Cela peut être correct pour le full tunnel ; c’est horrible pour le split tunnel si le DNS du VPN ne peut pas résoudre les domaines publics ou est injoignable.

Décision : Si le split tunnel est prévu, supprimez la règle NRPT catch‑all et conservez seulement les namespaces d’entreprise.

Tâche 8 : Valider explicitement la résolution DNS et voir quel serveur répond

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName www.microsoft.com -Type A | Select-Object -First 3"
Name                                     Type TTL   Section IPAddress
----                                     ---- ---   ------- ---------
www.microsoft.com                        A    20    Answer  184.25.56.101

cr0x@server:~$ powershell -NoProfile -Command "nslookup www.microsoft.com 10.8.0.53"
Server:  vpn-dns-1
Address:  10.8.0.53

*** vpn-dns-1 can't find www.microsoft.com: Non-existent domain

Sens : Le serveur DNS interne ne résout pas les domaines publics (par conception ou erreur). Si Windows envoie tout le trafic DNS là‑bas, la navigation meurt.

Décision : Configurez soit le DNS VPN pour qu’il relaie les requêtes publiques, soit arrêtez de forcer le DNS public à passer par lui.

Tâche 9 : Prouvez quel chemin prennent vos paquets (tracert sans DNS)

cr0x@server:~$ powershell -NoProfile -Command "tracert -d 1.1.1.1"
Tracing route to 1.1.1.1 over a maximum of 30 hops

  1    35 ms    34 ms    36 ms  10.8.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

Trace complete.

Sens : Le saut 1 est la passerelle VPN, puis plus rien. C’est le classique « route par défaut via le VPN, mais le VPN ne forwarde pas vers Internet »
(ou il bloque l’ICMP au‑delà de la passerelle, mais vous verrez généralement des échecs pour le TCP aussi).

Décision : Confirmez si le VPN est censé fournir un egress Internet. Sinon, retirez la route par défaut et passez en split tunnel.

Tâche 10 : Tester la connectivité TCP vers un endpoint connu et capturer l’interface utilisée

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 8.8.8.8 -Port 53 -InformationLevel Detailed"
ComputerName           : 8.8.8.8
RemoteAddress          : 8.8.8.8
RemotePort             : 53
InterfaceAlias         : Wintun Userspace Tunnel
SourceAddress          : 10.8.0.2
TcpTestSucceeded       : False
PingSucceeded          : True

Sens : Le ping ICMP fonctionne mais le TCP/53 échoue. Cela peut être une politique sur le VPN (blocage sortant), un problème de firewall stateful, ou des problèmes MTU/fragmentation.

Décision : Si l’interface est le tunnel VPN et que les ports sortants sont bloqués, vous avez besoin d’un changement de politique VPN (ou du split tunnel) plutôt que de bidouilles côté client.

Tâche 11 : Vérifier le MTU sur l’interface VPN (tueur silencieux)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceAlias | Format-Table -Auto InterfaceAlias,NlMtu,InterfaceMetric,Dhcp"
InterfaceAlias           NlMtu InterfaceMetric Dhcp
Wi-Fi                    1500              25 Enabled
Wintun Userspace Tunnel  1420              10 Disabled

Sens : MTU 1420 est courant pour WireGuard ; IPSec et certains VPN SSL vont plus bas. Si le MTU est incorrect, vous obtenez « certains sites fonctionnent, d’autres bloquent »,
surtout HTTPS avec de plus gros paquets.

Décision : Si les symptômes sont partiels (petits pings fonctionnent ; gros transferts bloquent), testez avec un MTU plus petit ou clamperez le MSS côté passerelle VPN.

Tâche 12 : Confirmer les routes IPv6 et si IPv6 vole le trafic

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv6 -DestinationPrefix '::/0' | Format-Table -Auto InterfaceAlias,NextHop,RouteMetric,InterfaceMetric"
InterfaceAlias           NextHop              RouteMetric InterfaceMetric
Wi-Fi                    fe80::1                     10             25
Wintun Userspace Tunnel  ::                          256             10

Sens : La route par défaut IPv6 via le Wi‑Fi existe et est préférée. Si votre « pas d’internet » n’apparaît que pour certaines applis, elles essaient peut‑être IPv6 en premier.
Pendant ce temps le VPN est IPv4-only et votre DNS d’entreprise peut retourner des enregistrements AAAA qui échouent.

Décision : Si l’accès corporate casse parce que les clients préfèrent IPv6 qui ne traverse pas le VPN, fournissez IPv6 sur le VPN, ou contrôlez les réponses DNS / désactivez IPv6 sur la conception du tunnel (pas en réflexe).

Tâche 13 : Inspecter les paramètres proxy WinHTTP (oui, toujours)

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.8.0.20:8080
    Bypass List     : (none)

Sens : Certains scripts post‑connexion VPN configurent un proxy. Si ce proxy n’est atteignable que via le VPN et que votre routage VPN est cassé, les navigateurs peuvent échouer de façons déroutantes.
Certaines applis utilisent WinHTTP ; d’autres WinINET ; ils peuvent être en désaccord.

Décision : Si Internet est mort seulement pour certaines applis (ou seulement les services système), corrigez l’accès au proxy ou supprimez le proxy WinHTTP s’il est obsolète.

Tâche 14 : Vérifier le réglage Windows « use default gateway on remote network » (RAS/VPN)

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -AllUserConnection | Select-Object Name,SplitTunneling,RememberCredential | Format-Table -Auto"
Name              SplitTunneling RememberCredential
----              -------------- ------------------
Corp-VPN          False          True

Sens : SplitTunneling False implique généralement full tunnel (route par défaut via le VPN). C’est acceptable si votre VPN est conçu pour cela.
C’est catastrophique si le headend est « interne uniquement ».

Décision : Changez‑le seulement si la politique le permet. Si vous êtes opérateur, corrigez le profil VPN et la méthode de distribution plutôt que de demander aux utilisateurs de le modifier manuellement.

Tâche 15 : Ajuster la métrique d’interface (chirurgical, mais parfois nécessaire)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Wi-Fi' -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Wintun Userspace Tunnel' -InterfaceMetric 50"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -in @('Wi-Fi','Wintun Userspace Tunnel')} | Format-Table -Auto InterfaceAlias,InterfaceMetric"
InterfaceAlias           InterfaceMetric
Wi-Fi                                10
Wintun Userspace Tunnel              50

Sens : Vous avez dit à Windows de préférer le Wi‑Fi lorsque les routes sont en compétition.
C’est un outil brutal et cela peut violer la politique full‑tunnel si vous n’êtes pas prudent.

Décision : Utilisez les métriques pour résoudre des conflits de priorité de route, pas pour « contourner la sécurité ». Si votre entreprise exige le full tunnel, ne diffusez pas de « hacks de métrique » comme solution de support.

Tâche 16 : Ajouter une route split‑tunnel spécifique (exemple pour un sous‑réseau corp)

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '10.20.0.0/16' -InterfaceAlias 'Wintun Userspace Tunnel' -NextHop '0.0.0.0' -RouteMetric 5"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '10.20.0.0/16' | Format-Table -Auto DestinationPrefix,InterfaceAlias,NextHop,RouteMetric"
DestinationPrefix InterfaceAlias           NextHop  RouteMetric
10.20.0.0/16       Wintun Userspace Tunnel  0.0.0.0          5

Sens : Vous routez explicitement uniquement le sous‑réseau corporate dans le tunnel.
Pour beaucoup de technologies VPN, le next hop « on‑link » (0.0.0.0) est correct parce que l’interface de tunnel elle‑même est le chemin.

Décision : Si le client VPN ne gère pas les routes de façon fiable, vous pouvez pinger des routes critiques. Mais préférez corriger la configuration poussée de façon centrale ; la dérive fait que le vous du futur reçoit des pages.

Tâche 17 : Vérifier les connexions actives et les adresses source liées

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Established | Select-Object -First 5 LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess | Format-Table -Auto"
LocalAddress    LocalPort RemoteAddress   RemotePort OwningProcess
10.8.0.2        50214     10.8.0.53       53         1240
192.168.1.123   50215     93.184.216.34   443        8916
192.168.1.123   50216     142.250.72.14   443        8916

Sens : Vous avez des connexions simultanées provenant à la fois du VPN et du Wi‑Fi. Cela peut être normal avec le split tunnel. Cela peut aussi casser des applis qui supposent une source IP unique stable.

Décision : Si une appli spécifique échoue tandis que d’autres fonctionnent, elle peut être sensible au changement d’adresse source. Routez explicitement les destinations de cette appli, ou utilisez un full tunnel cohérent.

Tâche 18 : Vérifier le profil du firewall Windows et si le VPN vous a marqué « Public » avec des règles strictes

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -Auto Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name          InterfaceAlias           NetworkCategory IPv4Connectivity
HomeNetwork   Wi-Fi                    Private         Internet
Corp-VPN      Wintun Userspace Tunnel  Public          LocalNetwork

Sens : Le profil réseau du VPN est Public et n’indique que LocalNetwork. Certaines politiques endpoint appliquent des règles de firewall plus strictes sur les réseaux Public,
et certains clients VPN étiquettent mal le profil.

Décision : Si le trafic est bloqué seulement quand le VPN est actif et que les routes semblent correctes, inspectez les politiques firewall/WFP et l’étiquetage des profils plutôt que de modifier les routes au hasard.

Blague n°2 : Les tables de routage sont le seul endroit où « le plus petit nombre gagne » est une politique que vous pouvez appliquer sans que les RH interviennent.

Une citation à garder sur votre bureau

« L’espoir n’est pas une stratégie. » — James Cameron

Elle s’applique douloureusement bien au dépannage VPN : n’espérez pas que les paquets sont allés où vous vouliez ; prouvez où ils sont allés.

Erreurs courantes : symptôme → cause racine → correctif

Cette section est volontairement spécifique. Si votre symptôme n’y figure pas, c’est soit un problème plus rare, soit un autre étage (authent, sécurité endpoint, FAI).

1) « Le VPN se connecte, les sites internes fonctionnent, l’internet public meurt »

• Cause racine : Route par défaut full tunnel installée via le VPN, mais l’egress/NAT du VPN vers Internet est désactivé ou bloqué.
• Correctif : Soit (a) activez l’egress sur la passerelle VPN (NAT + règles firewall + journalisation), soit (b) supprimez la route par défaut VPN et utilisez le split tunneling avec des préfixes d’entreprise explicites.

2) « Le ping d’une IP publique fonctionne, les sites web ne chargent pas »

• Cause racine : Les requêtes DNS sont envoyées à un serveur DNS injoignable ou à un serveur interne qui ne relaie pas les domaines publics.
• Correctif : Ajustez l’ordre des serveurs DNS, retirez le NRPT catch‑all, ou configurez le résolveur interne pour relayer/ résoudre les domaines publics ; assurez‑vous que les routes vers les serveurs DNS existent.

3) « Certains sites chargent, d’autres bloquent indéfiniment (surtout HTTPS) »

• Cause racine : Problèmes MTU/MSS sur le tunnel (fragmentation bloquée, PMTUD en blackhole), ou blocages firewall sélectifs.
• Correctif : Réduisez le MTU du tunnel, clamperez le MSS sur la passerelle VPN, vérifiez le comportement ICMP fragmentation‑needed, ou ajustez la politique firewall pour le TCP sortant.

4) « Le VPN fonctionne sur Wi‑Fi mais pas sur Ethernet (ou inversement) »

• Cause racine : Différences de métrique d’interface provoquent une sélection différente de la route par défaut ; le LAN corporate utilise d’autres options DHCP ou paramètres proxy ; politiques VLAN différentes.
• Correctif : Comparez les sorties de Get-NetRoute par environnement ; définissez des métriques explicites si nécessaire ; assurez‑vous que les routes VPN ne rentrent pas en collision avec les sous‑réseaux locaux.

5) « Le VPN dit connecté, mais le DNS retourne des IP internes étranges pour des noms publics »

• Cause racine : DNS split‑brain ou détournement DNS interne (intentionnel ou accidentel), parfois via la règle NRPT « . ».
• Correctif : Limitez NRPT aux namespaces corporate ; assurez‑vous que le DNS interne n’écrase pas les zones publiques sauf si c’est intentionnel (et planifié).

6) « L’internet meurt seulement pour une application (Teams, Outlook, navigateur, gestionnaire de paquets) »

• Cause racine : Paramètres proxy (WinHTTP vs WinINET), l’application utilise IPv6 en premier, ou l’application se lie à une interface fixe et n’aime pas les changements d’IP source.
• Correctif : Vérifiez netsh winhttp show proxy, confirmez le routage IPv6, et testez avec Test-NetConnection en ciblant le nom/port de l’application.

7) « Le VPN se connecte, mais vous ne pouvez atteindre ni l’interne ni l’externe ; la table de routage semble correcte »

• Cause racine : Blocages WFP/firewall, interférence d’un endpoint security, ou tunnel établi sans plan de données (mauvaises clés, AllowedIPs incorrects, sélecteurs SA erronés).
• Correctif : Validez avec Test-NetConnection vers des IP internes ; vérifiez le profil firewall ; pour WireGuard vérifiez AllowedIPs ; pour IPSec vérifiez les traffic selectors.

8) « Après avoir déconnecté le VPN, l’internet reste cassé jusqu’au reboot »

• Cause racine : Routes persistantes, adresses DNS obsolètes, ou paramètres proxy laissés par le client VPN.
• Correctif : Supprimez les routes persistantes, réinitialisez le DNS via DHCP, effacez le proxy WinHTTP, ou redémarrez le stack réseau (moins dramatique qu’un reboot complet).

Checklists / plan étape par étape

Checklist A : Le triage « est‑ce le routage ou le DNS ? » en 5 minutes

1. Exécutez ping 1.1.1.1. S’il échoue, vous avez probablement un problème de routage/firewall.
2. Exécutez ping www.microsoft.com. Si le ping IP fonctionne mais le nom échoue, concentrez‑vous sur le DNS.
3. Exécutez route print et identifiez la route gagnante 0.0.0.0/0.
4. Exécutez Get-DnsClientServerAddress et confirmez que les serveurs DNS sont joignables sur le chemin sélectionné.
5. Exécutez tracert -d 1.1.1.1 pour voir si le trafic sort via la passerelle VPN ou le routeur local.

Checklist B : Sanity check full tunnel (pour opérateurs et personnes on‑call)

Si votre organisation exige le full tunnel, assumez‑le et faites‑le fonctionner. Le semi‑full tunnel est un nid à incidents.

1. Confirmez que le VPN pousse une route par défaut avec la métrique prévue.
2. Confirmez que la passerelle VPN fournit un egress Internet (NAT) et a des règles firewall autorisant le trafic sortant selon la politique.
3. Confirmez que les serveurs DNS poussés via le VPN peuvent résoudre les zones internes et les domaines publics (directement ou via relai).
4. Confirmez l’ajustement MTU/MSS pour éviter le blackholing.
5. Journalisez les drops d’egress à la passerelle VPN. Si vous ne voyez pas les drops, vous discuterez avec des fantômes.
6. Testez la posture IPv6 : soit la supporter de bout en bout, soit la contraindre délibérément pour que les clients ne choisissent pas un chemin mort.

Checklist C : Sanity check split tunnel (pour ceux qui aiment les réseaux prévisibles)

1. Ne poussez pas 0.0.0.0/0 via le VPN. Poussez seulement les préfixes corporate.
2. Évitez les espaces d’adresses qui se chevauchent avec les réseaux domestiques (collisions 192.168.0.0/16 réelles). Si vous ne pouvez pas éviter, utilisez NAT côté client ou repensez les sous‑réseaux corp.
3. Utilisez NRPT pour les namespaces corporate uniquement, pas pour . sauf si vous forcez délibérément tout le DNS.
4. Assurez‑vous que les serveurs DNS corporate sont joignables via les routes du tunnel (évident, mais régulièrement oublié).
5. Soyez cohérents sur la politique proxy : soit proxy via le VPN pour les applis internes, soit pas. Les signaux mixtes causent des outages mixtes.
6. Documentez quel trafic doit passer par le VPN (contrôle de source, CI/CD, dépôts d’artefacts internes) et ajoutez ces préfixes/routes explicitement.

Checklist D : Actions client‑side « me débloquer sans violer la politique »

1. Déconnectez et reconnectez le VPN une fois (oui, une fois). Si la table de routage change à chaque fois, c’est un bug à reporter.
2. Videz le cache DNS (ipconfig /flushdns) après des changements de politique DNS.
3. Réobtenez le DHCP sur l’interface physique (ipconfig /renew) si le routage local semble incorrect.
4. Vérifiez et effacez le proxy WinHTTP obsolète si c’est clairement erroné (netsh winhttp reset proxy) — mais seulement si votre environnement ne l’exige pas.
5. Collectez des preuves avant d’escalader : table de routage, serveurs DNS, politiques NRPT, et quelques tests qui échouent avec horodatage.

Jeu de commandes « bundle de preuves » utile (copier/coller pour escalades)

cr0x@server:~$ powershell -NoProfile -Command "Get-Date; hostname; Get-NetAdapter | ? Status -eq 'Up' | ft -Auto Name,ifIndex,LinkSpeed; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | ft -Auto; Get-DnsClientServerAddress -AddressFamily IPv4 | ft -Auto; Get-DnsClientNrptPolicy | ft -Auto NameSpace,NameServers; Test-NetConnection 1.1.1.1 -InformationLevel Detailed; Resolve-DnsName www.microsoft.com -ErrorAction SilentlyContinue"

Sens : Cela capture l’heure, les interfaces up, les routes par défaut, la configuration DNS, NRPT, la connectivité basique, et une tentative de résolution DNS.
C’est la différence entre une escalade et un cri d’aide.

Décision : Si vous ne pouvez pas réparer localement, envoyez ce bundle à l’équipe VPN/réseau. Ils poseront encore une question de plus, mais au moins ce ne sera pas « quelle est votre table de routage ? ».

Trois micro‑histoires d’entreprise (anonymisées, plausibles et techniquement agaçantes)

Micro‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé un nouveau profil VPN pour des sous‑traitants. L’idée était simple : les sous‑traitants ne devaient atteindre que quelques applis web internes.
Le concentrateur VPN était configuré pour du routage interne uniquement — pas d’egress Internet, pas de NAT, ACLs sortantes strictes. La sécurité a approuvé. Tout le monde s’est senti responsable.

La mauvaise hypothèse est apparue sous la forme d’une inondation d’appels au helpdesk : « VPN connecté mais pas d’internet ». Le helpdesk l’a interprété comme un problème d’ISP parce que ça
commençait à la même heure chaque matin. En réalité, ça commençait quand les gens ouvraient leurs laptops, connectaient le VPN, puis essayaient d’utiliser des flux MFA hébergés sur des domaines publics.
Leurs navigateurs ne pouvaient pas résoudre ni atteindre les endpoints d’identité externes parce que le VPN poussait une route par défaut.

L’équipe VPN a insisté sur le fait qu’ils n’avaient jamais eu l’intention de tunnelet tout l’Internet. L’équipe endpoint a insisté sur le fait qu’elle n’avait jamais eu l’intention de changer la route par défaut. Les deux avaient raison, et les deux manquaient le troisième acteur : le template de profil qu’ils avaient cloné avait « envoyer tout le trafic » activé par défaut, car il venait d’un ancien déploiement full‑tunnel.

La correction n’a pas été héroïque. Ils ont retiré la route par défaut du profil sous‑traitant, poussé des préfixes explicites pour les deux applications, et ajouté une règle NRPT pour le domaine corporate seulement. Le lendemain, la file du helpdesk s’est calmée. Puis quelqu’un a demandé pourquoi ça avait pris trois jours. La réponse fut, douloureusement, « parce que personne n’a regardé route print ».

Micro‑histoire 2 : L’optimisation qui a mal tourné

Une équipe IT veut améliorer les performances VPN, alors ils ont ajusté les métriques d’interface pour favoriser agressivement l’adaptateur VPN. Métrique plus basse, priorité supérieure, moins d’ambiguïté.
Ça a fonctionné dans leur labo et sur le Wi‑Fi corporate. Les graphiques semblaient meilleurs. Ils ont déployé le changement.

Puis des employés distants sur des réseaux domestiques instables ont commencé à signaler des « connecté mais pas d’internet » intermittents et des problèmes « certains sites bloquent ». L’adaptateur VPN gagnait désormais les décisions de routage
même lorsque le tunnel était opérationnel mais dégradé. Pendant ce temps, le Wi‑Fi avait encore une route par défaut saine qui aurait pu porter le trafic public durant les dégradations du VPN.
Mais les métriques avaient été « optimisées » pour supprimer ce fallback.

La partie désagréable : le plan de contrôle du tunnel restait suffisamment stable pour afficher « Connected », tandis que le plan de données souffrait de MTU blackholing et de perte de paquets.
Les utilisateurs gardaient donc leur VPN connecté et accusaient « Internet ». En réalité, leur routage était verrouillé sur un chemin sous‑optimal sans repli gracieux.

Le rollback a amélioré les choses immédiatement. La solution à long terme a été plus mature : conserver le full tunnel pour les postes gérés qui en ont besoin, mais ajouter des health checks et un meilleur réglage MTU ;
et pour les populations en split‑tunnel, éviter de forcer les routes par défaut par des hacks de métrique. L’optimisation de métrique était un gain local qui est devenu une panne globale.

Micro‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une société financière avait un environnement VPN que tout le monde appelait « vieux », ce qui en langage corporate signifie « stable mais démodé ». Leur secret n’était pas du matériel magique.
C’était la discipline opérationnelle : chaque changement de profil VPN exigeait une capture avant/après des routes, des serveurs DNS, des règles NRPT, et un ensemble de tests scriptés depuis une VM Windows propre.

Un mardi, une rotation de certificats a coïncidé avec une mise à jour client. Les utilisateurs ont commencé à signaler des échecs de navigation après connexion VPN. Les passerelles VPN semblaient correctes.
L’authentification était ok. Le tunnel était up. Le piège classique.

Grâce à la pratique ennuyeuse, l’ingénieur on‑call a comparé les bundles de preuves avant/après et a repéré que la nouvelle mise à jour client avait introduit une règle NRPT catch‑all pour ., forçant tout le DNS vers les résolveurs internes.
Les résolveurs internes étaient joignables, mais configurés pour ne pas relayer les domaines publics — encore une fois, par politique.

Ils n’ont pas « essayé des trucs au hasard ». Ils ont retiré la règle catch‑all dans le profil, gardé NRPT pour les namespaces internes, et poussé la configuration corrigée.
L’incident a été contenu rapidement. Personne n’a écrit un post héroïque. C’est le but : les pratiques ennuyeuses empêchent les pannes excitantes.

FAQ

1) Pourquoi Windows indique « Connecté » si je ne peux rien charger ?

Parce que le plan de contrôle du client VPN est connecté. Vos routes et paramètres DNS peuvent toujours être erronés, et Windows n’appellera pas ça « déconnecté ».
Pensez‑y comme « tunnel établi », pas « paquets livrés ».

2) Quelle est la cause la plus courante de « VPN connecté mais pas d’internet » ?

Une route par défaut (0.0.0.0/0) préférée via le VPN alors que la passerelle VPN ne fournit pas d’egress Internet (ou le bloque).
C’est un décalage routage + politique, pas un mystère.

3) Comment savoir si c’est le DNS ou le routage ?

Pinguez une IP (comme 1.1.1.1) puis pinguez un nom (comme www.microsoft.com). Si l’IP marche et le nom échoue, c’est DNS.
Si les deux échouent, c’est le routage/firewall ou le plan de données du tunnel.

4) Dois‑je simplement activer le split tunneling pour réparer ?

Seulement si votre politique de sécurité le permet et si votre VPN est conçu pour le split tunneling. Sinon vous « réparez » en changeant la politique.
La bonne correction pour le full tunnel est de rendre le full tunnel fonctionnel : egress, relais DNS, réglage MTU, et politique firewall claire.

5) Pourquoi ai‑je deux routes par défaut, et pourquoi cela importe‑t‑il ?

Vous pouvez avoir plusieurs routes par défaut (Wi‑Fi et VPN). Windows choisit selon les métriques. La métrique la plus basse gagne, et votre trafic suit.
Si le gagnant mène dans une impasse, votre Internet le suit dans le vide.

6) Qu’est‑ce que NRPT et pourquoi cela casse la navigation ?

NRPT est la table de politique de résolution de noms de Windows. Si une politique force tous les domaines vers le DNS du VPN (règle pour .),
et que ce serveur DNS ne peut pas résoudre les domaines publics ou est injoignable, la navigation échoue même si le routage IP est correct.

7) Pourquoi la déconnexion du VPN ne restaure‑t‑elle pas toujours l’internet ?

Certains clients VPN laissent des routes persistantes, des paramètres DNS ou des configurations proxy. Windows continuera à les utiliser jusqu’à ce qu’ils soient supprimés ou remplacés.
Vérifiez les routes persistantes et les listes de serveurs DNS, et réinitialisez les proxies obsolètes si nécessaire.

8) IPv6 pourrait‑il être en cause ?

Oui. Windows privilégie IPv6 quand il peut. Si votre VPN ne transporte pas IPv6 mais que le DNS renvoie des enregistrements AAAA pour des services internes ou externes,
certaines applis tenteront IPv6 en premier et sembleront cassées. Vérifiez les routes par défaut IPv6 et si le design du VPN supporte IPv6 intentionnellement.

9) Changer la métrique d’interface est‑ce une bonne solution à long terme ?

C’est un outil, pas une stratégie. Les métriques peuvent résoudre des égalités de route, mais les utiliser pour contourner un profil VPN mal conçu crée de la dérive sur les machines.
Préférez corriger les routes et les politiques DNS poussées par le VPN de manière centrale.

10) Quelles preuves dois‑je envoyer à l’équipe VPN ?

Routes par défaut et métriques, serveurs DNS, politiques NRPT, et quelques tests échouants (Test-NetConnection et Resolve-DnsName).
Incluez des horodatages et si le problème survient seulement sur certains réseaux (Wi‑Fi domestique, tethering, hôtel).

Conclusion : étapes suivantes pour éviter la récidive

« Connecté mais pas d’internet » est rarement aléatoire. C’est généralement l’une des trois choses : la mauvaise route par défaut a gagné, le DNS a été forcé quelque part d’inutile, ou le tunnel est up mais le plan de données est cassé
(souvent MTU/firewall). On ne répare pas ça en devinant. On le répare en lisant la table de routage comme s’il s’agissait d’un fichier de log.

Étapes pratiques suivantes :

1. Effectuez le triage de 5 minutes : ping IP vs ping nom, puis propriété de la route par défaut.
2. Décidez full tunnel vs split tunnel et alignez routes + politique DNS sur cette décision.
3. Si vous exploitez le VPN : arrêtez d’envoyer des profils qui installent une route par défaut sans fournir d’egress et de DNS capables de résoudre ce dont les utilisateurs ont besoin.
4. Standardisez un jeu de commandes « evidence bundle » et exigez‑le pour les escalades. Pas parce que vous êtes méchant — parce que cela réduit le temps d’incident.

La victoire n’est pas seulement de remettre un portable en ligne. C’est de rendre le prochain incident assez ennuyeux pour que personne ne se souvienne qu’il a eu lieu.