Pourquoi un VPN d’entreprise peut-il « casser » NextDNS ou AdGuard sur un routeur de voyage ? Parce que le DNS a changé de route

Le VPN de mon entreprise s’est connecté du premier coup. C’est précisément à ce moment-là que mon bloqueur DNS a cessé de fonctionner.

J’étais dans un hôtel, avec un petit routeur de voyage posé entre le Wi-Fi de la chambre et mes appareils. J’avais configuré le DNS dessus pour filtrer publicités et traqueurs. Sur mon téléphone personnel, tout fonctionnait. Sur l’ordinateur de travail aussi.

Puis j’ai lancé le VPN obligatoire de l’entreprise. Teams s’est connecté. Outlook a commencé à synchroniser. Le portail interne s’est ouvert.

Mais dans le tableau de bord du filtre DNS, mon ordinateur professionnel semblait avoir disparu. Les requêtes que je voyais quelques secondes auparavant n’arrivaient plus.

J’ai pensé que le routeur avait perdu sa configuration. J’ai redémarré AdGuard Home. Puis essayé NextDNS. Puis activé l’option qui forçait les clients à utiliser le DNS du routeur. Mauvaise idée.

Cette fois, certains sites ordinaires fonctionnaient encore, mais une ressource interne de l’entreprise ne se résolvait plus correctement.

J’avais réussi à transformer un détail agaçant en vrai problème de travail.

Mon routeur faisait exactement ce que je lui demandais — et le VPN aussi

Cette situation est devenue plus facile à rencontrer parce que les routeurs de voyage savent désormais faire énormément de choses.

GL.iNet a lancé son Beryl 7 en février 2026 avec Wi-Fi 7, fonctions VPN et routage avancé dans un boîtier de voyage de 205 [grammes](https://www.gl-inet.com/blogs/blog/glinet-launches-beryl-7-travel-router/) Son firmware permet aussi de combiner DNS chiffré, politiques VPN et AdGuard Home.

Sur le papier, mon installation paraissait donc parfaitement logique : Hôtel → routeur de voyage → AdGuard ou NextDNS → mes appareils. Et pour le portable professionnel, j’imaginais simplement une étape supplémentaire :

Hôtel → routeur → filtrage DNS → VPN d’entreprise → réseau de l’entreprise. Je pensais avoir empilé des protections. En réalité, j’avais surtout installé deux systèmes susceptibles de vouloir répondre à la même question : qui décide où envoyer une requête DNS ?

Et sur un ordinateur professionnel, le VPN de l’entreprise a souvent une excellente raison de vouloir garder cette décision.

Le routeur ne voyait plus les questions DNS du portable

C’est le point qui m’avait échappé. Sans le VPN professionnel, mon ordinateur demandait en substance au routeur : « Où se trouve ce domaine ? »

Le routeur envoyait cette demande vers mon résolveur filtrant. AdGuard ou NextDNS pouvait donc la voir, appliquer mes règles et bloquer ce que j’avais choisi de bloquer.

Puis j’activais le VPN d’entreprise.

À partir de là, le chemin pouvait changer complètement. Un client professionnel peut recevoir ses propres serveurs DNS et envoyer certaines requêtes — voire toutes — dans le tunnel de l’entreprise. Cisco Secure Client documente précisément ce fonctionnement avec le split DNS et les politiques permettant d’envoyer les recherches DNS dans le tunnel.

Le routeur de voyage était toujours là. AdGuard fonctionnait toujours. NextDNS fonctionnait toujours sur mes autres appareils.

Mais les questions DNS du portable professionnel étaient désormais comme des lettres placées dans une enveloppe fermée avant d’arriver au routeur.

Le filtre du routeur ne pouvait plus lire ce qu’il ne voyait plus.

C’est aussi ce qui rend le problème si trompeur. Dans une discussion publique sur r/GlInet, un utilisateur décrivait un ordinateur professionnel géré par son entreprise derrière un routeur de voyage WireGuard : l’adresse IP publique semblait correcte, mais le DNS continuait à suivre Cisco Umbrella.

C’est exactement le genre de situation qui pousse à accuser le routeur, WireGuard ou NextDNS alors que chaque élément peut, en réalité, faire correctement son travail.

Mon erreur suivante a été de vouloir reprendre le contrôle de force.

En forçant NextDNS, j’ai cassé ce dont le VPN professionnel avait besoin

J’avais activé le filtrage DNS pour une raison très simple : moins de publicités et moins de traqueurs. Le VPN professionnel avait une mission différente. Il devait notamment permettre à mon ordinateur de trouver des services internes qui n’existent pas nécessairement dans le DNS public.

Un nom interne peut être parfaitement compréhensible pour le résolveur de l’entreprise et totalement inconnu de NextDNS ou d’un autre résolveur public. Des utilisateurs professionnels de NextDNS ont d’ailleurs décrit ce problème : le filtrage fonctionne, puis certains hôtes privés accessibles par VPN deviennent introuvables parce que le DNS attendu par le tunnel n’est plus celui qui reçoit la requête.

À ce moment-là, le problème est devenu évident. Mon filtre disait : « Donne-moi les requêtes, je vais nettoyer le Web. » Le VPN professionnel disait : « Donne-les-moi, certaines destinations n’existent que chez moi. »

Et moi, au milieu, je cochais des cases pour obliger l’un à gagner sur l’autre. J’ai arrêté.

Le test le plus utile a consisté à ne plus rien forcer

J’ai remis l’ordinateur professionnel dans la configuration attendue par l’entreprise. VPN coupé. Le tableau de bord AdGuard voyait de nouveau ses requêtes.

VPN professionnel activé. Les requêtes du poste disparaissaient du tableau de bord, tandis que Teams, Outlook, le portail interne et les ressources de travail fonctionnaient. J’ai alors pris mon téléphone personnel, toujours connecté au même routeur.

Son filtrage continuait normalement. Voilà ma réponse.

Le routeur n’était pas cassé. AdGuard n’était pas cassé. Le VPN professionnel avait simplement repris le contrôle du DNS de l’appareil qu’il devait connecter au réseau de l’entreprise.

Et plus j’essayais de lutter contre cette politique depuis le routeur, plus je risquais de casser précisément les services dont j’avais besoin pour travailler.

Certaines configurations professionnelles sont d’ailleurs conçues pour empêcher ce contournement. Cisco documente un mode « Tunnel All DNS » capable d’intercepter le DNS et de bloquer les requêtes qui tentent de partir par un autre chemin.

À partir de là, la question n’était plus : « Comment obliger le portable professionnel à utiliser mon DNS ? » Elle devenait beaucoup plus utile : comment garder le filtrage sur mes appareils personnels sans toucher au chemin dont mon entreprise a besoin ?

J’ai arrêté de demander au routeur de protéger tout le monde de la même façon

C’est là que j’ai changé mon installation. Je n’ai pas supprimé AdGuard Home. Il restait parfaitement utile pour les appareils de la chambre qui dépendaient simplement du routeur. J’ai seulement arrêté d’en faire le point de passage obligatoire de mon ordinateur professionnel.

Sur mes appareils personnels, j’ai ouvert OnlydogVPN^↗ et utilisé la connexion avec le blocage des publicités et des traqueurs.

Le changement paraît petit, mais il supprimait le conflit à sa source : mon filtrage personnel n’avait plus besoin de gagner une bataille DNS contre le VPN de l’entreprise.

J’ai connecté mon téléphone. Ouvert les mêmes pages que plus tôt. Elles se chargeaient normalement, tandis que le compteur de requêtes bloquées commençait à monter.

Puis j’ai repris le portable professionnel. VPN de l’entreprise. Connexion.

Portail interne. Document client. Teams.

Tout fonctionnait. Pour la première fois de la matinée, je n’avais pas réussi à faire cohabiter les deux systèmes en trouvant le réglage parfait. J’avais fait quelque chose de beaucoup plus simple : je les avais séparés.

L’entreprise gardait son tunnel et son DNS sur son ordinateur. Mes appareils personnels gardaient leur connexion et leur filtrage.

Et le routeur revenait à son rôle le plus utile dans une chambre d’hôtel : fournir un réseau stable au lieu d’essayer d’imposer la même politique DNS à des appareils qui n’avaient pas les mêmes besoins.

C’est précisément là que le petit service m’a davantage servi qu’une configuration plus sophistiquée. Je n’avais rien à réécrire sur le routeur pour retrouver le filtrage de mon téléphone : je pouvais l’activer directement sur l’appareil qui m’appartenait et laisser le portable professionnel tranquille.

Il existe pourtant une deuxième panne qui lui ressemble beaucoup

Il me restait un dernier problème à comprendre.

Pendant mes premiers essais, j’avais aussi rencontré un cas où ce n’était plus seulement le portable professionnel qui perdait le DNS. Tous les appareils derrière le routeur avaient des difficultés dès que j’activais un VPN directement sur le routeur.

Même symptôme. Autre cause.

GL.iNet a publié en juin 2026 un guide consacré précisément au routage d’AdGuard Home lorsqu’un VPN est actif sur le routeur. Dans certaines configurations, les requêtes qu’AdGuard envoie vers son serveur DNS amont peuvent elles-mêmes être entraînées dans le tunnel VPN, ce qui demande d’ajuster leur routage.

J’ai fini par retenir une distinction beaucoup plus simple que tous les paramètres que j’avais essayés. Si seul le portable professionnel change de comportement lorsque son propre VPN démarre, je regarde d’abord le DNS imposé par l’entreprise.

Si tous les appareils du routeur perdent le DNS lorsque le VPN du routeur démarre, je regarde le chemin entre AdGuard et son résolveur amont.

Cette différence m’aurait évité plusieurs redémarrages — et surtout plusieurs modifications inutiles sur un ordinateur que je n’étais pas censé reconfigurer.

Je voulais un seul filtre pour tout le monde ; c’était précisément le mauvais objectif

Le petit service que j’ai utilisé possède moins de régions de sortie et moins d’historique public que les grands fournisseurs établis. Il ne remplace évidemment pas non plus le VPN professionnel : seul celui de l’entreprise me donne accès à ses ressources internes.

Mais dans cette chambre d’hôtel, ce n’était pas une faiblesse gênante. Je ne cherchais pas un deuxième outil capable de prendre le contrôle du portable professionnel. Je cherchais un moyen de ne plus faire dépendre la protection de mes appareils personnels d’une configuration DNS globale qui se battait avec lui.

Après ce changement, mon installation paraissait presque trop simple. Le routeur fournissait le réseau. L’ordinateur de travail utilisait le VPN et le DNS de l’entreprise.

Mes appareils personnels utilisaient leur propre connexion et leur propre filtrage. Trois rôles. Trois endroits. Plus personne ne se disputait le même DNS.

Je pensais qu’un bon routeur de voyage devait imposer NextDNS ou AdGuard à absolument tout ce qui s’y connectait. Ce matin-là, j’ai compris que le meilleur réglage pour mon portable professionnel était justement de ne plus essayer de le contrôler — et de garder mon filtrage personnel sur les appareils où cette décision m’appartenait vraiment.