OpenVPN « route addition failed » sur Windows : corrections de routage qui fonctionnent vraiment

Procédure de diagnostic rapide

Si vous êtes en conférence et que quelqu’un dit « le VPN est connecté mais rien ne marche », n’errer pas. Faites ceci dans l’ordre. L’objectif est d’identifier rapidement le goulot d’étranglement : privilèges, conflits de routes, sélection d’adaptateur ou contrôles de politique.

1) Identifiez la route exacte en échec (ne devinez pas)

• OpenVPN GUI : ouvrez le journal et cherchez route addition failed.
• Notez le réseau de destination et le masque (ou CIDR), et la passerelle/interface utilisée.
• Si le journal ne montre pas les détails de la route, augmentez la verbosité (verb 4 ou verb 5) et reconnectez.

2) Vérifiez si Windows a rejeté le changement pour cause de privilèges

• Si vous voyez « Access is denied » ou le code d’erreur 5, vous n’êtes pas élevé ou le service ne s’exécute pas avec les droits nécessaires.
• Si vous voyez « The object already exists » ou l’erreur 183, une route en conflit existe déjà dans la table.

3) Déchargez la table de routage et cherchez conflits et métriques

• Cherchez une route existante vers le même réseau destination, en particulier avec une métrique plus faible.
• Cherchez plusieurs routes par défaut (0.0.0.0/0) créées par le Wi‑Fi, Ethernet, Hyper‑V, WSL ou un autre VPN.

4) Validez l’état de l’adaptateur VPN et l’index d’interface

• Si TAP/Wintun est déconnecté, n’a pas d’IP ou a une métrique cassée, les ajouts de route peuvent échouer ou être ignorés.
• Si le serveur pousse des routes pour des sous‑réseaux que vous avez déjà localement, Windows vous « aidera » à créer un trou noir.

5) Si tout semble correct, suspectez des contrôles de sécurité

• Les règles de Windows Defender Firewall, les callouts WFP d’agents de sécurité endpoint et les baselines de durcissement peuvent bloquer les modifications de routes.
• Les outils de « posture VPN » d’entreprise peuvent parfois rivaliser avec OpenVPN et réécrire les routes une seconde plus tard.

C’est le triage. Maintenant nous allons le rendre précis et reproductible.

Ce que signifie réellement « route addition failed » sur Windows

OpenVPN ne « route » pas les paquets. Il demande au système d’exploitation d’installer des routes. Sur Windows, cela implique d’appeler l’API IP Helper (et consorts), qui met ensuite à jour la table de routage. Si Windows refuse la route, OpenVPN journalise l’échec et poursuit—parfois avec une connectivité partielle qui vous fait perdre des heures.

Un ajout de route peut échouer pour quelques raisons peu glamour :

• Privilège : ajouter des routes nécessite des privilèges administratifs. L’OpenVPN GUI peut s’exécuter en tant qu’utilisateur normal. Le service OpenVPN peut ne pas être configuré correctement. Ou UAC fait ce que fait UAC.
• Conflit : la route exacte (destination + masque + passerelle/interface) existe déjà, ou une route plus spécifique existante rend la nouvelle inutile.
• Passerelle/interface invalide : OpenVPN tente d’ajouter la route via une interface qui n’est pas encore prête (problème de timing), n’a pas d’IP, ou n’est pas l’adaptateur que Windows croit être.
• Politique et filtrage : les drivers de sécurité endpoint peuvent bloquer la modification des routes ou les réinitialiser immédiatement après. C’est « amusant » parce qu’OpenVPN peut journaliser un succès alors que les routes disparaissent ensuite.
• Chaos des métriques : Windows choisit la « meilleure » route en utilisant d’abord la longueur du préfixe, puis la métrique. Si les métriques sont mal gérées automatiquement—ou « optimisées » par des humains—vous obtenez des échecs de split‑tunnel et du routage en boucle.

Un modèle mental important : OpenVPN est juste un installateur de routes plus un tunnel. Si Windows n’accepte pas la route, le tunnel est sans objet. Vos paquets continueront à prendre l’ancien chemin comme si rien ne s’était passé.

Blague n°1 : le routage Windows, c’est comme l’attribution des places au bureau—tout le monde a un plan jusqu’à ce que le stagiaire installe un nouveau client VPN et prenne la seule chaise marquée « default gateway ».

Faits et historique qui expliquent la douleur d’aujourd’hui

Un peu de contexte aide car la bizarrerie que vous observez n’est pas aléatoire ; c’est de l’histoire en couches.

1. Windows a longtemps préféré les « métriques automatiques » pour choisir la meilleure interface, et il les change souvent après des événements de lien. Bien pour les consommateurs, déroutant pour le split‑tunneling.
2. L’intégration OpenVPN d’origine sur Windows reposait lourdement sur TAP (interface virtuelle de couche 2). Plus tard, Wintun a amélioré les performances et réduit les problèmes de driver, mais la logique de routage reste pilotée par l’OS.
3. Les anciennes configs OpenVPN utilisaient route-method exe et appelaient littéralement route.exe. Les versions modernes utilisent typiquement les API IP Helper, mais les journaux et modes d’échec référencent encore la sémantique « route add ».
4. Les décisions de routage Windows sont basées sur la « longest prefix match » en premier. Les métriques sont secondaires. Voilà pourquoi une route /24 périmée peut annuler une belle nouvelle route par défaut, et vous jurerez que le VPN « ignore » les réglages.
5. Le split‑tunneling est devenu courant avec le SaaS. Une fois que les entreprises ont arrêté d’envoyer tout le trafic via le siège, les tables de routage se sont compliquées rapidement, surtout sur des portables avec plusieurs adaptateurs virtuels.
6. Les produits de sécurité endpoint accrochent souvent Windows Filtering Platform (WFP). Ils peuvent autoriser le tunnel VPN mais bloquer les changements de route ou certains sous‑réseaux—le tunnel est monté, mais vos CIDR internes sont morts.
7. Les routes poussées par OpenVPN sont « consultatives » : le serveur pousse, le client tente. L’OS arbitre. C’est pourquoi deux clients avec le même profil peuvent se comporter différemment si leurs routes locales diffèrent.
8. Les images d’entreprise incluent fréquemment Hyper‑V, WSL, Docker ou des commutateurs virtuels. Chacun ajoute des routes et peut voler des métriques ou ajouter des plages RFC1918 chevauchantes.

Une citation à garder sur un post‑it, car elle s’applique parfaitement au routage : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan.

Modes d’échec courants : access denied, file exists, not found

« ROUTE: route addition failed » + « Access is denied »

C’est le classique. Vous n’êtes pas élevé, ou OpenVPN ne s’exécute pas dans un contexte pouvant modifier la table de routage. Parfois c’est intermittent parce que le premier ajout de route échoue, mais des ajouts ultérieurs réussissent quand l’adaptateur se lève et déclenche d’autres chemins de code. N’acceptez pas l’intermittence. Corrigez le modèle de privilèges.

« ROUTE: route addition failed » + « The object already exists »

Windows a déjà une route pour cette destination. Peut‑être d’un autre VPN, peut‑être d’une session OpenVPN passée avec des routes persistantes, peut‑être d’un réseau d’adaptateur virtuel (Hyper‑V/WSL/Docker) utilisant des plages qui se chevauchent. OpenVPN tente d’ajouter, Windows dit « déjà là », et OpenVPN le journalise comme un échec même si la route existante peut être correcte—ou catastrophiquement incorrecte.

« ROUTE: route addition failed » + « The network path was not found » / mauvaise passerelle

C’est généralement un problème de sélection d’interface : OpenVPN tente d’ajouter une route via une passerelle qui n’existe pas encore, ou via un index d’interface erroné. Le timing compte sur Windows. L’adaptateur peut être « connecté » mais pas complètement initialisé avec une IP, DNS et paramètres de routage.

« Route added successfully » mais le trafic reste erroné

C’est un comportement de métrique ou de préfixe, pas un échec d’ajout de route. Une route plus spécifique (ou une métrique plus basse) gagne et envoie le trafic ailleurs. Ou votre trafic atteint le VPN, mais le routage de retour ou les règles du firewall le bloquent. Votre « correction » est d’arrêter de fixer le journal OpenVPN et de commencer à interroger la sélection de route par l’OS.

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

Vous voulez des tâches à exécuter, des sorties à interpréter et des décisions à prendre sans devenir archéologue réseau à temps partiel. Les voici. Exécutez‑les sur le client Windows. Utilisez PowerShell ou CMD en mode élevé lorsque nécessaire.

Task 1: Confirm you’re actually elevated (yes, really)

cr0x@server:~$ whoami /groups | findstr /i "S-1-5-32-544"
BUILTIN\Administrators Alias S-1-5-32-544 Enabled group, Enabled by default, Group owner

Ce que cela signifie : Si vous ne voyez pas le groupe Administrators activé, vous n’êtes pas élevé. L’OpenVPN GUI lancé normalement est souvent non‑élevé, même si votre utilisateur est « admin ».

Décision : Relancez OpenVPN GUI en « Exécuter en tant qu’administrateur » ou utilisez le service OpenVPN avec les privilèges appropriés.

Task 2: Capture the failing route from the OpenVPN log

cr0x@server:~$ type "C:\Program Files\OpenVPN\log\client.log" | findstr /i "route addition failed"
2025-12-27 09:11:54 ROUTE: route addition failed using CreateIpForwardEntry: Access is denied.   [status=5 if_index=23]

Ce que cela signifie : Le statut 5 est un problème de privilège. Le if_index est l’interface que Windows a tenté d’utiliser.

Décision : Corrigez le privilège d’abord. Si vous êtes déjà élevé, suspectez les contrôles endpoint qui bloquent les modifications de route.

Task 3: Dump routing table and look for the target subnet

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.50     35
        10.20.0.0    255.255.0.0         On-link       10.8.0.2      5
        10.20.0.0    255.255.0.0      192.168.1.1    192.168.1.50     25
===========================================================================

Ce que cela signifie : Deux routes vers 10.20.0.0/16. La route « On‑link » du VPN a une meilleure métrique (5), donc elle devrait gagner. Si la moins bonne gagne, vous avez probablement une route plus spécifique ailleurs ou des routes pilotées par une politique.

Décision : Si la « mauvaise » route a la meilleure métrique, supprimez‑la ou ajustez les métriques. Si les deux existent, décidez quelle interface doit posséder ce sous‑réseau et appliquez‑le.

Task 4: Confirm interface indexes and names match the OpenVPN log

cr0x@server:~$ netsh interface ipv4 show interfaces
Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 11          25        1500  connected     Wi-Fi
 23           5        1500  connected     OpenVPN Wintun

Ce que cela signifie : Idx 23 correspond au journal. Bien. Si le journal référence un index qui n’existe plus, vous avez un adaptateur obsolète ou du churn de driver.

Décision : En cas de mismatch d’index : supprimez les adaptateurs TAP/Wintun obsolètes et réinstallez proprement, ou mettez à jour le profil OpenVPN pour utiliser le bon type d’appareil.

Task 5: Verify the VPN adapter has an IP and the expected gateway behavior

cr0x@server:~$ ipconfig /all
Ethernet adapter OpenVPN Wintun:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . : OpenVPN Wintun
   Physical Address. . . . . . . . . : 00-FF-12-34-56-78
   DHCP Enabled. . . . . . . . . . . : No
   IPv4 Address. . . . . . . . . . . : 10.8.0.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 

Ce que cela signifie : Beaucoup de setups OpenVPN utilisent un /32 sur l’interface tunnel et ne définissent pas de passerelle par défaut là‑dessus. C’est normal. Le routage doit toujours fonctionner via des routes on‑link.

Décision : S’il n’y a pas d’IP du tout, votre tunnel n’est pas réellement configuré ; réglez cela avant de chasser les routes.

Task 6: Check for overlapping RFC1918 routes from local networks

cr0x@server:~$ route print | findstr /r "10\. 172\.16\. 192\.168\."
        10.0.0.0        255.0.0.0      192.168.1.1    192.168.1.50     25
      192.168.0.0    255.255.0.0         On-link     192.168.1.50    281

Ce que cela signifie : Si votre réseau local route déjà 10.0.0.0/8 via la passerelle domestique/bureau, et que le VPN veut aussi des parties de 10/8, vous êtes en « pays de chevauchement ». Windows utilisera le préfixe le plus spécifique, mais la route locale large peut encore casser des routes VPN moins spécifiques.

Décision : Préférez des adresses internes non chevauchantes si vous les contrôlez. Si vous ne les contrôlez pas, poussez des routes plus spécifiques depuis OpenVPN (par ex. /16 ou /24 au lieu de /8) et supprimez les routes locales larges quand c’est possible.

Task 7: Delete a conflicting route (surgical, not scorched-earth)

cr0x@server:~$ route delete 10.20.0.0 mask 255.255.0.0 192.168.1.1
 OK!

Ce que cela signifie : Vous avez supprimé la route qui volait le trafic au VPN.

Décision : Reconnectez le VPN et vérifiez qu’OpenVPN peut ajouter la route prévue. Si la route conflictuelle réapparaît, un acteur (service, autre VPN, script, GPO) la réinstalle—chassez cet acteur, pas le symptôme.

Task 8: Add a route manually to prove the OS will accept it

cr0x@server:~$ route add 10.20.0.0 mask 255.255.0.0 10.8.0.1 metric 5
 OK!

Ce que cela signifie : Windows a accepté la route. Si OpenVPN ne peut toujours pas l’ajouter, vous avez probablement un problème de privilège/contexte (GUI vs service) ou un problème de timing.

Décision : Si l’ajout manuel fonctionne uniquement dans une session élevée, OpenVPN doit s’exécuter élevé ou en tant que service. Si l’ajout manuel échoue même élevé, suspectez WFP/politique de sécurité ou une passerelle invalide.

Task 9: Confirm actual route selection for a target IP

cr0x@server:~$ powershell -Command "Get-NetRoute -DestinationPrefix 10.20.5.10/32 | Sort-Object -Property RouteMetric | Format-Table -AutoSize"
DestinationPrefix NextHop     InterfaceAlias  RouteMetric PolicyStore
----------------- -------     --------------  ----------- -----------
10.20.5.10/32     10.8.0.1    OpenVPN Wintun  5           ActiveStore

Ce que cela signifie : Cela montre quelle route Windows utilisera pour cette destination spécifique (ou du moins les candidates). Une route hôte /32 est décisive.

Décision : Si la route pointe vers le Wi‑Fi/Ethernet au lieu du VPN, vous avez un conflit de préfixe/métrique. Corrigez la route en conflit ou ajoutez une route plus spécifique via le VPN.

Task 10: Check whether Windows is auto-managing interface metrics poorly

cr0x@server:~$ powershell -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric | Format-Table -AutoSize"
ifIndex InterfaceAlias        NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState
------- --------------        ------------ --------------- ----     ---------------
23      OpenVPN Wintun        1500         5               Disabled Connected
11      Wi-Fi                 1500         25              Enabled  Connected

Ce que cela signifie : Une métrique plus basse l’emporte quand la longueur de préfixe est à égalité. Une métrique VPN plus basse que le Wi‑Fi est généralement ce que vous voulez pour un full‑tunnel, et souvent ce que vous voulez pour le split‑tunnel si vous comptez sur les métriques pour la route par défaut.

Décision : Si la métrique du VPN est plus élevée que le Wi‑Fi et que vous attendez que le trafic passe par le VPN par défaut, affectez une métrique plus basse à l’interface VPN ou poussez explicitement une route par défaut via le VPN.

Task 11: Disable automatic metrics on a specific interface (controlled change)

cr0x@server:~$ powershell -Command "Set-NetIPInterface -InterfaceAlias 'OpenVPN Wintun' -AutomaticMetric Disabled -InterfaceMetric 5"

Ce que cela signifie : Vous avez fixé la métrique. Cela supprime une source d’aléa « ça marchait hier ».

Décision : Ne faites cela que si vous contrôlez la baseline du portable ou si vous écrivez un playbook de support. Les métriques comme tweak utilisateur sont fragiles ; elles dérivent avec les renommages d’adaptateurs et les reconstructions.

Task 12: Confirm the OpenVPN process context (GUI vs service)

cr0x@server:~$ sc query OpenVPNService
SERVICE_NAME: OpenVPNService
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING

Ce que cela signifie : Si le service tourne, les routes peuvent être installées par le service même si le GUI n’est pas élevé (selon votre build/config). S’il est arrêté, le GUI doit être élevé pour ajouter des routes.

Décision : Standardisez : exécutez soit en service pour la cohérence, soit imposez « Exécuter en tant qu’administrateur » pour le GUI. Mixer les deux crée des tickets.

Task 13: Verify DNS behavior when routes are fine but apps still fail

cr0x@server:~$ nslookup internal-app.corp
Server:  UnKnown
Address:  192.168.1.1

*** internal-app.corp can't find internal-app.corp: Non-existent domain

Ce que cela signifie : Vous interrogez votre DNS local (routeur domestique) au lieu du DNS d’entreprise. Le routage peut être parfait ; la résolution de noms vous sabote.

Décision : Corrigez les options DNS poussées, utilisez block-outside-dns quand approprié, ou définissez le DNS de l’interface VPN via une politique.

Task 14: Detect whether another VPN client is also installed and interfering

cr0x@server:~$ powershell -Command "Get-NetAdapter | Select-Object Name,InterfaceDescription,Status | Format-Table -AutoSize"
Name             InterfaceDescription                      Status
----             --------------------                      ------
Wi-Fi            Intel(R) Wi-Fi 6 AX200 160MHz             Up
OpenVPN Wintun   OpenVPN Wintun                            Up
CorpVPN          Acme SecureConnect Virtual Adapter        Up

Ce que cela signifie : Deux adaptateurs VPN actifs en même temps n’apportent pas « plus de sécurité ». C’est de la roulette de routes.

Décision : Choisissez un VPN. Désactivez ou déconnectez l’autre avant de connecter OpenVPN, sauf si vous supportez explicitement des tunnels en chaîne (la plupart des organisations ne le font pas, et Windows n’aime pas ça).

Task 15: Prove packet path with traceroute (when routing lies to you)

cr0x@server:~$ tracert -d 10.20.5.10

Tracing route to 10.20.5.10 over a maximum of 30 hops

  1     2 ms     1 ms     2 ms  10.8.0.1
  2    15 ms    14 ms    15 ms  10.20.0.1
  3    18 ms    17 ms    18 ms  10.20.5.10

Trace complete.

Ce que cela signifie : Si hop 1 est votre routeur domestique (192.168.1.1) au lieu de la passerelle VPN (souvent 10.8.0.1 ou similaire), votre trafic n’entre pas dans le tunnel.

Décision : Corrigez la sélection de route. Si traceroute entre dans le VPN mais meurt plus loin, le problème est côté serveur (routage/firewall), pas un ajout de route Windows.

Task 16: Check Windows event logs for driver or filter issues (route changes blocked)

cr0x@server:~$ powershell -Command "Get-WinEvent -LogName System -MaxEvents 30 | Where-Object {$_.Message -match 'Wintun|TAP|filter|WFP'} | Select-Object TimeCreated,Id,ProviderName,Message | Format-List"
TimeCreated : 12/27/2025 9:12:10 AM
Id          : 5007
ProviderName: Microsoft-Windows-Windows Firewall With Advanced Security
Message     : Windows Firewall settings were changed.

Ce que cela signifie : Ce n’est pas une preuve formelle en soi, mais des changements au moment de la connexion peuvent se corréler avec des échecs de route ou des pertes de trafic. Les agents de sécurité basculent souvent les profils de firewall quand un VPN monte.

Décision : Si vous voyez des événements constants lors de la connexion, coordonnez‑vous avec les responsables des outils de sécurité. Votre « problème réseau » peut être un moteur de politique qui fait mal son travail.

Erreurs courantes : symptôme → cause racine → correction

Symptôme : « route addition failed: Access is denied »

Cause racine : OpenVPN GUI non élevé ; service arrêté ; tokens UAC ; ou endpoint security bloquant les écritures de route.

Correction : Exécutez OpenVPN GUI en administrateur ou exécutez OpenVPN comme service Windows avec les permissions adéquates. Si vous êtes déjà élevé, testez un route add manuel ; si cela échoue aussi, escaladez vers l’équipe de sécurité endpoint/WFP.

Symptôme : « route addition failed: The object already exists »

Cause racine : Route existante vers le même préfixe depuis un autre VPN, une route persistante, ou un réseau d’adaptateur virtuel (Hyper‑V/WSL/Docker) utilisant des plages qui se chevauchent.

Correction : Supprimez la route conflictuelle ; arrêtez l’acteur qui la réajoute ; évitez les sous‑réseaux internes qui se chevauchent ; poussez des routes plus spécifiques ; désactivez le second adaptateur VPN.

Symptôme : le VPN se connecte, mais seuls certains sous‑réseaux internes fonctionnent

Cause racine : Conflits de split‑tunneling. Un sous‑ensemble de routes a échoué à s’installer, souvent celles qui chevauchent des réseaux locaux ou celles poussées avant que l’adaptateur ne soit stabilisé.

Correction : Augmentez la verbosité du journal pour voir quelles plages précises ont échoué. Ajoutez un route-delay ou assurez‑vous que l’adaptateur est prêt. Supprimez les routes locales qui se chevauchent ou changez les préfixes poussés.

Symptôme : la route est présente, mais le trafic sort encore par le Wi‑Fi

Cause racine : Règles de métrique et de préfixe : une route plus spécifique existe ailleurs, ou un routage basé sur une politique d’un autre logiciel gagne.

Correction : Utilisez Get-NetRoute pour l’IP de destination exacte, pas seulement le sous‑réseau. Supprimez la route conflictuelle plus spécifique, ou ajoutez une route /32 hôte via le VPN pour les endpoints critiques.

Symptôme : les noms internes ne se résolvent pas, mais le ping par IP fonctionne

Cause racine : DNS non poussé ou non appliqué. Windows continue d’utiliser des serveurs DNS locaux ; les politiques de split‑DNS manquent.

Correction : Poussez le serveur DNS et les options de domaine depuis le VPN ; appliquez block-outside-dns si supporté ; validez la sélection DNS avec nslookup.

Symptôme : tout fonctionne pendant 30–90 secondes, puis casse

Cause racine : Un autre agent réécrit les routes après que le VPN se connecte : « optimisation réseau », posture checking, logiciel de roaming Wi‑Fi, ou un autre client VPN qui répare ses propres routes.

Correction : Surveillez la table de routage dans le temps ; identifiez le process/service ; désactivez l’agent concurrent ou appliquez une politique de route déterministe (routes possédées par le service, métriques figées).

Symptôme : « Cannot find device » / erreurs d’index d’interface dans le journal

Cause racine : Adaptateurs TAP/Wintun obsolètes, réinstallation de driver, mise à jour Windows qui remanie les index d’interface.

Correction : Supprimez les adaptateurs inutilisés, réinstallez le driver correct et standardisez sur Wintun quand c’est possible pour réduire la dérive TAP legacy.

Blague n°2 : Si vous avez « réglé » le routage en désactivant chaque adaptateur jusqu’à ce que ça marche, félicitations—vous avez réinventé la gestion du changement, mais avec plus de panique.

Trois mini-récits d’entreprise issus de la production

Mini‑récit 1 : l’incident causé par une fausse hypothèse

L’entreprise avait une histoire propre : « OpenVPN pousse des routes ; les clients obéissent ; terminé. » Cette hypothèse tenait sur les portables des développeurs et a cassé sur les portables des cadres—ceux équipés d’un agent de sécurité avec des hooks noyau et un goût pour les « paramètres protecteurs ».

Le symptôme était classique : le VPN connecté, quelques applis internes fonctionnaient, tout ce qui appartenait à un sous‑réseau particulier expirait. L’ingénieur de garde (qui avait vu suffisamment de tickets VPN pour vieillir d’une décennie) est allé droit à la table de routage et a trouvé la route /16 poussée manquante. OpenVPN avait journalisé route addition failed avec le statut 5 sur ces machines.

La mauvaise hypothèse : « Statut 5 signifie que l’utilisateur n’a pas lancé en admin. » Ils étaient admins. Ils étaient élevés. Un route add manuel échouait encore. C’est à ce moment‑là que l’équipe a cessé de blâmer les humains et a commencé à blâmer la plateforme.

Ils ont corrélé les échecs de route au moment de la connexion avec des mises à jour de politique de l’agent de sécurité et ont trouvé une règle empêchant la modification des routes vers « les plages privées non explicitement approuvées ». La politique visait à empêcher les malwares de rerouter le trafic local. Elle empêchait aussi les clients VPN de faire leur travail à moins qu’ils n’enregistrent leurs routes dans une allowlist spécifique au vendor.

La résolution fut ennuyeuse : coordination avec la sécurité, ajout des sous‑réseaux VPN à l’allowlist, et documentation que OpenVPN a besoin de la capacité d’écrire des routes. La leçon n’était pas « la sécurité est mauvaise ». La leçon était que le routage Windows n’est pas un terrain privé—d’autres locataires y vivent.

Mini‑récit 2 : l’optimisation qui a mal tourné

Une équipe réseau voulait un Internet plus rapide en VPN. Ils sont passés du full‑tunnel au split‑tunnel et n’ont poussé qu’une poignée de routes internes. Puis ils ont voulu simplifier et ont poussé une route large : 10.0.0.0/8. « Une route c’est plus simple que vingt », disaient‑ils. Ils n’avaient pas totalement tort. Ils n’avaient pas totalement raison non plus.

Les utilisateurs ont commencé à se plaindre que, dans certains hôtels, rien d’interne ne fonctionnait. À la maison tout allait bien. Au bureau tout allait bien. À l’hôtel : mort. Les journaux VPN montraient des échecs d’ajout de route pour 10/8. Windows disait que la route existait déjà.

Le détail manquant : ces hôtels utilisaient aussi 10/8 en interne. La passerelle locale Wi‑Fi installait une route 10/8, et Windows la traitait comme n’importe quelle autre. La route OpenVPN poussée pour 10/8 entrait en collision. Parfois Windows gardait la locale. Parfois il acceptait celle du VPN mais les métriques favorisaient le mauvais chemin. Quoi qu’il en soit, le split‑tunneling est devenu pile ou face.

La correction fut l’inverse de l’« optimisation » : arrêter de pousser 10/8. Pousser seulement les préfixes réels de l’entreprise (des /16 et /24 plus spécifiques). Oui, c’est plus de routes. C’est aussi ce qu’ils voulaient dire à l’origine. Ils ont ajouté une vérification dans la documentation d’onboarding : si votre réseau local chevauche, attendez‑vous à des douleurs—et ne prétendez pas que c’est la faute de l’utilisateur.

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

Une autre organisation avait une politique terne : tous les clients VPN Windows fonctionnent en tant que services, pas en mode GUI utilisateur. Tout le monde grognait parce que ça paraissait « entreprise ». Puis une mise à jour Windows est passée et a changé la façon dont les tokens UAC se comportaient pour un sous‑ensemble d’appareils avec certains baselines de durcissement.

Les équipes qui comptaient sur « Exécuter en tant qu’administrateur » ont commencé à voir des échecs d’ajout de route. Leurs SOPs étaient soudainement fausses. Les gens ont fait la danse habituelle : réinstaller OpenVPN, réinitialiser la pile réseau, redémarrer, jurer contre le portable, recommencer.

L’organisation avec les clients en service a à peine remarqué. Le service OpenVPN tournait avec des privilèges cohérents et installait les routes de façon déterministe. Leur incident fut un non‑événement : quelques utilisateurs ont eu des problèmes de driver d’adaptateur, mais les échecs d’ajout de route n’en faisaient pas partie.

La pratique salvatrice n’était pas glamour. C’était la standardisation : une méthode d’installation, un contexte d’exécution, des journaux cohérents et des privilèges prévisibles. Quand Windows change sous vos pieds—et il le fera—vous voulez moins d’éléments mouvants, pas plus de folklore.

Listes de contrôle / plan pas-à‑pas

Étapes pas‑à‑pas : réparer les échecs d’ajout de route sur une machine Windows

1. Récupérez la route exacte en échec depuis le journal OpenVPN (destination, masque, passerelle, index d’interface et code d’état Windows).
2. Confirmez l’élévation (whoami /groups). Si non élevé, arrêtez et corrigez le contexte d’exécution.
3. Confirmez l’index/nom de l’adaptateur avec netsh interface ipv4 show interfaces. Si le journal référence un index mort, nettoyez les adaptateurs obsolètes.
4. Dump des routes (route print) et trouvez les conflits pour ce préfixe. Décidez quelle route doit l’emporter.
5. Supprimez les routes conflictuelles de manière chirurgicale. Reconnectez le VPN. Vérifiez que la route apparaît et reste en place.
6. Vérifiez la sélection réelle de route pour une IP interne spécifique en utilisant Get-NetRoute ou tracert.
7. Validez le DNS avec nslookup pour être sûr d’utiliser le résolveur prévu.
8. Surveillez la churn des routes (changements de table après la connexion). Si les routes reviennent en arrière, identifiez le service/logiciel concurrent.

Checklist : ce qu’il faut standardiser à l’échelle du parc (pour que cela cesse de revenir)

• Mode d’exécution : choisissez OpenVPN en service ou GUI élevé ; ne mélangez pas sans raison.
• Stratégie d’adaptateur : standardisez sur Wintun quand c’est supporté ; retirez le fouillis TAP legacy.
• Plan d’adressage : évitez de pousser des plages privées larges qui entrent en collision avec les réseaux domestiques/hôtels.
• Politique de routes : poussez des routes explicites et spécifiques ; évitez « une grosse route » sauf si vous contrôlez étroitement l’environnement client.
• Métriques : définissez qui doit gagner (VPN vs LAN) et appliquez des métriques quand nécessaire ; documentez le pourquoi.
• Coordination sécurité : assurez‑vous que les contrôles endpoint permettent l’installation de routes pour vos sous‑réseaux VPN.
• Journaux : stockez les journaux clients à un emplacement connu ; réglez une verbosité suffisante pour le dépannage sans transformer les logs en romans.

Étapes pas‑à‑pas : quand le problème est réellement côté serveur

1. Si traceroute montre que le hop 1 est la passerelle VPN mais que le trafic meurt ensuite, arrêtez de modifier les routes Windows.
2. Confirmez que le serveur pousse les bonnes routes et que le serveur sait retourner le trafic dans le tunnel.
3. Vérifiez les règles de firewall sur le concentrateur VPN et les routeurs internes pour le pool d’adresses clients VPN.
4. Validez que les réseaux internes savent comment atteindre le sous‑réseau client VPN (ou que le NAT est configuré volontairement).

FAQ

1) Pourquoi OpenVPN dit « route addition failed » mais le VPN se connecte quand même ?

Parce que l’établissement du tunnel et l’installation des routes sont des étapes séparées. TLS peut réussir, l’adaptateur peut se lever, et les ajouts de route peuvent encore échouer. L’interface affiche « connecté », vos paquets ne sont pas d’accord.

2) « The object already exists » est‑ce vraiment un problème ?

Parfois oui, parfois non. Si la route existante pointe vers la bonne interface/passerelle, vous pourriez être OK. Si elle pointe vers le Wi‑Fi ou un autre VPN, vous avez une panne partielle ou totale. Vérifiez toujours l’interface et la métrique de la route existante.

3) Ai‑je besoin de TAP ou Wintun ?

La plupart des déploiements Windows modernes devraient privilégier Wintun sauf besoin legacy spécifique. TAP a plus de baggage historique. Mais changer de driver ne résoudra pas magiquement les conflits de route ou les problèmes de privilège ; ça réduit juste l’instabilité liée au driver.

4) Pourquoi les routes échouent seulement sur certains réseaux Wi‑Fi ?

À cause des espaces IP privés qui se chevauchent et des routes locales « utiles ». Hôtels, cafés et certains réseaux invités d’entreprise aiment utiliser 10/8. Si votre VPN pousse des plages larges, vous entrez en collision et Windows choisit un gagnant que vous n’avez pas voté.

5) Comment savoir quelle interface Windows utilisera pour une IP interne ?

Ne regardez pas la table de routage et ne devinez pas. Interrogez la destination spécifique avec Get-NetRoute pour cette IP (ou utilisez tracert et regardez le hop 1). Ça vous indique la sélection de chemin réelle.

6) La sécurité endpoint peut‑elle vraiment bloquer les ajouts de route ?

Oui. Les callouts WFP et les politiques de durcissement peuvent refuser ou rétablir les changements de route. Le symptôme ressemble à « OpenVPN cassé », mais la cause racine est « écriture de routes non autorisée » ou « routes réécrites après la connexion ».

7) Dois‑je utiliser des routes persistantes pour stabiliser ?

Seulement si vous contrôlez le poste et que vous savez pourquoi vous en avez besoin. Les routes persistantes peuvent survivre aux sessions VPN et provoquer de bizarres échecs « pourquoi le trafic va dans un tunnel mort » plus tard. Préférez des routes déterministes au moment de la connexion gérées par le service VPN.

8) Ma route existe, mais les applis internes échouent encore. Et maintenant ?

Vérifiez d’abord le DNS, puis le firewall. Si vous pouvez pinguer par IP mais pas par nom, c’est du DNS. Si vous résolvez les noms mais que le TCP échoue, regardez les règles firewall et le routage de retour côté serveur. Le routage est nécessaire, pas suffisant.

9) Changer les métriques d’interface est‑ce une bonne solution long terme ?

Ça peut l’être, mais c’est tranchant. Figurer les métriques marche mieux quand c’est déployé via une politique et validé sur plusieurs modèles matériels. Comme tweak ponctuel utilisateur, c’est fragile—les noms d’adaptateur et les indices changent, et votre « fix » devient une histoire de fantômes.

Conclusion : prochaines étapes qui tiennent

« Route addition failed » n’est pas un bug mystérieux d’OpenVPN. C’est Windows qui refuse un changement de route pour une raison : privilège, conflit, disponibilité d’interface ou politique. La solution qui marche est celle qui correspond au mode d’échec.

Faites ceci ensuite :

1. Capturer la route exacte en échec et le code d’état Windows depuis le journal OpenVPN.
2. Prouver la sélection de route pour une IP interne cassée en utilisant Get-NetRoute ou tracert.
3. Éliminer les conflits (routes qui se chevauchent, doubles adaptateurs VPN, routes persistantes obsolètes).
4. Standardiser le modèle de privilège : le VPN en service est terne mais correct, et le terne est sous‑estimé en production.
5. Coordonner avec les outils de sécurité si les ajouts manuels de route échouent même quand vous êtes élevé.

Si vous adoptez une seule habitude : arrêtez de considérer « connecté » comme un signal de succès. Considérez la table de routage comme la source de vérité. Ce n’est pas glamour, mais ça évite de passer la matinée sur un ticket VPN que vous auriez pu clore en cinq minutes.