WSL2 hors ligne sous VPN : j’accusais DNS, mais `vEthernet (WSL)` se retrouvait du mauvais côté du pare-feu

Je venais d’activer une option que je considérais comme une amélioration. Bloquer l’accès au réseau local lorsque le VPN est connecté. Sur Windows, tout semblait parfait. Le navigateur ouvrait les pages normalement. Teams fonctionnait. Le VPN affichait connecté.

Mon adresse IP publique avait bien changé.

Puis je suis retourné dans Ubuntu sous WSL2 pour lancer :

sudo apt update

Attente. Erreur réseau. J’ai essayé git fetch. Même chose. Docker n’arrivait plus à récupérer une image. Je coupe le VPN. Tout repart immédiatement. Je le rallume. Windows reste en ligne. WSL devient aveugle.

Comme beaucoup de problèmes WSL finissent par ressembler à des problèmes DNS, j’ai commencé par /etc/resolv.conf. J’ai redémarré WSL. J’ai essayé une adresse IP directement.

Toujours rien. C’est là que j’ai compris que je cherchais du mauvais côté. Ubuntu n’avait pas oublié comment utiliser Internet. Le chemin entre WSL et Windows venait simplement d’être pris dans les règles du VPN.

WSL2 ressemble à une application Windows, mais son réseau ne l’est pas

C’est facile à oublier tant que tout fonctionne.

J’ouvre Windows Terminal, je tape wsl, et Linux apparaît presque instantanément. Visuellement, Ubuntu ressemble à une application Windows de plus.

Mais WSL2 fonctionne dans un environnement virtualisé, avec sa propre couche réseau.

Dans son fonctionnement historique en NAT, Windows crée un réseau virtuel pour WSL. Microsoft propose aussi un mode mirrored, conçu notamment pour mieux faire cohabiter WSL avec des configurations réseau complexes et certains VPN.

Microsoft a également ajouté dnsTunneling pour réduire les pannes de résolution DNS lorsque Windows change de réseau ou lorsqu’un VPN modifie les DNS disponibles.

Tout cela explique pourquoi modifier /etc/resolv.conf est devenu le réflexe de tant d’utilisateurs.

Dans mon cas, pourtant, le DNS n’était que la fausse piste la plus visible.

Le trafic WSL peut aussi être filtré par le pare-feu Hyper-V. Microsoft attribue à WSL son propre VMCreatorId et prévoit des règles spécifiques pour ce trafic virtualisé.

Autrement dit, entre : Windows a Internet et : WSL a Internet, il existe une petite frontière invisible. Et mon VPN venait de la fermer.

Le test par adresse IP m’a fait arrêter de réparer DNS

Depuis WSL, un nom de domaine échouait. Mais une connexion directe vers une adresse IP extérieure échouait elle aussi. À ce moment-là, continuer à modifier les serveurs DNS n’avait plus beaucoup de sens. J’ai regardé les interfaces réseau Windows. Wi-Fi. Interface VPN. Puis :

vEthernet (WSL ...)

L’option « bloquer le réseau local » a soudain changé de signification. Dans ma tête, le LAN était évident : la box ; l’imprimante ; le NAS ; les autres ordinateurs du Wi-Fi.

Mais un logiciel VPN ne raisonne pas nécessairement avec cette intuition humaine. Il voit des interfaces, des sous-réseaux privés et des chemins réseau.

Dans la configuration que je testais, l’interface virtuelle utilisée par WSL se retrouvait elle aussi du côté du trafic local à restreindre.

L’image qui m’a finalement aidé était simple. Je pensais avoir fermé la porte donnant sur la rue pour empêcher les voisins d’entrer. J’avais aussi fermé la porte intérieure qui menait de WSL vers Windows. Le VPN continuait donc à protéger la connexion Windows.

Il avait simplement mis mon propre Linux en quarantaine avec le reste du LAN.

Microsoft a déjà dû réparer cette frontière entre VPN et WSL

Ce qui m’a empêché d’accuser une bizarrerie propre à mon PC, c’est l’historique récent de Windows.

Après la mise à jour KB5067036 du 28 octobre 2025, Microsoft a documenté un problème avec WSL en mode mirrored et certains VPN tiers : Windows pouvait continuer à atteindre une destination alors que WSL renvoyait « No route to host ».

Microsoft reliait le problème au comportement de certaines interfaces VPN virtuelles dans ce chemin réseau. Cisco Secure Client et OpenVPN figuraient parmi les solutions concernées. Le correctif est arrivé le 13 janvier 2026 avec KB5074109.

Ce n’était pas exactement la panne que j’avais devant moi.

Mais cela confirmait le point qui m’intéressait : un VPN peut parfaitement fonctionner dans Windows pendant que la jonction VPN–Hyper-V–WSL casse.

Une discussion publique sur r/bashonubuntuonwindows montrait la même difficulté côté utilisateur : Windows restait connecté tandis que WSL perdait son réseau, et les échanges ont fini par toucher aux interfaces VPN, à vEthernet (WSL) et à leurs métriques.

Je reconnaissais déjà le chemin dans lequel j’étais en train de m’engager. Modifier une métrique. Retester. Changer le mode réseau. Retester. Créer une exception. Retester. Je pouvais probablement finir par trouver une combinaison stable.

Mais je voulais lancer apt, pas administrer un petit laboratoire Hyper-V chaque fois que j’activais mon VPN.

J’ai désactivé le blocage du LAN

Pour vérifier mon hypothèse, j’ai fait le changement le plus simple possible. J’ai désactivé l’option qui bloquait l’accès au réseau local. VPN toujours connecté. Retour dans Ubuntu.

sudo apt update

Les dépôts répondent.

git fetch

Terminé. Docker télécharge son image. Voilà. Je venais de trouver le bouton responsable. Pendant quelques minutes, cela m’a suffi. Puis je me suis souvenu de la raison pour laquelle j’avais activé cette protection.

Sur un Wi-Fi d’hôtel, de gare ou de coworking, je préfère que mon ordinateur ne discute pas librement avec tous les équipements présents sur le même réseau.

Je pouvais donc garder le réglage strict et perdre WSL. Ou le désactiver chaque fois que je voulais travailler sous Linux. Il existait évidemment des solutions plus fines.

Je pouvais examiner le pare-feu Hyper-V, ajuster les routes ou passer WSL en mode mirrored. Microsoft recommande justement ce dernier pour plusieurs scénarios de compatibilité VPN, même si certains clients VPN ou certaines politiques d’entreprise restent capables de perturber le réseau WSL.

Mais ce n’était plus la question que je voulais résoudre.

Je ne cherchais pas la configuration WSL la plus sophistiquée.

Je cherchais un VPN qui n’oblige pas mon environnement de développement à devenir une exception réseau permanente.

J’ai changé le VPN au lieu de continuer à modifier WSL

C’est à ce moment-là que j’ai essayé OnlydogVPN sur la même machine.

Je n’ai pas touché à Ubuntu. Je n’ai pas réécrit /etc/resolv.conf. Je n’ai pas désactivé le pare-feu Hyper-V. Je n’ai pas créé une règle autorisant globalement vEthernet (WSL).

J’ai fermé l’ancien client, ouvert le nouveau et utilisé le mode qui sélectionne automatiquement une connexion adaptée à l’usage.

Windows s’est connecté.

J’ai gardé le terminal à côté du navigateur.

sudo apt update

Les paquets sont apparus.

git fetch

Terminé. Puis Docker. Téléchargement terminé lui aussi.

Pendant les tests réalisés pour cet article, le tunnel pouvait donc rester actif sous Windows sans faire disparaître la sortie Internet de WSL2.

C’est seulement après ce résultat que son approche m’a intéressé.

Le service utilise un transport basé sur HTTP/3 et demande beaucoup moins de décisions réseau avant de se connecter.

Pour moi, le bénéfice n’était pas une mystérieuse fonction « WSL compatible ».

C’était plus simple que ça.

Je n’avais pas à décider si l’interface Hyper-V devait être classée comme LAN autorisé, LAN interdit ou exception spéciale.

Windows utilisait le VPN. WSL continuait à travailler. Je pouvais revenir à mon code.

Le mode mirrored est utile, mais je ne voulais plus qu’il soit mon premier réflexe

J’ai tout de même testé l’option recommandée par Microsoft.

Dans .wslconfig :

networkingMode=mirrored

Avec cette architecture et dnsTunneling, WSL suit de plus près la configuration réseau de l’hôte, ce qui améliore plusieurs scénarios de compatibilité VPN.

Je garderais volontiers ce réglage lorsqu’il convient à la machine. Mais l’expérience avait changé l’ordre de mon diagnostic. Avant, dès que WSL perdait Internet, je commençais à démonter WSL : DNS. NAT. Routes. Mode mirrored. Arrêt complet. Redémarrage.

Maintenant, si Windows reste parfaitement connecté et que WSL tombe exactement au moment où le VPN s’active, je regarde d’abord ce que le client VPN fait aux interfaces virtuelles.

Microsoft confirme d’ailleurs que les règles Windows Defender et Hyper-V peuvent s’appliquer au trafic WSL, et que certaines politiques d’entreprise peuvent bloquer ce trafic.

L’erreur apparaît dans Linux. Cela ne signifie pas que Linux l’a créée. Cette distinction m’aurait épargné pas mal de fichiers de configuration modifiés pour rien.

J’ai moins de régions, mais plus besoin de surveiller cette frontière

Le petit service propose moins de régions qu’un fournisseur mondial installé depuis longtemps.

Si j’avais besoin d’une sortie VPN dans une ville très précise, cette différence compterait.

Mais sur cette machine de développement, la liste des pays n’était pas ce qui déterminait si ma journée avançait.

Je pouvais avoir cent destinations disponibles.

Si apt, Git et Docker perdaient Internet dès que j’activais le tunnel, elles ne m’aidaient pas beaucoup.

Ce dont j’avais besoin était plus discret : Windows devait conserver son VPN ; WSL devait conserver son réseau ; et je ne voulais pas maintenir une exception Hyper-V entre les deux.

Au départ, je pensais qu’un réglage « bloquer le LAN » plus strict rendait forcément ma configuration meilleure.

WSL2 m’a obligé à préciser ce que ce mot voulait réellement dire.

Une imprimante inconnue sur le Wi-Fi et vEthernet (WSL) peuvent tous deux ressembler à des réseaux locaux dans la pile Windows.

Pour moi, ils n’ont pourtant rien à voir.

Depuis, mon critère sur cette machine est devenu très concret : je préfère un VPN qui laisse WSL2 continuer à télécharger, compiler et travailler sans règle spéciale plutôt qu’une protection du LAN si agressive qu’elle finit par enfermer mon propre Linux derrière la porte.