OpenVPN sur Windows : problèmes du pilote TAP et comment les réparer

octobre 15, 2025 • février 3, 2026 • Lecture : 28 min • Views: 14

Cet article vous a aidé ?

Vous cliquez sur « Connecter ». Le journal défile. La poignée de main TLS semble correcte. Puis : rien. Ou pire, la connexion s’établit mais vous n’arrivez à rien joindre, le DNS part en vrille,
et votre portable devient une petite île au milieu du réseau d’entreprise.

Quand OpenVPN sur Windows se comporte mal, le pilote TAP est un suspect fréquent. Pas toujours coupable — mais souvent trouvé sur les lieux avec un tournevis.
C’est le guide de terrain que j’aurais aimé voir plus souvent : comment TAP casse, comment le prouver, et comment le réparer sans transformer votre machine en scène de crime réseau.

TAP sur Windows : ce que c’est et pourquoi ça échoue

OpenVPN sur Windows utilise traditionnellement une interface réseau virtuelle appelée TAP-Windows. Pensez-y comme une carte réseau logicielle.
OpenVPN écrit des trames Ethernet dedans et lit les trames qui en sortent. Windows la traite comme un adaptateur réel — lui assigne une IP, définit des routes,
applique des politiques de pare-feu, et parfois la « optimise » en l’envoyant dans un fossé.

Il y a deux familles principales d’« adaptateurs virtuels » que vous verrez dans l’univers OpenVPN :

TAP : approximativement couche 2. Il peut transporter des trames Ethernet et est utilisé pour les configurations de type dev tap.
Il peut aussi être utilisé avec dev tun dans certaines distributions packagées, mais TAP n’est pas identique à TUN.
Wintun : un pilote plus récent orienté couche 3. Il est courant dans les nouvelles versions d’OpenVPN et aussi utilisé par des outils WireGuard.
Si vous dépannez spécifiquement TAP, ne « réparez » pas par erreur le mauvais pilote puis vous demandez pourquoi rien n’a changé.

Les pannes TAP ont tendance à se regrouper en quelques catégories :

Problèmes d’installation/signature du pilote (surtout après des mises à jour Windows ou des baselines de sécurité renforcées).
Problèmes d’état de l’adaptateur (désactivé, caché, dupliqué, état de registre obsolète).
Interférences de liaison et de filtres (sécurité endpoint, agents DLP, « aides » d’accélération réseau).
Mauvaise application du routage/DNS (le VPN se connecte mais le trafic n’emprunte pas le chemin attendu).
Problèmes DHCP ou d’attribution IP (bloqué sur « Assigning IP », mauvaise plage, pas de passerelle).

Le changement d’état d’esprit important : sur Windows, les problèmes VPN ne sont souvent pas des « problèmes OpenVPN ». Ce sont des problèmes de « pile réseau Windows rencontre un
adaptateur virtuel rencontre la colle de sécurité d’entreprise ». On ne les dépanne pas à l’intuition. On les dépanne avec des commandes et des preuves.

Feuille de route pour un diagnostic rapide

Quand la production brûle — le personnel distant ne peut pas se connecter, la hotline est submergée, et vous êtes à deux appels d’entendre « redémarrez simplement le serveur VPN » — il vous faut
une séquence de triage rapide. Voici la procédure que j’utilise.

Première étape : l’adaptateur TAP est-il présent et sain ?

Vérifiez l’état dans le Gestionnaire de périphériques (ou via PowerShell) : l’adaptateur TAP est-il là ?
S’il est présent : fonctionne-t-il correctement (pas de Code 10/Code 31) et est-il activé ?
S’il manque : le pilote a-t-il échoué à s’installer, ou est-il caché/obsolète ?

Deuxième étape : OpenVPN est-il lié au bon adaptateur ?

Confirmez les lignes du journal OpenVPN indiquant l’ouverture de l’adaptateur et la configuration IP.
Vérifiez que le nom d’interface et l’index sur l’OS correspondent à ce qu’OpenVPN attend.
Recherchez plusieurs instances TAP et collisions de nom.

Troisième étape : le routage/DNS Windows correspond-il à l’intention du VPN ?

Après « connected », vérifiez les routes : route par défaut, routes découpées, métriques.
Vérifiez les serveurs DNS par interface ; Windows adore « aider » ici.
Vérifiez le profil de pare-feu pour l’interface TAP (Public vs Privé a son importance).

Quatrième étape : identifier la partie interférente

Logiciel de sécurité récemment installé ? Pilotes de filtre réseau ? Logiciel d’« accélération VPN » ?
Mise à jour Windows récente ? Changements de signature des pilotes ? Core Isolation / Memory Integrity activés ?
Une stratégie de groupe applique-t-elle une baseline de durcissement réseau ?

Si vous suivez cet ordre, vous évitez le piège classique : reconfigurer le serveur VPN pour réparer un pilote client cassé.

Faits intéressants et historique utiles

Fait 1 : TAP-Windows est basé sur le modèle de pilote NDIS. Chaque grand changement NDIS (NDIS 5 → 6 et au-delà) a modifié le comportement des pilotes de filtre.
Fait 2 : Le concept original de « TAP » venait de l’idée d’un réseau tap : un appareil qu’on branche pour observer/injecter le trafic. Le TAP virtuel a rendu ce concept programmable.
Fait 3 : La popularité d’OpenVPN en entreprise n’était pas seulement due à la crypto ; c’était qu’il fonctionnait sans modifications du noyau sur de nombreux OS — jusqu’à ce que les baselines de sécurité se durcissent.
Fait 4 : Windows a une longue histoire de sélection automatique « utile » des métriques et d’enregistrement DNS par interface. Les VPN sont l’endroit où cette « aide » devient problématique.
Fait 5 : De nombreux échecs clients après des mises à jour Windows ne sont pas des bugs OpenVPN ; ce sont des problèmes de compatibilité et d’application des signatures de pilotes qui se manifestent tardivement.
Fait 6 : L’essor de Wintun s’explique en partie parce que des interfaces virtuelles couche 3 plus simples réduisent les bizarreries liées au bridging et aux pilotes filtres.
Fait 7 : Une seule machine peut accumuler des adaptateurs réseau « fantômes » avec le temps — des périphériques cachés d’anciens clients VPN — qui peuvent entrer en conflit avec les métriques de route et les indices d’interface.
Fait 8 : Les outils endpoint d’entreprise installent souvent des pilotes de filtre NDIS qui se placent entre la pile protocolaire et les adaptateurs. S’ils ne tolèrent pas les NIC virtuelles, vous obtenez des pannes intéressantes.

Symptômes qui indiquent généralement un problème TAP

Le pilote TAP n’est pas discret quand il échoue. Il est juste incohérent sur la manière dont il échoue. Symptômes courants :

« There are no TAP-Windows adapters on this system » dans les journaux OpenVPN GUI.
Le Gestionnaire de périphériques affiche l’adaptateur TAP avec Code 10/Code 31 (périphérique ne peut pas démarrer / échec du chargement du pilote).
OpenVPN se connecte mais aucun trafic ne passe, souvent parce que les routes ne sont pas appliquées ou que la métrique choisit le mauvais chemin.
Bloqué sur « Assigning IP » ou connexion qui se déconnecte immédiatement après établissement.
Le DNS casse uniquement lorsque le VPN se connecte (surtout les configurations split-tunnel où seul le DNS interne devrait passer par le VPN).
Multiples adaptateurs TAP avec des noms similaires, et OpenVPN choisit le mauvais.
Le VPN fonctionne en Wi‑Fi mais pas en Ethernet (ou inversement), typiquement à cause des jeux de métrique ou de différences de pilotes filtre.
Le VPN fonctionne en tant qu’administrateur mais pas en tant qu’utilisateur, souvent un problème de service/permissions ou de politique autour de l’accès au pilote.

Blague #1 : L’adaptateur TAP est comme une salle de réunion — quand il est cassé, tout le monde blâme la dernière personne qui l’a touché, pas le système qui échoue réellement.

Tâches pratiques : commandes, sorties, décisions

Ci-dessous figurent les tâches pratiques que j’utilise réellement pour diagnostiquer les problèmes TAP sur Windows. Chacune inclut : une commande, ce que signifie la sortie et la décision à prendre.
Ces exemples supposent que vous exécutez PowerShell ou CMD sur Windows. L’invite dans les blocks est standardisée ; ne vous en faites pas trop.

Tâche 1 : Confirmer l’état des processus et du service OpenVPN

cr0x@server:~$ powershell -NoProfile -Command "Get-Process openvpn* -ErrorAction SilentlyContinue | Format-Table Name,Id,Path"
Name     Id Path
----     -- ----
openvpn  4216 C:\Program Files\OpenVPN\bin\openvpn.exe

Ce que ça signifie : OpenVPN est en cours d’exécution. Si rien n’est retourné, vous ne dépannez pas TAP ; vous dépannez le lancement du processus/la configuration du service.

Décision : Si OpenVPN n’est pas en cours d’exécution, vérifiez d’abord les journaux du service et la configuration. S’il tourne, passez aux vérifications de l’adaptateur.

Tâche 2 : Lister les adaptateurs réseau et trouver TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object Status,Name | Format-Table -Auto Name,InterfaceDescription,Status,IfIndex,MacAddress"
Name                  InterfaceDescription                         Status   IfIndex MacAddress
----                  --------------------                         ------   ------ ----------
Ethernet              Intel(R) Ethernet Connection                 Up           6   2C-4D-54-11-22-33
Wi-Fi                 Intel(R) Wi-Fi 6 AX200                       Up           9   7A-1B-2C-3D-4E-5F
TAP-Windows Adapter V9 TAP-Windows Adapter V9                      Disabled    22   00-FF-12-34-56-78

Ce que ça signifie : L’adaptateur TAP existe mais est désactivé. C’est un problème côté client réparable.

Décision : Activez-le (Tâche 3). S’il est complètement absent, vous êtes en territoire de réinstallation (Tâche 9/10).

Tâche 3 : Activer l’adaptateur TAP

cr0x@server:~$ powershell -NoProfile -Command "Enable-NetAdapter -Name 'TAP-Windows Adapter V9' -Confirm:\$false; Get-NetAdapter -Name 'TAP-Windows Adapter V9' | Format-Table Name,Status"
Name                   Status
----                   ------
TAP-Windows Adapter V9 Up

Ce que ça signifie : Windows peut monter l’interface. Le pilote est au moins chargeable.

Décision : Réessayez la connexion VPN. Si cela échoue toujours, passez à l’état du pilote (Tâche 4) et à l’inspection des journaux (Tâche 6).

Tâche 4 : Vérifier les codes d’erreur du Gestionnaire de périphériques via PnP

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object { \$_.FriendlyName -like '*TAP*' } | Format-Table Status,Class,FriendlyName,InstanceId -Auto"
Status Class FriendlyName               InstanceId
------ ----- ------------               ----------
OK     Net   TAP-Windows Adapter V9     ROOT\NET\0001

Ce que ça signifie : Le statut est OK. Si vous voyez Error ici, cela correspond souvent à Code 10/31 dans le Gestionnaire de périphériques.

Décision : Si le statut est Error, ne perdez pas de temps sur les routes/DNS. Réparez d’abord le pilote (Tâches 9–11).

Tâche 5 : Vérifier les détails du pilote installé

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object { \$_.DeviceName -like '*TAP-Windows*' } | Select-Object DeviceName,DriverVersion,DriverProviderName,InfName | Format-List"
DeviceName         : TAP-Windows Adapter V9
DriverVersion      : 9.24.2.601
DriverProviderName : OpenVPN, Inc
InfName            : oem42.inf

Ce que ça signifie : Vous pouvez identifier quel INF soutient le pilote et si c’est une version reconnue pour votre build OpenVPN.

Décision : Si le fournisseur n’est pas OpenVPN (ou ressemble à un paquet repackagé), soyez suspicieux. Planifiez une réinstallation propre.

Tâche 6 : Lire les journaux de l’interface OpenVPN GUI pour la sélection d’adaptateur et la config IP

cr0x@server:~$ powershell -NoProfile -Command "Get-Content -Path \"$env:USERPROFILE\OpenVPN\log\client.log\" -Tail 40"
2025-12-27 10:13:11 OpenVPN 2.6.8 x86_64-w64-mingw32
2025-12-27 10:13:12 TAP-Windows Driver Version 9.24
2025-12-27 10:13:12 Opening Windows TAP-Windows adapter 'TAP-Windows Adapter V9'
2025-12-27 10:13:13 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.33.44.12/255.255.255.0 on interface {A1B2C3D4-E5F6-...}
2025-12-27 10:13:20 Initialization Sequence Completed

Ce que ça signifie : OpenVPN a trouvé l’adaptateur TAP et lui a demandé d’appliquer les paramètres IP. Si vous ne voyez jamais « Opening … adapter », la découverte TAP a échoué.

Décision : Si « Initialization Sequence Completed » apparaît mais que le trafic est mort, passez aux vérifications de routage/DNS (Tâches 7–8, 12–14).

Tâche 7 : Inspecter la configuration IP de l’interface TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration -InterfaceAlias 'TAP-Windows Adapter V9' | Format-List"
InterfaceAlias       : TAP-Windows Adapter V9
InterfaceIndex       : 22
IPv4Address          : 10.33.44.12
IPv4DefaultGateway   :
DNSServer            : 10.33.44.53, 10.33.44.54

Ce que ça signifie : L’interface a reçu une IP et des serveurs DNS. L’absence de passerelle par défaut est normale pour une configuration split-tunnel.

Décision : S’il n’y a pas d’IPv4Address, l’attribution IP a échoué — vérifiez le push DHCP, le pare-feu ou les problèmes de pilote. Si une IP est présente, vérifiez les routes.

Tâche 8 : Vérifier les changements de table de routage après la connexion

cr0x@server:~$ powershell -NoProfile -Command "route print | Select-String -Pattern '0.0.0.0|10\.33\.44\.0|VPN|TAP' -Context 0,1"
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.10     25
       10.33.44.0    255.255.255.0        On-link       10.33.44.12     1

Ce que ça signifie : Vous avez une route connectée pour le sous-réseau VPN via TAP. La route par défaut pointe toujours vers la passerelle locale avec métrique 25.

Décision : Si vous attendez un tunnel complet et que la route par défaut ne change pas, la config client/push est incorrecte. Si vous attendez un split-tunnel mais que des routes internes manquent, corrigez le push/routes côté serveur.

Tâche 9 : Trouver et supprimer les adaptateurs TAP « fantômes » (périphériques cachés)

cr0x@server:~$ powershell -NoProfile -Command "set devmgr_show_nonpresent_devices=1; start devmgmt.msc"

Ce que ça signifie : Ceci lance le Gestionnaire de périphériques avec la possibilité d’afficher les périphériques non présents (vous devez toujours activer « Afficher les périphériques cachés » dans l’UI).

Décision : Si vous voyez plusieurs anciens adaptateurs TAP, désinstallez les obsolètes. Trop d’adaptateurs virtuels provoquent des variations d’index d’interface et « OpenVPN choisit la mauvaise NIC ».

Tâche 10 : Énumérer les INFs de pilotes OEM installés et localiser les packages liés à TAP

cr0x@server:~$ powershell -NoProfile -Command "pnputil /enum-drivers | findstr /i \"tap openvpn wintun\""
Published Name : oem42.inf
Original Name  : tap0901.inf
Provider Name  : OpenVPN, Inc
Class Name     : Net

Ce que ça signifie : Vous avez identifié le package de pilote installé. Le « Published Name » est ce que vous pouvez supprimer si vous voulez une réinstallation propre.

Décision : Si vous suspectez une corruption, des versions incompatibles ou une mise à jour à moitié ratée, supprimez l’ancien package de pilote (Tâche 11) puis réinstallez proprement (Tâche 12).

Tâche 11 : Supprimer un package de pilote TAP spécifique

cr0x@server:~$ pnputil /delete-driver oem42.inf /uninstall /force
Microsoft PnP Utility

Driver package deleted successfully.

Ce que ça signifie : Windows a supprimé le package de pilote et désinstallé les périphériques qui l’utilisaient (si possible).

Décision : Redémarrez si demandé. Puis réinstallez le package OpenVPN/TAP correct. Si la suppression échoue car « en cours d’utilisation », arrêtez les services OpenVPN et réessayez.

Tâche 12 : Réinstaller TAP en utilisant l’installeur OpenVPN en mode silencieux

cr0x@server:~$ "C:\Program Files\OpenVPN\bin\tapctl.exe" create --name "TAP-Windows Adapter V9"
Created a TAP device named 'TAP-Windows Adapter V9'

Ce que ça signifie : tapctl est le moyen pratique de créer un adaptateur neuf si votre build OpenVPN l’inclut.

Décision : Si tapctl n’est pas présent, votre packaging est différent — utilisez l’installeur officiel OpenVPN et sélectionnez l’installation du pilote TAP. Évitez les paquets de pilotes aléatoires.

Tâche 13 : Vérifier les journaux d’événements Windows pour le chargement des pilotes et les erreurs NDIS

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 200 | Where-Object { \$_.Message -match 'TAP|NDIS|Netwtw|driver' } | Select-Object TimeCreated,Id,ProviderName,LevelDisplayName -First 8 | Format-Table -Auto"
TimeCreated           Id ProviderName            LevelDisplayName
-----------           -- ------------            ----------------
12/27/2025 10:10:02 219 Kernel-PnP              Warning
12/27/2025 10:10:03  12 Service Control Manager Error

Ce que ça signifie : Vous recherchez des preuves comme « échec du chargement du pilote », « bloqué à cause de la signature », ou des échecs de binding NDIS.

Décision : Si vous voyez des blocages liés à la signature, n’essayez pas de « réparer » avec des hacks de registre. Il vous faut un pilote correctement signé et compatible et possiblement un ajustement des paramètres de sécurité.

Tâche 14 : Inspecter les liaisons réseau et les pilotes filtre sur l’interface TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterBinding -Name 'TAP-Windows Adapter V9' | Where-Object { \$_.Enabled -eq \$true } | Format-Table ComponentID,DisplayName -Auto"
ComponentID DisplayName
----------- -----------
ms_tcpip    Internet Protocol Version 4 (TCP/IPv4)
ms_tcpip6   Internet Protocol Version 6 (TCP/IPv6)
ms_msclient Client for Microsoft Networks
ms_server   File and Printer Sharing for Microsoft Networks

Ce que ça signifie : Vous pouvez voir ce qui est lié à l’interface. Les filtres tiers apparaissent souvent ici aussi.

Décision : Si vous voyez des liaisons de filtres de sécurité agressifs et que votre organisation l’autorise, testez temporairement la désactivation du filtre uniquement sur TAP (pas globalement). Si cela corrige le problème, vous avez identifié le coupable.

Tâche 15 : Valider le comportement DNS par interface

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress | Sort-Object InterfaceIndex | Format-Table InterfaceAlias,InterfaceIndex,AddressFamily,ServerAddresses -Auto"
InterfaceAlias          InterfaceIndex AddressFamily ServerAddresses
--------------          -------------- ------------- --------------
Ethernet                6              IPv4          {192.168.1.1}
TAP-Windows Adapter V9  22             IPv4          {10.33.44.53, 10.33.44.54}

Ce que ça signifie : Les serveurs DNS diffèrent par interface. C’est normal — jusqu’à ce que la résolution de noms aille sur la mauvaise interface en premier.

Décision : Si les domaines internes se résolvent via le mauvais DNS, vous devrez peut-être utiliser des règles NRPT (en entreprise) ou ajuster les options OpenVPN (par ex. block-outside-dns quand pris en charge).

Tâche 16 : Confirmer le profil de pare-feu assigné au réseau TAP

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table InterfaceAlias,NetworkCategory,IPv4Connectivity -Auto"
InterfaceAlias          NetworkCategory IPv4Connectivity
--------------          --------------- ---------------
Ethernet                Private         Internet
TAP-Windows Adapter V9  Public          LocalNetwork

Ce que ça signifie : TAP est apparu comme réseau Public. Beaucoup d’organisations verrouillent fortement le profil Public, ce qui peut casser le trafic VPN ou le DNS.

Décision : Dans des environnements gérés, corrigez via la politique (préférable). Sur une machine autonome, vous pouvez ajuster le profil, mais faites-le délibérément et documentez-le.

Tâche 17 : Tests rapides de connectivité (ICMP + TCP)

cr0x@server:~$ powershell -NoProfile -Command "ping 10.33.44.1; Test-NetConnection 10.33.44.1 -Port 443"
Pinging 10.33.44.1 with 32 bytes of data:
Reply from 10.33.44.1: bytes=32 time=18ms TTL=63

ComputerName     : 10.33.44.1
RemoteAddress    : 10.33.44.1
RemotePort       : 443
TcpTestSucceeded : True

Ce que ça signifie : Le chemin du tunnel et un chemin de service réel fonctionnent tous deux. ICMP seul n’est pas une victoire ; beaucoup de réseaux le bloquent.

Décision : Si le ping fonctionne mais que TCP ne fonctionne pas, examinez le pare-feu ou le routage pour le VLAN du service. Si TCP fonctionne mais que le DNS ne fonctionne pas, concentrez-vous sur le DNS.

Stratégies de réparation qui n’engendrent pas de nouveaux problèmes

« Réparer TAP » peut signifier n’importe quoi, du basculement d’un adaptateur à l’extraction des packages de pilotes et au nettoyage du registre. La bonne approche dépend de ce qui est cassé.
Voici la séquence qui minimise les dommages collatéraux.

1) Traitez l’adaptateur TAP comme une véritable NIC

Commencez par les choses ennuyeuses : est-il désactivé, dans un mauvais état ou en concurrence avec des clones ? Si vous pouvez le réparer en activant l’adaptateur, faites-le et passez à autre chose.
Si vous pouvez le réparer en supprimant les périphériques fantômes, faites cela ensuite. La réinstallation des pilotes doit être une mesure tardive, pas un réflexe.

2) Préférez la suppression propre du package pilote plutôt que « mise à niveau par-dessus »

Quand TAP est cassé à cause de versions incompatibles ou d’une mise à niveau à moitié ratée, « réinstaller OpenVPN » laisse parfois le package pilote cassé en place.
Windows est poli de cette façon. Utilisez pnputil pour énumérer et supprimer l’ancien INF OEM, puis installez à neuf.

3) Ne combattez pas la signature des pilotes avec des hacks

Si le problème est l’application de la signature ou une baseline de sécurité renforcée, ne jouez pas à « test signing » ou à désactiver les contrôles d’intégrité « juste pour une minute ».
Cette minute devient une année. Utilisez un pilote qui correspond à votre build Windows et qui est correctement signé. Si votre organisation utilise Memory Integrity / HVCI, validez la compatibilité.

4) Reconnaissez quand TAP est le mauvais outil

Si vous ne faites pas vraiment de pontage couche‑2 et que votre build OpenVPN prend en charge Wintun, passer de TAP à Wintun peut réduire les pannes à long terme.
Ce n’est pas une prise de position morale ; c’est opérationnel. Moins de pièces mobiles signifie moins de tickets à 2 h du matin.

5) Soyez strict sur le nommage et la sélection des adaptateurs

Avoir plusieurs adaptateurs TAP avec des noms similaires est la recette du théâtre « ça marche sur ma machine ». Nommez les adaptateurs de façon cohérente et référez-vous à eux explicitement quand c’est possible.
Si vous gérez des clients centralement, standardisez le package client pour que le nom et le comportement de l’adaptateur soient cohérents sur l’ensemble du parc.

Citation (idée paraphrasée), attribuée : Werner Vogels souligne souvent que « tout échoue, tout le temps » — les systèmes gagnent en concevant pour la récupération, pas pour la perfection.

Erreurs courantes : symptôme → cause racine → correction

1) « Aucun adaptateur TAP trouvé »

Symptôme : Le journal OpenVPN indique aucun adaptateur TAP ; le Gestionnaire de périphériques n’en affiche aucun.

Cause racine : Pilote TAP non installé, supprimé par un outil de sécurité, ou installation bloquée.

Correction : Énumérez les pilotes avec pnputil /enum-drivers, réinstallez à l’aide d’un installeur OpenVPN fiable ou avec tapctl. Vérifiez le journal Système pour les blocages de signature.

2) L’adaptateur TAP existe mais affiche « Code 10 » / « le périphérique ne peut pas démarrer »

Symptôme : Code d’erreur dans le Gestionnaire de périphériques ; l’adaptateur bascule mais ne démarre pas correctement.

Cause racine : Version de pilote incompatible, enforcement de signature, ou conflits avec des filtres NDIS.

Correction : Supprimez le package pilote avec pnputil /delete-driver ... /force, redémarrez, réinstallez un pilote signé compatible. Inspectez les filtres NDIS tiers.

3) Le VPN « se connecte » mais aucune ressource interne ne fonctionne

Symptôme : « Initialization Sequence Completed », mais les sous-réseaux internes sont injoignables.

Cause racine : Routes manquantes (serveur ne pousse pas les routes, ou client n’applique pas), mauvaise métrique d’interface, ou problèmes de profil de pare-feu.

Correction : Vérifiez route print et les métriques. Validez les routes poussées dans le journal OpenVPN. Confirmez la catégorie réseau TAP et les règles de pare-feu.

4) Le DNS échoue uniquement lorsque le VPN est connecté

Symptôme : Le DNS public fonctionne avant la connexion ; après connexion, la résolution de noms se bloque ou résout mal les noms internes.

Cause racine : Affectation de serveurs DNS et priorité par interface / conflits NRPT, parfois aggravés par des clients DNS « intelligents ».

Correction : Inspectez le DNS par interface avec Get-DnsClientServerAddress. Utilisez le routage DNS basé sur le domaine (NRPT en entreprise) ou ajustez les options OpenVPN.

5) Bloqué sur « Assigning IP »

Symptôme : OpenVPN se connecte puis reste bloqué lors de l’application de l’IP.

Cause racine : Le pilote TAP n’accepte pas la configuration de type DHCP, ou le pare-feu/politique locale bloque le chemin de configuration.

Correction : Confirmez la ligne de journal indiquant la définition de l’IP DHCP ; vérifiez que l’interface affiche une adresse IPv4. Si non, réinstallez le pilote et vérifiez les journaux d’événements pour les échecs au niveau pilote.

6) Ça marche en Wi‑Fi mais pas en Ethernet (ou inversement)

Symptôme : Le VPN est OK sur un type de liaison, cassé sur l’autre.

Cause racine : Métriques de route et préférence DNS par interface ; parfois des filtres de sécurité différents sur les NIC physiques.

Correction : Inspectez les métriques/routes après connexion. Si nécessaire, définissez des métriques explicites ou ajustez la configuration split/full tunnel. Comparez les liaisons et pilotes filtre entre adaptateurs.

7) Réinstaller OpenVPN n’a rien réparé

Symptôme : « J’ai réinstallé deux fois. » TAP toujours cassé.

Cause racine : L’ancien package pilote reste dans DriverStore ; la réinstallation le réutilise.

Correction : Supprimez avec pnputil par le nom publié, puis réinstallez. Vérifiez le fournisseur/la version ensuite.

Blague #2 : Réinstaller OpenVPN sans supprimer l’ancien package pilote, c’est comme mettre des pneus neufs sur une voiture avec un essieu tordu — techniquement vous avez fait quelque chose, pratiquement vous tremblez encore.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé une nouvelle baseline de durcissement Windows. Rien d’exotique : enforcement plus strict des pilotes, quelques protections noyau,
et un lot de mises à jour d’endpoint security. Le déploiement a été par étapes : « unités métier d’abord », puis l’IT, puis l’ingénierie.

Le troisième jour, la file d’assistance s’est remplie de « le VPN se connecte mais rien ne marche ». L’équipe réseau a d’abord supposé, classiquement : « le concentrateur VPN est surchargé ».
Ils ont monté l’échelle serveur, ajusté les ciphers, même modifié les keepalive — parce que les journaux OpenVPN sur le serveur semblaient occupés et que cela ressemblait à une preuve.

Pendant ce temps, les portables affectés avaient tous une chose en commun : le pilote TAP était présent mais n’arrivait pas à démarrer. Code 10 dans le Gestionnaire de périphériques. Les journaux OpenVPN du client
mentionnaient l’adaptateur, mais n’appliquaient jamais correctement la configuration IP. L’hypothèse erronée était de traiter ça comme un problème côté serveur à cause du timing corrélé.

La vraie correction a été côté client : un package pilote TAP signé et compatible plus une exception de politique pour une classe de pilote spécifique sous la nouvelle baseline.
Après cela, les changements serveurs ont été annulés. Ça n’a pas fait de mal, mais n’a pas résolu le vrai problème. Leçon opérationnelle : ne laissez pas un timing corrélé vous pousser vers la mauvaise couche.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une organisation globale voulait accélérer le VPN pour les gros transferts et les opérations Git internes. Quelqu’un a proposé une « optimisation simple » :
modifier les métriques d’interface pour que l’interface VPN gagne toujours, même pour le trafic Internet public. Full-tunnel pour tout le monde, tout le temps.

Ça a marché en laboratoire. En production, cela a créé une panne lente. Les utilisateurs pouvaient se connecter, mais la navigation web est devenue instable,
et les applications SaaS ont déconnecté les utilisateurs constamment. La latence a explosé parce que le trafic prenait un détour inutile via une passerelle VPN éloignée régionalement.
Pire : la résolution DNS est devenue incohérente parce que Windows sélectionnait les serveurs DNS en fonction de l’interface VPN désormais dominante, même quand il ne le fallait pas.

Le pilote TAP a été blâmé parce qu’il était la partie visible. Des gens ont réinstallé des pilotes, supprimé des adaptateurs et redémarré jusqu’à épuisement.
Mais le pilote TAP faisait exactement ce qu’on lui avait demandé. L’optimisation était le problème : elle a forcé un comportement de routage non aligné avec la conception réseau.

La correction a été moins excitante : revenir au split tunneling avec des routes explicites pour les sous-réseaux internes, et appliquer un routage DNS basé sur le domaine pour les espaces de noms internes.
Les performances se sont améliorées là où ça comptait (interne), et l’Internet public a cessé de prendre le grand tour. Leçon : les métriques de route sont des armes à double tranchant — ne les confiez pas aux « victoires rapides ».

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre entreprise avait une politique : chaque package client VPN était épinglé à une version OpenVPN testée et à une version TAP spécifique.
Pas de mises à jour auto, pas de « le dernier c’est mieux », et surtout pas de mélange de suites VPN packagées par différents fournisseurs. La sécurité validait parce que les mises à jour étaient planifiées et testées.

Puis une mise à jour Windows a resserré la compatibilité des pilotes d’une manière qui a cassé plusieurs adaptateurs VPN tiers dans l’industrie.
Les équipes qui laissaient un zoo de versions clients ont vu le chaos immédiat : des échecs différents par modèle de portable, par privilège utilisateur, par version d’agent de sécurité.

Cette organisation ? Silencieuse. Une poignée de cas limites, mais rien d’équivalent à une panne. Leur gestion du parc a détecté une petite hausse des avertissements d’événements TAP,
et parce que la version du pilote était cohérente, ils ont pu tester un build de pilote de remplacement, valider et le déployer.

La pratique « ennuyeuse » — verrouillage de version plus déploiement contrôlé — n’a gagné aucun prix. Elle a juste maintenu des milliers d’utilisateurs opérationnels.
En exploitation, l’ennui est une fonctionnalité. L’excitation est ce que vous obtenez quand votre processus de changement est du théâtre improvisé.

Listes de contrôle / plan étape par étape

Checklist A : Première réponse (15 minutes, une machine)

Journal OpenVPN : confirmez s’il ouvre l’adaptateur TAP et complète l’initialisation.
Présence de l’adaptateur : Get-NetAdapter et trouver TAP. Si absent, aller vers la voie de réinstallation.
Santé de l’adaptateur : Get-PnpDevice -Class Net pour le statut TAP et vérifier les codes d’erreur du Gestionnaire de périphériques.
Config IP : Get-NetIPConfiguration sur TAP ; confirmez IPv4 et DNS attendus.
Routes : route print ; confirmez que les routes internes attendues existent et que les métriques sont cohérentes.
Sélection DNS : Get-DnsClientServerAddress ; vérifiez que le DNS interne va là où il doit aller.

Checklist B : Réparation propre du pilote (sécurisée, répétable)

Arrêtez OpenVPN GUI/service pour que le pilote ne soit pas « en cours d’utilisation ».
Identifiez le package TAP installé via pnputil /enum-drivers.
Supprimez le package pilote : pnputil /delete-driver oemXX.inf /uninstall /force.
Redémarrez (oui, vraiment — l’état NDIS est tenace).
Installez la build OpenVPN approuvée qui inclut le package pilote correct, ou recréez via tapctl.
Vérifiez le fournisseur/la version via WMI et confirmez que l’adaptateur apparaît dans Get-NetAdapter.
Connectez et revérifiez IP/routes/DNS.

Checklist C : Remédiation sur parc (ne pas DDoS le helpdesk)

Choisissez une version client connue-bonne + version pilote TAP ; testez sur des builds Windows représentatifs (y compris le dernier niveau de patch).
Écrivez un script de détection : TAP présent, version du pilote, statut PnP, et dernières lignes de journal OpenVPN connectées.
Déployez en anneaux : IT d’abord, puis pilote métier, puis déploiement large.
Ayez une porte de sortie : capacité à revenir rapidement au package pilote et à la version client précédents.
Mesurez : avertissements du journal d’événements, échecs de connexion, temps de connexion, échecs de résolution DNS.

FAQ

1) TAP est-il identique à TUN ?

Non. TAP est un concept d’adaptateur Ethernet virtuel (trames couche 2). TUN est un concept d’interface IP virtuelle (paquets couche 3).
Les configs OpenVPN peuvent indiquer dev tun alors que le packaging Windows implique encore des composants TAP dans des installations anciennes — ne supposez pas que le nom correspond à l’intention de la config.

2) Pourquoi Windows crée-t-il plusieurs adaptateurs TAP ?

Les installations/mises à jour, les suppressions ratées et les différents packages clients VPN peuvent tous créer des adaptateurs virtuels supplémentaires. Les périphériques « non présents » restent dans le système.
C’est pourquoi le nettoyage des adaptateurs fantômes est important, surtout sur des portables utilisés longtemps.

3) Que signifie généralement « Code 10 » sur l’adaptateur TAP ?

Cela signifie généralement que le pilote n’a pas pu démarrer — souvent dû à des problèmes de compatibilité, d’enforcement de signature ou de conflits avec des pilotes filtre.
Considérez-le comme un problème de santé du pilote, pas comme un problème de routage.

4) Pourquoi le VPN se connecte mais je n’atteins pas les ressources internes ?

Parce que « connecté » signifie que TLS et l’établissement du tunnel ont réussi. Cela ne garantit pas que les routes, le DNS ou les politiques de pare-feu sont corrects.
Vérifiez route print, les métriques d’interface et les serveurs DNS par interface.

5) Dois-je désactiver IPv6 sur l’adaptateur TAP ?

Seulement si vous avez un mode de défaillance IPv6 spécifique et que vous comprenez les conséquences. Désactiver IPv6 de manière générale est une superstition populaire.
Diagnosez d’abord : fuyez-vous du DNS sur IPv6, ou votre DNS interne est-il inaccessible via v6 ? Corrigez la cause racine plutôt que d’amputer les protocoles.

6) J’ai réinstallé OpenVPN et le pilote TAP est toujours cassé. Pourquoi ?

Parce que Windows peut réutiliser le package pilote existant depuis le DriverStore. Utilisez pnputil pour supprimer l’INF OEM publié, redémarrez, puis installez à neuf.

7) Quel est le moyen le plus rapide de savoir si c’est TAP ou le routage ?

Si OpenVPN ne peut pas ouvrir l’adaptateur ou si l’adaptateur affiche des erreurs PnP, c’est un problème TAP/pilote. Si OpenVPN complète l’initialisation et que l’adaptateur a une IP, c’est probablement le routage/DNS/pare-feu.
La section « Feuille de route pour un diagnostic rapide » est conçue autour de cette séparation.

8) Les logiciels de sécurité endpoint peuvent-ils casser TAP ?

Oui. Beaucoup de produits endpoint ajoutent des pilotes de filtre NDIS. Certains gèrent mal les NIC virtuelles, certains bloquent l’installation des pilotes, et d’autres modifient les profils de pare-feu.
Ne devinez pas — vérifiez les liaisons et les journaux d’événements et réalisez un test contrôlé.

9) Passer à Wintun est-ce une solution valide aux problèmes TAP ?

Parfois. Si votre environnement n’exige pas de pontage couche‑2, passer à Wintun peut réduire les problèmes liés aux pilotes et aux filtres.
Ce n’est pas magique ; c’est moins de fonctionnalités, moins de façons d’échouer.

Conclusion : prochaines étapes pour rester sain d’esprit

Si vous retenez une leçon opérationnelle des pannes TAP, retenez celle-ci : séparez la santé de l’adaptateur de l’intention routage/DNS.
Ne « corrigez » pas les routes quand le pilote ne peut pas démarrer. Ne réinstallez pas les pilotes quand la table de routage est incorrecte. Diagnostiquez, puis agissez.

Prochaines étapes pratiques :

Exécutez la feuille de route rapide sur une machine affectée et notez quelle couche échoue : pilote, état de l’adaptateur, routage, DNS ou profil pare-feu.
Standardisez sur une build OpenVPN connue-bonne et une version pilote TAP (ou Wintun) testée ; verrouillez-la et déployez en anneaux.
Créez un petit audit scriptable : adaptateur présent, statut PnP, version du pilote, et vérifications route/DNS — pour que le prochain incident soit mesuré, pas discuté.
Quand il faut réparer : supprimez proprement l’ancien package pilote, redémarrez, réinstallez, vérifiez. La répétabilité vaut mieux que l’ingéniosité.