Impossibile unire al dominio via VPN RRAS su Windows Server 2022: diagnosi DNS e routing

La VPN si connette ma il join al dominio fallisce con “An Active Directory Domain Controller (AD DC) for the domain xyz.com could not be contacted”? Questa guida pratica su RRAS in Windows Server 2022 spiega cause tipiche, verifiche DNS e routing e i comandi risolutivi passo‑passo.

Indice

Panoramica del problema

Scenario – Server RRAS su Windows Server 2022 con pool IP statico; client Windows 10 Pro 22H2 che si connette via VPN. La VPN si stabilisce e il traffico IP di base funziona.

Sintomo – Al tentativo di unire il PC al dominio (System > About > Domain or Workgroup), appare l’errore “An Active Directory Domain Controller (AD DC) for the domain xyz.com could not be contacted”. In genere ciò indica che il client non riesce a risolvere xyz.com o gli SRV ldap.tcp.dc._msdcs.xyz.com, oppure non raggiunge le porte di Active Directory attraverso il tunnel.

Perché compare l’errore

Il join di dominio non “scopre” i controller AD a caso: usa il DNS per risolvere il nome di dominio e gli SRV records (ldap.tcp, kerberos.tcp), quindi stabilisce sessioni su porte come 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB/Netlogon), 135 (RPC Endpoint Mapper) e 49152‑65535 (porte RPC dinamiche). Se il client punta a un DNS pubblico o non ha rotte verso la subnet del DC, le query falliscono e il wizard segnala l’impossibilità di contattare un AD DC.

Con RRAS il client riceve spesso un indirizzo PPP con maschera /32 (255.255.255.255): è normale e non impedisce il DNS; significa semplicemente “link punto‑punto”. In split‑tunnel, però, non viene impostato un gateway predefinito remoto: senza rotte esplicite verso la/le subnet AD, il traffico per il DC non uscirà dalla VPN.

Soluzioni e verifiche essenziali

Area	Azione consigliata	Note pratiche
DNS lato client	• Impostare sul PPP adapter l’IP del DNS interno (il DC) e il suffisso del dominio. • Eseguire `nslookup xyz.com` e `nslookup ldap.tcp.dc._msdcs.xyz.com` per confermare la risoluzione.	La maschera /32 (255.255.255.255) che RRAS assegna al PPP è normale e non blocca il DNS.
Routing	Se il DC risiede in una subnet diversa dal pool VPN, creare una rotta statica in RRAS o sul client: `netsh interface ipv4 add route <subnetDC> <mask> <gatewayRRAS>`	In topologie piatte (un’unica LAN dietro il server) rotte aggiuntive non servono.
Distribuzione parametri IP da RRAS	Assicurarsi che il pool statico (o il DHCP relay) consegni DNS server, suffix DNS e, se necessario, rotte classless.	Il flag “Enable IPv4 forwarding” e “Enable broadcast name resolution” è sufficiente; non esiste un’opzione RRAS chiamata “DNS forwarding”.
Firewall/porte AD	Consentire, lungo il tunnel VPN, porte 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB), 135 (RPC Endpoint Mapper) e porte RPC dinamiche 49152‑65535.	Anche il firewall del client deve lasciar passare il traffico quando riattivato.
Impostazioni della connessione VPN	• In IPv4 > Advanced, spuntare “Use default gateway on remote network” oppure mantenere lo split‑tunnel ma aggiungere rotte statiche verso la/e subnet AD. • Abilitare “Register this connection’s addresses in DNS”.	Senza gateway o rotte corrette il client trova il DC solo via IP, non via nome.
Credenziali & policy	Usare un account con diritto di join (Domain Admin o delegato). Verificare assenza di restrizioni (es. LimitLogin).	—
Log di diagnostica	Client: Event Viewer ► System e DNS Client Events. Server: Event Viewer ► Routing and Remote Access, DNS Server.	Errori tipici: 1014 (DNS timeout) su client; 20255 (Routing) su RRAS.

Procedura rapida: da “VPN connessa” a “join riuscito”

Connetti la VPN e apri un prompt elevato.
Verifica connettività IP: ping <IP_DC> Se il ping fallisce, risolvi prima routing e firewall del tunnel.
Controlla i DNS effettivi sul PPP: ipconfig /all Nell’adapter VPN verifica “DNS Servers” e “Connection‑specific DNS Suffix”.
Testa la risoluzione: nslookup xyz.com nslookup ldap.tcp.dc._msdcs.xyz.com L’ultima query deve restituire record SRV dei DC. Se ottieni “Non‑existent domain” o time‑out, il client non sta usando il DNS interno.
Verifica il DC locator: nltest /dsgetdc:xyz.com Deve restituire nome DC, sito e flags (DS LDAP KDC WRITABLE).
Se sei in split‑tunnel, aggiungi rotte (sostituisci i prefissi con le tue subnet AD, DFS, file server): PowerShell Add-VpnConnectionRoute -ConnectionName "VPN Aziendale" -DestinationPrefix "10.10.0.0/16" Add-VpnConnectionRoute -ConnectionName "VPN Aziendale" -DestinationPrefix "10.20.0.0/24" In alternativa, comando legacy persistente: route -p add 10.10.0.0 mask 255.255.0.0 <gatewayRRAS>
Controlla le porte critiche (utile con firewall restrittivi): PowerShell Test-NetConnection dc01.xyz.com -Port 53 Test-NetConnection dc01.xyz.com -Port 88 Test-NetConnection dc01.xyz.com -Port 389 Test-NetConnection dc01.xyz.com -Port 445 Test-NetConnection dc01.xyz.com -Port 135
Riprova il join dal pannello o via comando: PowerShell Add-Computer -DomainName "xyz.com" -Credential "XYZ\DomainJoinUser" -Verbose Restart-Computer

Configurazione consigliata lato RRAS (Windows Server 2022)

Indirizzamento: pool statico o DHCP relay

Pool statico: in IPv4 → General → Static address pool assegna una subnet dedicata (es. 10.70.100.0/24) che non si sovrapponga alla LAN.
DHCP relay: in ambienti complessi conviene affidare al DHCP la distribuzione di DNS, suffix e Classless Static Routes (opzione 121).

Rotte di ritorno verso il pool VPN

Oltre alle rotte “in andata” dal client, la rete interna deve conoscere la via di ritorno verso il pool VPN. Aggiungi sui router interni (o sul firewall perimetrale) una rotta statica <Pool_VPN> → <interfaccia interna di RRAS>. Senza questa rotta il DC vede pacchetti dal client ma risponde al default gateway, spezzando la sessione (asymmetric routing).

DNS e suffix

Assicurati che RRAS (o il DHCP) fornisca ai client:

DNS Server puntato ai DC interni (uno o più indirizzi).
Connection‑specific DNS Suffix (es. xyz.com), utile per risolvere nomi brevi e registrare dinamicamente l’host.

Firewall sul server RRAS

Consenti il traffico VPN e i flussi verso AD. Le porte minime già elencate (53/88/389/445/135 + 49152‑65535) devono attraversare il tunnel. Se l’apertura dell’intero range dinamico non è possibile, valuta (solo in casi estremi) la riduzione del range RPC su DC e membri; in ambienti standard è preferibile mantenerlo predefinito.

Configurazione consigliata lato client Windows 10/11

Impostare DNS e suffisso sul PPP

PowerShell
Sostituisci con il nome della tua VPN
$vpn = "VPN Aziendale"
Set-DnsClientServerAddress -InterfaceAlias $vpn -ServerAddresses 10.10.1.10,10.10.1.11
Set-DnsClient -InterfaceAlias $vpn -ConnectionSpecificSuffix "xyz.com" -RegisterThisConnectionsAddress $true

Full‑tunnel oppure split‑tunnel?

Full‑tunnel: abilita “Use default gateway on remote network” nelle proprietà IPv4 avanzate della connessione. Semplice, adatto a test o ambienti strettamente gestiti.
Split‑tunnel: mantieni disattivato il gateway remoto ma aggiungi rotte mirate alle subnet AD, file/print e management: PowerShell Add-VpnConnectionRoute -ConnectionName "VPN Aziendale" -DestinationPrefix "10.10.0.0/16" Add-VpnConnectionRoute -ConnectionName "VPN Aziendale" -DestinationPrefix "10.20.0.0/24"

Registrazione DNS dinamica

Con l’opzione “Register this connection’s addresses in DNS” il client aggiorna i record A/PTR nel DNS AD quando la VPN si attiva; utile per GPO e browse per nome. Verifica con:

ipconfig /registerdns
ipconfig /displaydns | findstr /i "xyz.com"

Test rapidi e interpretazione

ping <IP_DC> – Se fallisce, c’è un problema di connettività base (routing o firewall).
nslookup xyz.com – Deve rispondere il DNS interno (indirizzo del DC). Se la risposta è da un DNS pubblico, correggi subito i DNS del PPP.
nltest /dsgetdc:xyz.com – Se fallisce con DsGetDcName failed: 1355, i record SRV non sono raggiungibili o UDP/TCP 389/88/53 sono bloccati.

Diagnostica approfondita

Event Viewer

Client → System e Microsoft‑Windows‑DNS Client Events: cerca 1014 (DNS timeout), 8016 (DNS registration).
Server RRAS → Routing and Remote Access: eventi 20255/20271 per problemi di routing o IP assignment.
DNS Server: convalida aggiornamenti dinamici e risoluzione di _msdcs.xyz.com.

Strumenti di rete

PowerShell
Get-VpnConnection
Get-DnsClientServerAddress -InterfaceAlias "VPN Aziendale" | Format-List
Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like "VPN"} | Format-Table ifIndex,InterfaceAlias,AddressFamily,ConnectionState
Test-NetConnection dc01.xyz.com -CommonTCPPort LDAP
Resolve-DnsName -Type SRV ldap.tcp.dc._msdcs.xyz.com

MTU e frammentazione

Se i test TCP passano ma le operazioni AD “pendono”, potrebbero esserci problemi di MTU su L2TP/IPsec o IKEv2. Esegui un ping con DF:

ping dc01.xyz.com -f -l 1300

Se solo payload piccoli passano, riduci l’MTU sull’adapter VPN (solo per test) e verifica il percorso sul firewall perimetrale.

Casi frequenti e soluzioni

Il client risolve `xyz.com` sui DNS pubblici

Il join non potrà riuscire: i record SRV esistono solo sul DNS AD. Imposta i DNS interni sul PPP e ri‑esegui nslookup.

DC in subnet diversa dal pool VPN

Oltre alla rotta sul client (se split‑tunnel), aggiungi la rotta di ritorno sui router interni: <Pool_VPN> → RRAS. Senza ritorno, i SYN escono ma le risposte non tornano al client.

Firewall che blocca RPC dinamiche

Il join può apparire casualmente fallire. Apri il range 49152‑65535 o usa eccezioni applicative per NTDS, Netlogon, Server. In test, prova temporaneamente senza filtro stateful per confermare l’ipotesi (poi ripristina le regole sicure).

Browsing NetBIOS interrotto dalla /32

Per vecchie applicazioni/netbios name resolution, abilita NetBIOS over TCP/IP sull’adapter VPN o distribuisci un WINS. Non è necessario per il join, ma aiuta a “vedere” i nomi legacy.

Client usa tunnel utente ma serve join al primo logon

Per scenari “primo avvio” valuta un Device Tunnel (IKEv2) o un Offline Domain Join (djoin.exe) come alternativa temporanea. Esempio ODJ (amministratore):

djoin /provision /domain xyz.com /machine PCVPN01 /savefile C:\odjblob.txt
djoin /requestODJ /loadfile C:\odjblob.txt /windowspath C:\Windows /localos

Riavvia e verifica che il computer sia membro del dominio; poi applica GPO per la VPN definitiva.

Best practice operative

Se puoi, usa DNS esclusivamente interni quando la VPN è attiva; per la navigazione Internet affida lo split‑tunnel ma mantieni rotte verso AD/servizi interni.
Evita overlap di subnet: il pool VPN non deve intersecare nessuna rete interna; altrimenti il routing si comporterà in modo imprevedibile.
Automatizza le rotte: con criteri di distribuzione (DHCP opzione 121 o Add-VpnConnectionRoute via script) riduci gli errori umani.
Controlla il tempo: orologi client/DC devono essere allineati (Kerberos è sensibile allo skew).
Monitora i log: un giro regolare su DNS Client Events e RRAS anticipa guasti futuri.

Esempi pratici di configurazione (modellati)

Topologia piatta

RRAS e DC nella stessa LAN (es. 10.10.1.0/24), pool VPN 10.70.100.0/24. Azioni: imposta DNS del PPP su 10.10.1.10 (DC), suffix xyz.com. Nessuna rotta aggiuntiva in genere necessaria. Join immediato.

DC in VLAN dedicata

DC in 10.10.0.0/16, RRAS in 10.20.0.0/24, pool VPN 10.70.100.0/24.

Ritorno: sul core aggiungi 10.70.100.0/24 → 10.20.0.10 (IP interno RRAS).
Andata (split‑tunnel): sul client aggiungi 10.10.0.0/16 come rotta via VPN (Add‑VpnConnectionRoute).
DNS: PPP usa 10.10.1.10/11 (DC/DNS) e suffix xyz.com.

Split‑tunnel con DFS/Share distribuiti

Aggiungi rotte verso tutte le subnet dei file server (es. 10.30.0.0/24, 10.31.0.0/24). Valuta un elenco centralizzato di prefissi e applicalo via script PowerShell durante la connessione.

Checklist rapida (memorabile)

✅ VPN connessa e ping al DC per IP riuscito
✅ DNS del PPP puntano ai DC interni
✅ nslookup ldap.tcp.dc._msdcs.xyz.com restituisce record SRV
✅ Rotte attive verso le subnet AD (o full‑tunnel)
✅ Porte AD aperte lungo il tunnel
✅ nltest /dsgetdc:xyz.com OK
✅ Join eseguito con account autorizzato

Domande frequenti

La maschera /32 del PPP è “sospetta”? No, è tipica delle interfacce punto‑punto e non blocca la risoluzione DNS né le sessioni TCP.

Serve WINS per il join? No. Il join usa DNS e SRV; WINS/NetBIOS è utile solo per browsing legacy.

È obbligatorio abilitare “Use default gateway on remote network”? No. Comodo per test, ma in produzione lo split‑tunnel con rotte mirate è più efficiente.

Devo disattivare i firewall per il join? No: apri solo le porte necessarie. Se per diagnosi disattivi temporaneamente, ricordati di ripristinare le policy sicure.

Log ed errori tipici

Client – ID 1014 (DNS timeout): il PPP non usa i DNS interni o c’è filtraggio sulla 53/UDP/TCP.
RRAS – ID 20255/20271: problemi con IP assignment/route; verifica il pool e le interfacce.
DNS Server – errori di aggiornamento dinamico: spesso dovuti a permessi o mancanza del suffix.

Comandi pronti all’uso

Impostare DNS sul PPP

PowerShell
$vpn = "VPN Aziendale"
Set-DnsClientServerAddress -InterfaceAlias $vpn -ServerAddresses 10.10.1.10,10.10.1.11
Set-DnsClient -InterfaceAlias $vpn -ConnectionSpecificSuffix "xyz.com" -RegisterThisConnectionsAddress $true

Rotte split‑tunnel persistenti

PowerShell
Add-VpnConnectionRoute -ConnectionName "VPN Aziendale" -DestinationPrefix "10.10.0.0/16"
Add-VpnConnectionRoute -ConnectionName "VPN Aziendale" -DestinationPrefix "10.20.0.0/24"

Verifica DNS & DC locator

nslookup xyz.com
nslookup ldap.tcp.dc._msdcs.xyz.com
nltest /dsgetdc:xyz.com

Verifica porte AD

PowerShell
"53","88","135","389","445" | ForEach-Object { Test-NetConnection -ComputerName dc01.xyz.com -Port $_ }

Approfondimenti utili

La maschera /32 del PPP può ostacolare il browsing NetBIOS; se serve, abilita NetBIOS over TCP/IP o distribuisci un server WINS.
Se desideri che i client VPN ricevano indirizzi della stessa subnet LAN, usa il DHCP Server con opzione “Classless Static Routes” invece del pool statico RRAS.

In pratica, una volta garantita la corretta risoluzione DNS attraverso la VPN (puntamento al DNS interno, suffisso di ricerca e – se necessario – rotte statiche), il join al dominio riesce senza ulteriori modifiche.

Riepilogo operativo

Il messaggio “AD DC non contattabile” in presenza di una VPN RRAS funzionante è quasi sempre un problema di DNS o routing (talvolta di porte firewall). Punta il PPP ai DNS del dominio, aggiungi il suffisso, verifica gli SRV, apri le porte di AD e – in split‑tunnel – definisci rotte mirate alle subnet interne. Con questi passi, il join al dominio su Windows Server 2022 tramite RRAS torna ad essere un’operazione standard e affidabile.