Always On VPN / RRAS : corriger l’ordre des DNS et rétablir la résolution interne (Windows Server)

Après la refonte d’un serveur RRAS/NPS, vos clients Always On VPN reçoivent les DNS dans le mauvais ordre ? Voici une méthode éprouvée pour rétablir une résolution interne fiable, avec procédures pas‑à‑pas, scripts d’audit et bonnes pratiques Windows Server/AD DNS.

Sommaire

DNS mal ordonnés sur les clients VPN (Always On VPN / RRAS)

Vue d’ensemble de la question

Après la refonte d’un serveur VPN Windows Server 2019 (RRAS + NPS) avec un contrôleur de domaine 2012, les postes connectés en VPN reçoivent deux serveurs DNS dans le mauvais ordre (ex. 192.168.1.1 avant 192.168.1.200). Conséquence directe : l’ordinateur tente de résoudre les noms internes via un DNS « Internet » (routeur/ISP), échoue, puis dégrade l’expérience (latences, échecs de jonction au domaine, GPO non appliquées). La configuration manuelle des DNS sur l’adaptateur VPN corrige le symptôme, mais l’objectif est que l’assignation automatique fournisse d’emblée l’ordre correct. Le vidage du cache (ipconfig /flushdns) n’y change rien.

Diagnostic rapide et signes typiques

Résolution interne aléatoire : ping dc.votre-domaine.local ou nslookup renvoient « Non-existent domain » ou la requête bascule vers un résolveur public.
GPO et scripts de logon appliqués de manière intermittente, erreurs GroupPolicy dans l’Observateur d’événements.
Connexion aux partages UNC lente ou impossible (\\serveur\partage).
ipconfig /all sur le poste : l’adaptateur VPN liste d’abord un DNS non‑AD (ex. 192.168.1.1), puis le DNS AD (ex. 192.168.1.200).

Symptôme	Interprétation probable	Commande de vérification
Échec résolution *.local	Ordre DNS priorisant un résolveur non‑AD	`nslookup nomdomaine.local`
GPO non appliquées	SRV/LDAP non résolus via DNS AD	`gpresult /r` et journal GroupPolicy
Partages UNC inaccessibles	SPN de serveur non résolu	`nltest /dsgetdc:VOTRE-DOMAINE`
Résolution lente	Time‑out sur DNS Internet puis fallback	`Resolve-DnsName -Server <DNS> nom`

Réponse & Solution

Solution efficace mise en œuvre

Basculer l’attribution IPv4 de RRAS de « Dynamique (DHCP) » à « Plage statique ».
Créer une exclusion DHCP couvrant précisément cette plage pour éviter tout chevauchement d’adresses.

Effet : les clients VPN reçoivent des paramètres cohérents, avec l’ordre de DNS correct, et la résolution interne fonctionne immédiatement.

Pourquoi ça marche

En mode DHCP, RRAS relaye les options IP (dont l’option 006 DNS et 015 suffixe), et selon l’équipement en amont (routeur, firewall, relais), l’ordre des DNS peut être inversé ou pollué par un DNS « Internet ».
En plage statique, RRAS contrôle l’assignation : l’adaptateur VPN hérite d’options alignées sur la configuration réseau du serveur RRAS lui‑même, où le DNS AD doit être premier. Cette cohérence empêche l’inversion et stabilise la résolution.

Procédure synthétique

RRAS : Gestionnaire du serveur → Outils → Routage et accès distant → clic droit sur le serveur → Propriétés → onglet IPv4 → Plage d’adresses statiques → Ajouter (ex. 192.168.1.240–192.168.1.254) → OK → redémarrer le service RRAS.

DHCP : sur la portée concernée → Plages d’exclusion → ajouter exactement la même plage que dans RRAS.

Vérifications après changement

Reconnectez un client VPN.
Exécutez : ipconfig /all et vérifiez que l’adaptateur VPN affiche le DNS AD en premier et le suffixe attendu.
Testez : nslookup dc.votre-domaine.local, nltest /dsgetdc:votre-domaine.local, puis l’accès aux ressources.

# Exemple attendu (extrait ipconfig /all)
Carte PPP VPN :
   Suffixe DNS propre à la connexion. . . . : votre-domaine.local
   Serveurs DNS. . . . . . . . . . . . . . : 192.168.1.200
                                             192.168.1.201

Détails approfondis : comment RRAS et Windows choisissent les DNS

Deux facteurs déterminent l’ordre final observé côté client : le mode d’attribution de RRAS (DHCP vs plage statique) et l’algorithme de résolution côté Windows (métriques d’interface, suffixes, éventuelles règles NRPT et politiques de client DNS).

Mode RRAS	Avantages	Inconvénients fréquents	Usage recommandé
DHCP (relay)	Intégration simple à une portée existante	Ordre 006 imprévisible, pollution par DNS « Internet », dépendances au relais	À éviter si votre DHCP n’est pas strictement maîtrisé
Plage statique	Contrôle total des paramètres et cohérence avec le serveur RRAS	Nécessite une exclusion DHCP pour éviter les conflits IP	Recommandé pour les environnements AD

Sur le poste, Windows sélectionne l’ordre de requête des serveurs DNS par interface selon :

La présence de règles NRPT (Always On VPN) qui forcent un serveur pour un suffixe donné.
Les métriques d’interface (priorité routage) : l’interface la mieux notée est interrogée d’abord.
La liste reçue via DHCP/PPP : si l’ordre fourni n’est pas correct, les requêtes partent vers le mauvais serveur.

Alternative si vous devez rester en DHCP

Si une plage statique RRAS n’est pas envisageable, sécurisez votre portée DHCP :

Sur la portée DHCP associée au pool VPN, vérifiez l’option 006 (Serveurs DNS) : ne listez que vos DNS AD et placez‑les dans l’ordre souhaité (ex. 192.168.1.200, puis 192.168.1.201).
Vérifiez l’option 015 (Suffixe DNS) : votre-domaine.local.
Assurez‑vous qu’aucune option au niveau « serveur » (et non « portée ») ne vient supplanter la configuration de la portée.
Sur l’équipement relais (routeur/firewall), désactivez la réécriture de 006 ou tout ajout automatique d’un DNS public.

Vous pouvez aussi renforcer le comportement côté client en ajustant la priorité de l’interface VPN :

# Exécuter en administrateur sur un poste de test
Get-NetIPInterface -AddressFamily IPv4 |
  Sort-Object InterfaceMetric |
  Format-Table ifIndex,InterfaceAlias,InterfaceMetric

# Mettre une métrique basse (prioritaire) pour l'interface VPN

Set-NetIPInterface -InterfaceAlias "Mon VPN" -InterfaceMetric 5

Enfin, pour les environnements où la Résolution de noms multi‑hébergés intelligente doit être neutralisée, appliquez la stratégie :

Configuration ordinateur &gt; Modèles d'administration &gt; Réseau &gt; Client DNS &gt;
"Désactiver la résolution de noms multi-hébergés intelligente" = Activé

Always On VPN : forcer la résolution interne par suffixe (NRPT)

Always On VPN permet de contraindre la résolution pour un ou plusieurs suffixes via la Name Resolution Policy Table (NRPT). Même si l’ordre des DNS reçu est discutable, la NRPT garantit que toutes les requêtes destinées à *.votre-domaine.local partent vers les DNS internes.

Extrait ProfileXML (DomainNameInformationList)

&lt;VPNProfile&gt;
  &lt;DnsSuffix&gt;votre-domaine.local&lt;/DnsSuffix&gt;
  &lt;DomainNameInformationList&gt;
    &lt;DomainNameInformation&gt;
      &lt;DomainName&gt;votre-domaine.local&lt;/DomainName&gt;
      &lt;DnsServers&gt;192.168.1.200,192.168.1.201&lt;/DnsServers&gt;
      &lt;Proxy&gt;&lt;/Proxy&gt;
      &lt;AutoConfiguration&gt;false&lt;/AutoConfiguration&gt;
    &lt;/DomainNameInformation&gt;
  &lt;/DomainNameInformationList&gt;
&lt;/VPNProfile&gt;

Pour un test rapide (poste pilote), vous pouvez aussi injecter une règle NRPT locale :

# Redirige *.votre-domaine.local vers les DNS internes
Add-DnsClientNrptRule -Namespace "votre-domaine.local" `
  -NameServers "192.168.1.200,192.168.1.201"

# Vérifier les règles NRPT

Get-DnsClientNrptPolicy </code></pre>

<p>Dans un déploiement géré (Intune/GPO), le <em>ProfileXML</em> est fourni par la stratégie VPNv2. L’important est de <strong>définir explicitement</strong> les serveurs DNS pour les suffixes internes du domaine.</p>

<hr />

<h3>Contrôles &amp; bonnes pratiques complémentaires</h3>
<ul>
  <li><strong>Carte LAN du serveur RRAS</strong> : configurez <em>uniquement</em> les <strong>DNS AD</strong> (ex. <code>192.168.1.200</code>, <code>192.168.1.201</code>). <em>Ne pointez jamais</em> vers un DNS de routeur/ISP sur un hôte joint au domaine.</li>
  <li><strong>DNS AD</strong> : utilisez des <strong>redirecteurs</strong> (forwarders) vers Internet, plutôt que d’exposer des clients à des DNS externes.</li>
  <li><strong>Suffixes DNS</strong> : si nécessaire, définissez la <em>liste de recherche des suffixes</em> via GPO :
    <pre><code>Configuration ordinateur &gt; Modèles d'administration &gt; Réseau &gt; Client DNS &gt;
"Liste de recherche de suffixes DNS" = votre-domaine.local, sous-domaine.local

IPv6 : si votre AD/DNS n’est pas prêt en IPv6, évitez d’annoncer des DNS IPv6 aux clients VPN, ou fournissez des enregistrements AAAA valides.
Surveillance : suivez les journaux Microsoft‑Windows‑RasClient/Operational et DNS Client Events pour corréler la connexion VPN et les requêtes DNS.

Procédure détaillée étape par étape

A. Basculer RRAS en plage statique

Sur le serveur RRAS, ouvrez Routage et accès distant.
Clic droit sur le nom du serveur → Propriétés → onglet IPv4.
Sélectionnez Plage d’adresses statiques puis Ajouter.
Renseignez une plage dédiée (ex. 192.168.1.240–192.168.1.254) sur le même sous‑réseau que vos ressources internes si vous utilisez une affectation simple (selon design).
Validez, puis redémarrez le service RRAS.

B. Créer l’exclusion sur le DHCP

Ouvrez la console DHCP → votre Portée.
Plages d’exclusion → Ajouter la plage exactement identique à celle de RRAS.
Vérifiez que l’option 006 ne contient que vos DNS AD et que l’ordre est correct.
Vérifiez l’option 015 et la durée de bail (un bail trop long retarde la prise en compte).

C. Sanity check sur le serveur RRAS

Sur l’interface LAN du serveur RRAS : DNS AD en premier, pas de DNS Internet.
Vérifiez l’inscription DNS du serveur (ipconfig /registerdns), et que les zones AD répliquent correctement.

D. Validation côté poste

# 1) Affichage complet des paramètres IP/DNS
ipconfig /all

# 2) Résolution interne explicite

nslookup serveur.votre-domaine.local 192.168.1.200

# 3) Découverte DC

nltest /dsgetdc\:votre-domaine.local

# 4) Test SMB

dir \serveur\partage

Scripts PowerShell d’audit et de correction

Audit des adaptateurs VPN et de l’ordre DNS

# Lister les interfaces PPP/Tunnel et leurs DNS
Get-DnsClientServerAddress -AddressFamily IPv4 |
  Where-Object { $_.InterfaceAlias -match 'VPN|WAN Miniport|IKEv2|SSTP|L2TP' } |
  Select-Object InterfaceAlias, ServerAddresses |
  Format-Table -Auto

Forcer l’ordre DNS sur un adaptateur nommé « Mon VPN »

# Remplace la liste des serveurs DNS par l'ordre souhaité
Set-DnsClientServerAddress -InterfaceAlias "Mon VPN" `
  -ServerAddresses 192.168.1.200,192.168.1.201

Remarque : ceci corrige un poste ponctuellement. La vraie solution pérenne reste le basculage RRAS en plage statique (ou la mise au clair des options DHCP/relai).

FAQ – pièges courants

Pourquoi mon routeur (192.168.1.1) remonte en premier ?
Parce que le relai DHCP insère par défaut le DNS du routeur ou réécrit l’option 006. En mode plage statique, RRAS n’a plus besoin du relai et n’hérite plus de ce comportement.

Dois‑je configurer le DNS de l’ISP sur des machines jointes au domaine ?
Non. Les clients AD doivent pointer exclusivement vers les DNS AD. Pour Internet, ce sont vos serveurs DNS AD qui feront forwarder vers l’extérieur.

Et si j’ai plusieurs domaines/sous‑domaines ?
Ajoutez des entrées supplémentaires dans la DomainNameInformationList (NRPT) et, si nécessaire, allongez la liste de recherche des suffixes via GPO, en conservant les DNS internes en première position.

IPv6 est‑il un problème ?
Pas si vos serveurs et zones sont prêts. Sinon, évitez d’annoncer des DNS IPv6 aux clients VPN ou désactivez provisoirement l’assignation IPv6 côté RRAS.

Checklist post‑migration (à conserver)

RRAS en plage statique, exclusion DHCP créée.
Interface LAN de RRAS : DNS AD en premier, aucun DNS Internet.
DHCP : options 006/015 correctes, sans contamination par des options « serveur ».
Always On VPN : NRPT (DomainNameInformationList) renseignée pour les suffixes internes.
Clients : métrique de l’interface VPN raisonnable et GPO « multi‑hébergés intelligente » désactivant le comportement indésirable si besoin.
Tests : ipconfig /all, nslookup, nltest, accès aux partages et GPO OK.

En bref

La combinaison plage statique RRAS + exclusion DHCP est la méthode la plus simple et la plus fiable pour éviter l’inversion des DNS sur des clients VPN et garantir une résolution interne stable. Complétez avec des règles NRPT (Always On VPN) pour forcer la résolution par suffixe, et vérifiez vos bonnes pratiques AD/DNS : DNS internes partout, forwarders côté serveurs, suffixes et métriques cohérents. Vous éliminerez les latences, sécuriserez l’application des GPO et retrouverez un comportement prévisible des clients à chaque connexion.

Annexes utiles

Commandes de support

# Vider les caches DNS et NetBIOS (si WINS encore utilisé)
ipconfig /flushdns
nbtstat -R

# Forcer l'inscription DNS

ipconfig /registerdns

# Journaux pertinents

# Observateur d'événements > Journaux des applications et services >

# Microsoft > Windows > RasClient > Operational

# Microsoft > Windows > DNS Client Events > Operational

Modèle de communication pour le changement

Périmètre : bascule RRAS en plage statique + exclusion DHCP.
Impact : connexions VPN existantes coupées lors du redémarrage RRAS (prévoir un créneau).
Validation : tests ipconfig et nslookup sur échantillon de postes.
Retour arrière : rebasculer temporairement en DHCP si nécessaire (peu probable).

Modèle d’incident (exemple)

Titre : Résolution DNS interne intermittente en VPN
Symptômes : GPO incomplètes, délai à l’ouverture de session, échecs UNC
Cause racine : Option DHCP 006/relai modifiant l'ordre DNS
Action corrective : RRAS en plage statique + exclusion DHCP + NRPT
Résultat : Résolution interne stable, GPO appliquées, latence réduite

Conclusion

Corriger l’ordre des DNS côté clients VPN n’est pas qu’une question de confort : c’est une exigence de fiabilité Active Directory. En reprenant la main sur l’assignation IP via RRAS en plage statique, en assainissant DHCP et en forçant la résolution par suffixe (NRPT), vous supprimez les causes structurelles d’inversion, vous simplifiez l’exploitation et vous évitez des incidents récurrents difficilement traçables.

Always On VPN / RRAS : corriger l’ordre des DNS et rétablir la résolution interne (Windows Server)