Always On VPN su Windows Server 2019: risoluzione DNS errata in RRAS e ordine dei DNS – guida completa

Se i client Always On VPN ricevono come DNS primario il router e solo dopo il DNS di dominio, i nomi interni smettono di risolversi. In questa guida spiego perché accade su RRAS in Windows Server 2019 e come correggerlo definitivamente con un pool statico e un’esclusione DHCP.

Indice

Panoramica del problema

Dopo la ricostruzione del server VPN (RRAS su Windows Server 2019 con un controller di dominio Windows Server 2012), i client Always On VPN hanno iniziato a ricevere i server DNS nell’ordine sbagliato: 192.168.1.1 (router) come primario e 192.168.1.200 (DNS di dominio) come secondario. Il risultato: i nomi interni non si risolvono, mentre tutto funziona indicando gli IP direttamente. Le macchine connesse alla LAN non presentavano il problema: solo i client collegati via VPN venivano affetti dall’ordine errato dei DNS.

Sintomi osservabili

Risoluzione nomi interni fallisce: ad esempio filesrv.contoso.local non viene risolto o risolve su IP pubblici non pertinenti.
Connessioni per IP funzionano: ping, SMB/RDP/HTTP verso indirizzi interni funzionano se si usa direttamente l’IP.
Solo client VPN impattati: host LAN ottengono i DNS nell’ordine corretto e risolvono senza errori.
DNS client cache irrilevante: un ipconfig /flushdns non cambia il comportamento.
Forzare i DNS a mano funziona: impostando manualmente il DNS sull’adattatore VPN la risoluzione interna torna operativa, ma la soluzione non è scalabile né conforme alle best practice di AOVPN.

Topologia di riferimento

Elemento	Indirizzo	Note
Rete LAN	192.168.1.0/24	Rete interna principale
Router/Default Gateway	192.168.1.1	Non autorevole per la zona DNS interna
DNS di dominio	192.168.1.200	Autorevole per `contoso.local`
RRAS	Windows Server 2019	Always On VPN (IKEv2/SSTP)
Pool VPN statico suggerito	192.168.1.240–192.168.1.254	Range riservato ai client VPN

Diagnosi rapida

Con un client collegato in VPN:

ipconfig /all
nslookup filesrv.contoso.local
nslookup -q=SOA contoso.local
Get-DnsClientServerAddress -InterfaceAlias "VPN" | Format-Table -Auto
Resolve-DnsName filesrv.contoso.local

Se il primo server nella lista è 192.168.1.1 e non 192.168.1.200, il client interroga il router per primo, fallendo la risoluzione interna.

Causa tecnica

In RRAS esistono due modi per assegnare gli indirizzi IPv4 ai client:

Pool dinamico: RRAS chiede lease e opzioni (inclusa la Option 006 – DNS Servers) a un server DHCP e le inoltra ai client. In questo schema l’ordine dei DNS riflette quello definito nel DHCP o quello restituito al server RRAS.
Pool statico: RRAS assegna direttamente gli IP da un intervallo definito e propaga ai client i DNS indicati nelle proprietà IPv4 di RRAS, rispettandone l’ordine.

Nello scenario descritto, con pool dinamico, la catena RRAS⇄DHCP restituiva ai client VPN un ordine non desiderato (router al primo posto). Il passaggio a pool statico ha riportato il controllo in RRAS, ripristinando l’ordine corretto dei DNS.

Verifiche preliminari effettuate

Confermata la configurazione dell’adattatore VPN su IP e DNS automatici.
Eseguito ipconfig /flushdns su client: nessun miglioramento.
Impostati manualmente i DNS sull’adattatore VPN: problema aggirato, ma non sostenibile per Always On.

Soluzione consigliata

Impostare un pool IPv4 statico su RRAS e riservare lo stesso intervallo a livello DHCP tramite un’esclusione nello scope, in modo da evitare sovrapposizioni con i lease per i client LAN. Dopo la modifica, i client VPN ricevono i DNS nell’ordine impostato in RRAS e la risoluzione dei nomi interni torna stabile.

Procedura dettagliata in RRAS

Apri Routing e Accesso Remoto sul server RRAS.
Fai clic destro sul nome del server → Proprietà.
Vai alla scheda IPv4 e seleziona Pool di indirizzi statico.
Premi Aggiungi e specifica un intervallo non in uso dal DHCP (es. 192.168.1.240–192.168.1.254).
Nella stessa scheda, imposta i server DNS interni nell’ordine desiderato:
- DNS preferito: 192.168.1.200 (autorità per la zona interna)
- DNS alternativo: 192.168.1.1 (solo come fallback, opzionale)
Conferma e riavvia il servizio Routing e Accesso Remoto.

Configurazione in DHCP

Apri la console DHCP del tuo server.
Nello Scope LAN, crea un’esclusione per l’intervallo usato dal pool statico di RRAS (es. 192.168.1.240–192.168.1.254), in modo che non venga assegnato ai client LAN.
Verifica che l’Option 006 nello scope principale riporti l’ordine corretto (prima il DNS di dominio, poi eventuali altri).

Nota: per questa soluzione non servono prenotazioni (reservation) per i client VPN. Serve solo l’esclusione del range nel DHCP.

Perché la soluzione funziona

Controllo dell’ordine DNS in RRAS: con un pool statico, RRAS distribuisce direttamente ai client le opzioni DNS impostate nelle sue proprietà, rispettando l’ordine definito dall’amministratore.
Eliminazione dell’ambiguità DHCP: col pool dinamico, RRAS dipende dal DHCP, che potrebbe restituire un ordine DNS non allineato alle esigenze della VPN. Il pool statico elimina questa dipendenza.
Coerenza tra client: tutti i client VPN ricevono la stessa lista DNS nello stesso ordine, indipendentemente da particolarità di scope o policy DHCP.

Validazione post-intervento

Disconnetti e riconnetti la VPN (Always On potrebbe farlo automaticamente al cambio di rete).
Pulisci la cache DNS lato server e client: dnscmd /clearcache ipconfig /flushdns
Controlla i server DNS effettivi sull’interfaccia VPN: Get-DnsClientServerAddress -InterfaceAlias "VPN" | Format-List
Verifica la risoluzione per nomi interni ed esterni: nslookup filesrv.contoso.local nslookup www.microsoft.com
Controlla le route e che il traffico DNS per la zona interna passi sul tunnel: Get-DnsClientNrptPolicy Get-NetIPInterface -InterfaceAlias "VPN" route print

Variante con pool dinamico

Se vuoi rimanere sul pool dinamico, devi assicurarti che il DHCP restituisca l’Option 006 nell’ordine corretto per tutte le richieste che RRAS effettua per conto dei client VPN. Ottieni questo in due modi:

Scope dedicato “VPN”: crea uno scope DHCP separato utilizzato da RRAS (stessa sottorete del server RRAS o quella da cui può ottenere lease), con Option 006 impostata al DNS di dominio come primario. Assicurati che RRAS ottenga gli indirizzi da quello scope.
Policy DHCP: se usi DHCP di Windows Server 2012 o superiore, definisci una policy nello scope per assegnare un ordine DNS specifico a una classe o a condizioni che identifichino le richieste generate da RRAS. In ambienti complessi non sempre è banale distinguere le richieste di RRAS da quelle dei client LAN; per questo la soluzione con pool statico resta più semplice e robusta.

Buone pratiche e raccomandazioni

Usa un pool statico in RRAS per Always On VPN. È la scelta di default per coerenza e prevedibilità.
Imposta i DNS interni nelle proprietà IPv4 di RRAS nell’ordine desiderato; verranno propagati ai client VPN senza mediazioni.
Se mantieni il pool dinamico, usa scope o policy DHCP dedicate ai client VPN con Option 006 corretta.
Verifica autoritatività del DNS di dominio (192.168.1.200) per la zona interna, e che il router non risponda per la stessa zona.
Pulisci le cache dopo ogni modifica: lato server con dnscmd /clearcache, lato client con ipconfig /flushdns, e ristabilisci la connessione VPN.
Configura la NRPT (Name Resolution Policy Table) nel profilo AOVPN per forzare i suffissi interni (es. contoso.local) verso il DNS di dominio anche in scenari di split tunneling.
Evita il router come DNS primario per i client aziendali e soprattutto per i client VPN: i resolver del router non conoscono i record interni e possono causare DNS leak.
Separa i range: non riutilizzare per la VPN lo stesso range del DHCP LAN; mantieni un margine (es. ultimi 15 IP della subnet) esclusivo per il pool statico RRAS.

Controlli aggiuntivi lato server

Event Viewer:
- Registri applicazioni e servizi → Microsoft → Windows → RemoteAccess per eventi RRAS.
- DNS Server per risposte e fallimenti nella zona interna.
Servizi: verifica che Remote Access, DNS e (se presente) DHCP Server siano in stato Running.
Ordine DNS sulla NIC del server RRAS: sulla scheda di rete interna il DNS deve puntare solo al DNS di dominio (niente router). Questo previene comportamenti indesiderati anche durante l’handshake delle connessioni.

Strategie di mitigazione lato client

Se non puoi intervenire subito sul server, applica una o più di queste mitigazioni temporanee:

Regola NRPT nel profilo AOVPN: per ogni suffisso interno, imposta il DNS server 192.168.1.200. Così, anche se l’ordine generale dei DNS è subottimale, le query per la zona interna useranno comunque il resolver corretto.
Script provvisorio in PowerShell per forzare i DNS sull’interfaccia VPN dopo la connessione: $vpn = Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "VPN"} if ($vpn) { Set-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex -ServerAddresses 192.168.1.200,192.168.1.1 } (Da rimuovere quando la correzione lato RRAS è in produzione.)

Errori comuni da evitare

Range sovrapposti fra DHCP LAN e pool statico RRAS: comportano conflitti di indirizzi e problemi intermittenti.
DNS del router in prima posizione nell’Option 006 o nelle proprietà RRAS: rompe la risoluzione di zone interne.
Assenza di esclusione DHCP: rischi che un host LAN ottenga un IP del pool VPN e viceversa.
Più DNS “smart” in cascata (resolver esterni/filtranti): possono deviare o bloccare query per zone private, causando latenze e time‑out.

Checklist finale

RRAS impostato su pool statico con intervallo dedicato.
Esclusione creata nello scope DHCP per lo stesso intervallo.
Proprietà IPv4 di RRAS: ordine DNS = 192.168.1.200 (primario), 192.168.1.1 (secondario/opzionale).
Cache DNS svuotate (dnscmd /clearcache sul DNS, ipconfig /flushdns sui client).
VPN rinegoziata; ipconfig /all conferma l’ordine DNS corretto sull’interfaccia VPN.
Risoluzione nomi interni/esterni verificata con nslookup e Resolve-DnsName.

Domande frequenti

Serve una prenotazione (reservation) DHCP per i client VPN?
No. Per il pool statico basta escludere il range dal DHCP LAN. Le prenotazioni non sono necessarie perché RRAS assegna direttamente gli indirizzi ai client.

Posso omettere del tutto il router come DNS alternativo?
Sì. In molti ambienti è consigliato indicare solo i DNS di dominio su RRAS, lasciando al DNS interno il forwarding verso Internet.

Con split tunnel è ancora necessario il pool statico?
È la scelta più semplice e prevedibile anche in split tunnel. In aggiunta, configura la NRPT nel profilo AOVPN per i suffissi interni.

Il problema si presenta solo con Windows Server 2019?
No. La dinamica RRAS⇄DHCP vale anche su altre versioni: la soluzione con pool statico è applicabile allo stesso modo.

Riepilogo operativo

Il malfunzionamento nasce dall’ordine errato dei DNS assegnati ai client AOVPN quando RRAS delega al DHCP l’assegnazione degli indirizzi. Spostando l’assegnazione su un pool statico in RRAS e impostando esplicitamente i DNS interni (con esclusione del range nello scope DHCP), l’ordine dei resolver torna sotto il tuo controllo e la risoluzione dei nomi interni ricomincia a funzionare in modo affidabile.

Raccomandazioni supplementari

Best practice: per Always On VPN usa sempre un pool statico su RRAS.
Nelle proprietà di RRAS → IPv4 indica i DNS interni nell’ordine desiderato; verranno propagati ai client VPN.
Se vuoi restare con il pool dinamico, definisci in DHCP uno scope o una policy dedicata per i client VPN con l’Option 006 impostata correttamente.
Verifica che il DNS di dominio (192.168.1.200) sia autorevole per la zona interna e che il router non risponda per la stessa zona.
Dopo ogni modifica, svuota la cache DNS sia lato server (dnscmd /clearcache) sia lato client e ristabilisci la connessione VPN per confermare il funzionamento.

Con questa impostazione, l’infrastruttura AOVPN torna stabile: i client interrogano subito il DNS di dominio, i record interni rispondono in tempi brevi e l’esperienza utente migliora senza interventi manuali sui singoli endpoint.