VPN qui ne fonctionne pas sous Windows 11 : le guide de dépannage complet pour techniciens helpdesk

Pourquoi le VPN reste l'un des tickets les plus chronophages du helpdesk

Si vous bossez au helpdesk, vous connaissez la chanson : les tickets VPN débarquent toujours au pire moment. Un lundi matin à 8h30, vingt utilisateurs en télétravail qui ne peuvent plus se connecter, la direction qui attend un accès urgent à un fichier partagé, et vous voilà à jongler entre les appels et les tentatives de diagnostic à distance. Bref, la joie.

Le VPN, c'est un peu le maillon invisible de l'infra IT — tout le monde l'utilise, personne n'y pense, jusqu'au moment où ça casse. Et honnêtement, avec les mises à jour récentes de Windows 11 (la 24H2, puis les correctifs de début 2026), les pannes VPN se sont multipliées dans beaucoup d'environnements d'entreprise. Microsoft a même reconnu officiellement que certaines mises à jour cassaient les connexions L2TP/IPsec et les tunnels via WSL. Sympa.

Ce guide est conçu spécifiquement pour les techniciens helpdesk et administrateurs IT qui doivent diagnostiquer et résoudre rapidement les problèmes VPN en entreprise sous Windows 11. On va couvrir les diagnostics de base, les codes d'erreur les plus courants, les commandes PowerShell essentielles, les bugs connus de 2026 et le dépannage du VPN Always On — le tout avec des commandes prêtes à copier-coller.

Diagnostic rapide : identifier le type de panne VPN en moins de 3 minutes

Avant de toucher à quoi que ce soit, la première étape c'est de comprendre où le problème se situe. Un VPN qui ne fonctionne pas, ça peut venir du réseau, du poste client, du serveur VPN, des certificats ou d'une mise à jour Windows qui a tout cassé. Voici un arbre de décision rapide à suivre à chaque ticket.

Étape 1 — L'utilisateur a-t-il accès à Internet ?

Ça paraît évident, mais croyez-moi, c'est la première chose à vérifier. Demandez à l'utilisateur d'ouvrir un navigateur et d'accéder à un site externe :

ping 8.8.8.8
ping www.google.com

Si le ping échoue : le problème n'est pas le VPN — c'est la connexion Internet. Vérifiez le Wi-Fi, le câble Ethernet, le routeur domestique. Inutile d'aller plus loin.

Si le ping réussit : Internet fonctionne, le problème est spécifique au VPN. On continue.

Étape 2 — Le service VPN tourne-t-il ?

Vérifiez que les services Windows essentiels au VPN sont bien démarrés :

Get-Service -Name RasMan, IKEEXT, PolicyAgent | Select-Object Name, DisplayName, Status, StartType | Format-Table -AutoSize

Trois services à surveiller de près :

• RasMan (Remote Access Connection Manager) — gère les connexions VPN et d'accès distant
• IKEEXT (IKE and AuthIP IPsec Keying Modules) — indispensable pour IKEv2 et L2TP/IPsec
• PolicyAgent (IPsec Policy Agent) — applique les politiques IPsec

Si l'un de ces services est arrêté, démarrez-le et configurez-le en démarrage automatique :

Set-Service -Name IKEEXT -StartupType Automatic -Status Running
Set-Service -Name PolicyAgent -StartupType Automatic -Status Running

Étape 3 — Le serveur VPN est-il joignable ?

Testez la connectivité vers le serveur VPN de l'entreprise :

Test-NetConnection -ComputerName vpn.entreprise.fr -Port 443
Test-NetConnection -ComputerName vpn.entreprise.fr -Port 500

Le port dépend du protocole : 443 pour SSTP, 500 et 4500 pour IKEv2 et L2TP/IPsec. Si le serveur est injoignable, le souci est côté réseau ou côté serveur — pas côté poste client.

Étape 4 — Quel message d'erreur s'affiche ?

Notez le code d'erreur exact. Windows affiche un code numérique (800, 809, 812, 853…) qui oriente directement le diagnostic. On détaille les plus fréquents juste après.

Les codes d'erreur VPN les plus fréquents sous Windows 11

Voici les codes que vous allez croiser le plus souvent au helpdesk, avec leur signification et la marche à suivre pour chacun.

Erreur 800 — Connexion impossible au serveur VPN

C'est l'erreur la plus générique — et la plus frustrante. Elle signifie que le tunnel VPN n'a pas pu être établi. Les causes sont multiples : serveur injoignable, pare-feu qui bloque les ports, mauvaise adresse du serveur VPN ou protocole incompatible.

Vérifications :

• Confirmez l'adresse du serveur VPN (IP ou FQDN) dans les paramètres de connexion
• Testez la connectivité réseau avec Test-NetConnection
• Vérifiez que le pare-feu local ne bloque pas les ports UDP 500, 4500 et le protocole ESP (50)

Erreur 809 — Le serveur distant ne répond pas

Très fréquente en entreprise. Le serveur VPN est derrière un NAT ou un pare-feu qui bloque le trafic IKE/IPsec. C'est aussi l'erreur classique après une mise à jour de pare-feu côté datacenter.

Côté client, vérifiez la clé de registre NAT-T (on en parle plus bas). Côté serveur, confirmez que les ports UDP 500 et 4500 sont bien ouverts et transférés.

Erreur 812 — Politique de serveur incompatible

La méthode d'authentification configurée sur le client ne correspond pas à celle du serveur VPN (NPS/RADIUS). Typiquement, le profil VPN demande EAP-TLS mais le serveur attend MS-CHAPv2, ou l'inverse.

Solution : alignez la méthode d'authentification entre le profil VPN client et la politique NPS sur le serveur. Ça semble basique, mais c'est une cause de ticket récurrente après chaque changement de politique côté infra.

Erreur 853 — Certificat invalide pour IKEv2

Le certificat utilisé pour l'authentification IKEv2 est invalide, expiré ou absent du magasin de certificats. C'est un grand classique après un renouvellement de certificats côté serveur sans mise à jour côté client.

Vérification PowerShell :

Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*VPN*" -or $_.Subject -like "*entreprise*" } | Select-Object Subject, NotAfter, Thumbprint | Format-Table -AutoSize

Vérifiez que le certificat racine de l'autorité de certification (CA) est bien présent dans le magasin Autorités de certification racines de confiance du poste.

Erreur 720 — Adaptateur WAN Miniport corrompu

Le WAN Miniport (IP) n'est pas correctement lié. C'est souvent la conséquence d'une mise à jour majeure de Windows (comme le passage à 24H2). La solution : réinstaller les miniports via le Gestionnaire de périphériques ou PowerShell. On va voir comment juste après.

Bugs connus de Windows 11 qui affectent le VPN (2026)

Avant de passer du temps à chercher une mauvaise configuration, vérifiez d'abord que vous n'êtes pas face à un bug connu de Microsoft. Parce qu'en 2026, la liste est malheureusement bien remplie.

Windows 11 24H2 casse les connexions L2TP/IPsec

La mise à jour 24H2 a introduit des problèmes de connectivité VPN majeurs pour les protocoles L2TP/IPsec. Les miniports WAN (IP, IPv6, PPTP, L2TP) peuvent se corrompre lors de la montée de version. Des utilisateurs rapportent des erreurs 809 et 720 immédiatement après l'installation — et franchement, c'est un cas qu'on voit de plus en plus souvent.

Contournement :

1. Ouvrez le Gestionnaire de périphériques
2. Développez Cartes réseau
3. Faites un clic droit sur chaque WAN Miniport (IP, IPv6, PPTP, L2TP) → Désinstaller l'appareil
4. Appuyez sur F5 pour rechercher les modifications matérielles — Windows les recréera automatiquement

En PowerShell, vous pouvez aussi forcer la réinitialisation de la pile réseau :

netsh int ip reset
netsh winsock reset
ipconfig /flushdns
Restart-Computer

Mise à jour KB5067036 — VPN cassé via WSL

La mise à jour optionnelle KB5067036 pour Windows 11 a introduit un bug qui perturbe les connexions VPN pour les utilisateurs du sous-système Windows pour Linux (WSL). Le problème vient du mode "Mirrored mode networking" de WSL : l'interface virtuelle de l'application VPN ne répond plus aux requêtes ARP, ce qui empêche la résolution correcte entre adresses IP et MAC.

Les solutions VPN confirmées comme affectées sont Cisco Secure Client (anciennement AnyConnect) et OpenVPN. Si vos développeurs utilisent WSL (et il y a de bonnes chances que ce soit le cas), ce bug va probablement finir sur votre bureau.

Contournement : désactivez temporairement le mode réseau miroir de WSL en ajoutant dans le fichier .wslconfig :

[wsl2]
networkingMode=NAT

Puis redémarrez WSL :

wsl --shutdown

Mise à jour de février 2026 (KB5077181) — Problèmes DHCP

Celle-là, elle fait mal. La mise à jour cumulative de février 2026 a été signalée comme causant des boucles de démarrage, des problèmes de page de connexion et des dysfonctionnements DHCP. Les problèmes DHCP peuvent directement affecter les connexions VPN, car le poste ne reçoit plus d'adresse IP valide.

Solution : si l'utilisateur est touché, désinstallez la mise à jour depuis Paramètres → Windows Update → Historique → Désinstaller des mises à jour, ou en ligne de commande :

wusa /uninstall /kb:5077181 /quiet /norestart

Commandes PowerShell essentielles pour le diagnostic VPN

Allez, on entre dans le vif du sujet. PowerShell est clairement votre meilleur allié pour diagnostiquer les problèmes VPN à distance. Voici les commandes que j'utilise le plus au quotidien.

Lister toutes les connexions VPN configurées

Get-VpnConnection -AllUserConnection
Get-VpnConnection

La première commande liste les connexions VPN disponibles pour tous les utilisateurs (déployées par GPO ou Intune), la seconde celles de l'utilisateur courant. Vérifiez le protocole (TunnelType), le serveur (ServerAddress) et le mode d'authentification.

Vérifier la configuration IPsec d'une connexion

Get-VpnConnection -Name "VPN Entreprise" | Select-Object -ExpandProperty IPsecCustomPolicy

Cette commande affiche les paramètres de chiffrement, d'intégrité et de groupe Diffie-Hellman configurés pour la connexion. Comparez-les avec la configuration côté serveur pour identifier une incompatibilité.

Tester la résolution DNS via le VPN

Petit piège classique : n'utilisez pas nslookup pour tester le DNS via VPN. Cet outil contourne la table NRPT (Name Resolution Policy Table) et utilise les serveurs DNS de la carte réseau physique. Utilisez plutôt :

Resolve-DnsName -Name serveur-interne.entreprise.local
Resolve-DnsName -Name serveur-interne.entreprise.local -DnsOnly

Le cmdlet Resolve-DnsName respecte la NRPT et vous donnera un résultat fidèle à ce que l'utilisateur obtient réellement via le tunnel. J'ai personnellement perdu pas mal de temps avant de comprendre cette subtilité — ne faites pas la même erreur.

Consulter les journaux d'événements VPN

Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational" -MaxEvents 20 |
    Select-Object TimeCreated, Id, Message |
    Format-Table -Wrap -AutoSize

Ce journal contient les tentatives de connexion VPN, les erreurs et les déconnexions. C'est souvent ici que vous trouverez la cause exacte d'un échec — bien plus parlant que le simple code d'erreur affiché à l'utilisateur.

Reconfigurer les paramètres IPsec d'une connexion

Si le serveur VPN a été mis à jour avec de nouveaux paramètres de chiffrement, vous pouvez reconfigurer la connexion côté client :

Set-VpnConnectionIPsecConfiguration -ConnectionName "VPN Entreprise" `
    -AuthenticationTransformConstants SHA256128 `
    -CipherTransformConstants AES256 `
    -EncryptionMethod AES256 `
    -IntegrityCheckMethod SHA256 `
    -DHGroup Group14 `
    -PfsGroup PFS2048 `
    -Force

Résoudre les problèmes L2TP/IPsec derrière un NAT

C'est probablement l'un des problèmes les plus fréquents en entreprise : le serveur VPN est derrière un routeur NAT, et les connexions L2TP/IPsec échouent systématiquement avec une erreur 809. La raison est simple — Windows ne supporte pas le NAT-T (NAT Traversal) par défaut pour L2TP/IPsec. Il faut l'activer manuellement via le registre.

Activer le NAT-T côté client

Créez (ou modifiez) la clé de registre suivante :

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" `
    -Name "AssumeUDPEncapsulationContextOnSendRule" `
    -PropertyType DWORD `
    -Value 2 `
    -Force

Les valeurs possibles :

• 0 (défaut) — pas de NAT-T, le serveur et le client doivent être directement connectés
• 1 — le serveur est derrière un NAT
• 2 — le serveur et le client sont derrière un NAT (c'est la valeur qu'on veut dans 90% des cas en entreprise)

Un redémarrage est nécessaire pour que la modification prenne effet. Et attention, c'est un piège classique : le technicien applique la clé de registre, reteste immédiatement et conclut que ça ne fonctionne pas — alors qu'il fallait juste redémarrer. On est tous passés par là.

Vérifier les ports ouverts sur le pare-feu

Pour que L2TP/IPsec fonctionne derrière un NAT, les ports suivants doivent être ouverts et transférés :

• UDP 500 — négociation IKE (Internet Key Exchange)
• UDP 4500 — NAT Traversal (NAT-T)
• UDP 1701 — protocole L2TP
• Protocole IP 50 — ESP (Encapsulating Security Payload)

Dépanner le VPN Always On (AOVPN) en entreprise

Le VPN Always On est la solution recommandée par Microsoft pour les entreprises. Il remplace DirectAccess et offre une connexion VPN automatique, transparente pour l'utilisateur. Mais son dépannage est notoirement complexe — plusieurs couches d'infrastructure interagissent, et une erreur dans n'importe laquelle suffit à faire échouer la connexion entière.

Profils AOVPN qui apparaissent et disparaissent (Intune)

Un problème bien documenté (et bien agaçant) avec Windows 11 et Intune : les profils VPN Always On sont supprimés puis recréés à chaque synchronisation MDM. Le journal d'événements affiche une erreur du fournisseur Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider avec le message "The specified quota list is internally inconsistent with its descriptor".

Ce bug est lié aux routes de split tunneling configurées dans le profil. Supprimer toutes les routes fait disparaître l'erreur — mais ce n'est évidemment pas une solution viable en production.

Contournement : déployez le profil VPN via un script PowerShell (proactive remediation dans Intune) plutôt que via un profil de configuration MDM natif. Ça contourne le bug lié au CSP VPN et c'est franchement plus fiable dans la durée.

Tunnel d'appareil qui ne démarre plus automatiquement

Celui-ci est vicieux. Si vous mettez à jour un profil AOVPN en supprimant puis en recréant le tunnel d'appareil (device tunnel), ne sautez pas le redémarrage entre les deux opérations. Sans redémarrage, le tunnel d'appareil ne démarrera plus automatiquement — il faudra le lancer manuellement à chaque fois.

Un simple redémarrage après la recréation résout le problème. C'est bête, mais c'est comme ça.

Échecs d'authentification après mises à jour de sécurité

Microsoft a introduit des modifications aux contrôleurs de domaine dans les mises à jour de sécurité récentes qui peuvent provoquer des échecs d'authentification pour les connexions AOVPN. L'utilisateur voit le message : "The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid."

Vérification :

# Vérifier la validité des certificats machine
Get-ChildItem -Path Cert:\LocalMachine\My |
    Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication" } |
    Select-Object Subject, NotBefore, NotAfter, Thumbprint |
    Format-Table -AutoSize

Assurez-vous que le certificat client n'est pas expiré et que le contrôleur de domaine reconnaît l'autorité de certification émettrice.

Tester la résolution DNS avec la NRPT

La table NRPT (Name Resolution Policy Table) est configurée dans le profil XML du VPN Always On. Pour vérifier qu'elle est correctement appliquée :

Get-DnsClientNrptPolicy | Format-Table Namespace, NameServers -AutoSize

Si aucune règle n'apparaît, le profil VPN n'a pas été correctement déployé ou la connexion n'est pas active. Dans les deux cas, il faut investiguer.

Checklist de dépannage rapide

Voici une checklist synthétique à garder sous la main pour chaque ticket VPN. Perso, je l'ai imprimée à côté de mon écran :

1. Internet fonctionne ? → ping 8.8.8.8
2. Services VPN démarrés ? → Get-Service RasMan, IKEEXT, PolicyAgent
3. Serveur VPN joignable ? → Test-NetConnection -ComputerName vpn.entreprise.fr -Port 500
4. Code d'erreur ? → Consultez le tableau des erreurs ci-dessus
5. Mise à jour Windows récente ? → Vérifiez l'historique des mises à jour
6. Certificats valides ? → Get-ChildItem Cert:\LocalMachine\Root
7. NAT-T activé ? → Vérifiez la clé de registre AssumeUDPEncapsulationContextOnSendRule
8. Miniports WAN intacts ? → Réinstallez-les via le Gestionnaire de périphériques
9. Logs VPN ? → Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational"
10. DNS via le tunnel ? → Resolve-DnsName serveur.entreprise.local

FAQ — Questions fréquentes sur le dépannage VPN

Quel protocole VPN choisir en entreprise sous Windows 11 en 2026 ?

Privilégiez IKEv2 avec authentification par certificat. C'est le protocole le plus stable sur les builds récentes de Windows 11, et il gère nativement les changements de réseau (passage du Wi-Fi à l'Ethernet, par exemple). Le L2TP/IPsec reste fonctionnel mais nécessite des ajustements (NAT-T), et Microsoft pousse clairement vers IKEv2 et SSTP.

La mise à jour Windows a cassé le VPN, dois-je la désinstaller ?

Pas forcément. Commencez par réinstaller les miniports WAN et réinitialiser la pile réseau (netsh int ip reset). La désinstallation de la mise à jour est un dernier recours, car elle peut réintroduire des failles de sécurité. Si la désinstallation est vraiment inévitable, planifiez la réinstallation de la mise à jour dès qu'un correctif Microsoft est disponible.

Pourquoi nslookup fonctionne mais l'accès aux ressources internes échoue via le VPN ?

Ah, celui-là… nslookup contourne la table NRPT (Name Resolution Policy Table) et utilise les serveurs DNS de la carte réseau physique, pas ceux du tunnel VPN. Utilisez Resolve-DnsName en PowerShell pour obtenir un résultat fidèle à la configuration VPN réelle. C'est un piège qui fait perdre énormément de temps en diagnostic — et j'en ai vu des techniciens tourner en rond à cause de ça.

Comment déployer une configuration VPN sur plusieurs postes en entreprise ?

Trois options principales : Intune/Endpoint Manager pour les environnements cloud, GPO (stratégie de groupe) pour les environnements Active Directory traditionnels, ou un script PowerShell déployé via SCCM/MECM. Pour le VPN Always On, Microsoft recommande un profil ProfileXML déployé via MDM. Et si vous rencontrez le bug des profils qui disparaissent sous Intune, passez par un script PowerShell via les remédiations proactives (on en a parlé plus haut).

Le VPN se connecte mais l'utilisateur n'accède à aucune ressource interne — que vérifier ?

Vérifiez la configuration du split tunneling. Si le VPN est configuré en split tunnel, seul le trafic destiné aux sous-réseaux définis passe par le tunnel. Vérifiez les routes avec Get-VpnConnection -Name "VPN" | Select-Object -ExpandProperty Routes. Vérifiez aussi que les serveurs DNS internes sont bien configurés dans le profil VPN et que la NRPT est correctement appliquée.