Errore VPN Windows Server 2019 “The remote connection was not made because the name of the remote access server did not resolve”: diagnosi e soluzione

Messaggio di errore: “The remote connection was not made because the name of the remote access server did not resolve”. Questa guida pratica spiega come diagnosticare e risolvere rapidamente il problema su VPN basate su Windows Server con RRAS, partendo dal DNS fino ai certificati.

Indice

Panoramica del problema

Quando un client VPN restituisce il messaggio di errore “The remote connection was not made because the name of the remote access server did not resolve”, siamo davanti a un classico caso di risoluzione nomi fallita. In termini pratici, il nome FQDN impostato nel profilo VPN (per esempio vpn.dominio.com) non viene tradotto in un indirizzo IP raggiungibile dal client. Su Windows questo si manifesta tipicamente come errore 868 lato client. Nel caso descritto, il server funziona dalla rete locale ma non dall’esterno, e l’indirizzo IP pubblico e le regole firewall sono dichiarati invariati: un indizio forte che la radice sia nel DNS o nel port‑forwarding.

Sintomi e impatto

Connessioni VPN che falliscono subito, prima della fase di autenticazione.
Assenza di richiesta credenziali o certificati nel client.
Ping o tracert verso il FQDN che non risolvono o risolvono su un IP errato.
Accesso funzionante in LAN via nome corto o IP interno, ma non da Internet.
Altri servizi pubblicati sullo stesso IP pubblico funzionanti, isolando il problema alla voce DNS o al forwarding specifico della VPN.

Cause probabili a colpo d’occhio

Area	Verifiche consigliate	Perché è rilevante
DNS pubblico	– Controllare che i record A o CNAME del FQDN VPN puntino all’IP pubblico corretto. – Usare `nslookup` o un resolver pubblico per testare la risoluzione da Internet.	Se il record è scaduto, cancellato o propagato male, il client non risolve il nome.
DNS interno e cache	Dal server: `ipconfig /flushdns` e `ipconfig /registerdns`. Verificare che il controller di dominio gestisca correttamente zone e forwarder.	Cache o registrazioni corrotte possono impedire la pubblicazione o servire risposte vecchie.
NAT e port forwarding	Confermare sul firewall che porte e protocolli usati (PPTP, L2TP con NAT‑T, SSTP) siano inoltrati all’IP privato attuale del server.	Se il server è stato ricreato o ha cambiato IP, il forwarding potrebbe puntare a un host errato.
Firewall esterno o provider	Provare da una rete esterna diversa (hotspot). Chiedere al provider eventuali filtraggi su DNS o VPN.	Serve a escludere blocchi lato ISP, filtri carrier‑grade NAT o routing anomalo.
Log di sistema	In Visualizzatore eventi: registri System, Application, e ruolo Remote Access; verificare errori di DNS o RRAS.	Offre dettagli su time‑out di lookup e tentativi di handshake abortiti.
Integrità del ruolo RRAS	Riesaminare la configurazione: utenti autorizzati, protocolli abilitati, certificato per tunnel SSL, binding HTTP.	Configurazioni corrotte o certificati scaduti impediscono la negoziazione anche con DNS corretto.

Flusso di diagnosi rapido

Eseguire una risoluzione pubblica del FQDN della VPN e verificare che torni l’IP pubblico atteso.
Se la risoluzione è corretta, testare la porta del protocollo previsto verso il FQDN.
Se la porta risulta chiusa, controllare NAT e regole firewall di frontiera.
Se la porta risulta aperta ma la sessione fallisce, analizzare certificati e log RRAS.

Verifica approfondita del DNS pubblico

La priorità è assicurarci che vpn.dominio.com punti al giusto IP pubblico. Eseguire dal client o da un host esterno:

nslookup vpn.dominio.com 8.8.8.8
nslookup vpn.dominio.com 1.1.1.1

Se la risposta non corrisponde all’IP pubblicato sul firewall, aggiornare il record presso il provider DNS. Se si usa un CNAME, verificare la catena completa fino al record A di destinazione.

Con PowerShell è possibile ispezionare anche il tempo di vita della risposta:

Resolve-DnsName -Name "vpn.dominio.com" -Server 8.8.8.8 |
  Select-Object Name,Type,IPAddress,TTL

Consigli operativi:

Usare TTL moderati (per esempio 300–900 secondi) sui record VPN per facilitare cambi rapidi in emergenza.
Evitare conflitti di split‑horizon DNS: la zona interna non deve sovrascrivere il record pubblico con un IP privato quando i client sono fuori sede.
Verificare che non esista un record AAAA non desiderato: alcuni client possono tentare IPv6 prima di IPv4.

Cache locale e DNS interno

Se il server Windows funge anche da resolver interno o controller di dominio, assicurarsi che non serva risposte stale. Sul server:

ipconfig /flushdns
ipconfig /registerdns

Su client Windows:

ipconfig /flushdns
ipconfig /displaydns

Nel Visualizzatore eventi, esaminare Applications and Services Logs → Microsoft → Windows → DNS‑Server per errori di forwarding o di zona. Se si utilizzano forwarder, verificare che siano raggiungibili e corretti. In ambienti Active Directory, controllare che la zona pubblica non sia stata accidentalmente creata anche internamente con record diversi.

Port forwarding e traduzione degli indirizzi

Anche con un DNS perfetto, la VPN non risponderà se il traffico non raggiunge RRAS. Verificare le seguenti corrispondenze tra protocollo e porte:

SSTP: TCP 443 verso l’host RRAS.
L2TP con IPsec: UDP 500 e UDP 4500, più ESP; dietro NAT è obbligatorio NAT‑T su UDP 4500.
PPTP: TCP 1723 e protocollo GRE; protocolli legacy non raccomandati.

Con PowerShell dal client:

Test-NetConnection -ComputerName vpn.dominio.com -Port 443 -InformationLevel Detailed
Test-NetConnection -ComputerName vpn.dominio.com -CommonTCPPort HTTPS

Se il test mostra TcpTestSucceeded: False, ricontrollare sul firewall di frontiera:

Regola di pubblicazione dalla WAN verso l’IP privato attuale del server.
Eventuali oggetti DHCP o binding che possano essere cambiati dopo un rebuild del server.
NAT hairpin: comportamenti diversi tra interno ed esterno possono confondere i test; provare sempre da una rete realmente esterna.

Verifiche su firewall e provider

Testare da una seconda connessione, ad esempio hotspot, per escludere filtri di rete locali. In caso di blocchi sporadici, verificare con il provider la presenza di filtri su UDP 500/4500, GRE, o rate‑limit su TCP 443. Se viene utilizzato un dispositivo con sicurezza automatica, controllare funzioni di protezione come DoS protection o application awareness che potrebbero chiudere sessioni VPN legittime.

Analisi dei log e del ruolo remoto

Il ruolo Remote Access in Windows registra informazioni preziose. Controllare in Visualizzatore eventi:

Custom Views → Server Roles → Remote Access per errori e avvisi RRAS.
Applications and Services Logs → Microsoft → Windows → RemoteAccess per eventi operativi.
System e Application per errori di driver, certificati o HTTP.

Esempio di estrazione veloce con PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-RemoteAccess/Operational" -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Per uno stato sintetico del ruolo:

Import-Module RemoteAccess
Get-RemoteAccess
Get-RemoteAccessConnectionStatistics

Packet capture con analizzatore di rete

Quando DNS e port forwarding sembrano corretti, uno sniff di rete può chiarire gli ultimi dubbi. Avviare una cattura su interfaccia WAN del server o del firewall e filtrare:

dns per verificare richieste e risposte sul FQDN.
tcp.port == 443 per tunnel SSTP e handshake TLS.
udp.port == 500 or udp.port == 4500 per tunnel L2TP con IPsec e NAT‑T.

Se si vedono SYN in arrivo su 443 e risposte coerenti, ma il client cade comunque, indagare i certificati. Se non si vede alcun SYN, il problema è a monte (DNS errato o port forwarding mancante).

Verifica dei certificati per tunnel sicuri

Per tunnel basati su SSL è necessario un certificato server valido:

Il nome comune o un soggetto alternativo deve corrispondere al FQDN usato dai client.
Il certificato deve includere l’uso esteso Server Authentication.
La catena di fiducia deve essere completa e le liste di revoca raggiungibili dai client.
La scadenza deve essere futura e coerente sui sistemi.

Controlli utili sul server:

certlm.msc

In Computer locale → Personale → Certificati verificare la presenza del certificato usato da RRAS e che sia legato alla porta HTTP del listener. Per ispezionare i binding HTTP:

netsh http show sslcert

Se il certificato non è presente o non è selezionato in RRAS, aprire la console Routing and Remote Access, sezione Proprietà → Sicurezza, e selezionare il certificato corretto.

Integrità della configurazione del servizio

Talvolta il ruolo funziona in LAN perché la risoluzione interna punta all’IP privato, mentre all’esterno un record errato indirizza altrove. In altri casi, un ripristino del server può aver cambiato l’IP interno, lasciando il port‑forwarding puntato all’host precedente. Verifiche consigliate:

Controllare utenti autorizzati e criteri di accesso remoto.
Confermare i protocolli abilitati coerenti con i client in uso.
Verificare gli indirizzi degli endpoint e i pool IP assegnati ai client.
Se sono presenti criteri NPS, esaminare i log per eventuali rifiuti lato policy.

Controlli dal punto di vista del client

Assicurarsi che nel profilo VPN il campo Server name or address contenga esattamente l’FQDN previsto, senza spazi o suffissi.
Verificare che il file %SystemRoot%\System32\drivers\etc\hosts non contenga una riga che mappi il FQDN a un IP errato.
Eseguire ipconfig /flushdns e riprovare.
Se possibile, impostare temporaneamente DNS pubblici noti sul client per test.
Per un test testuale rapido: rasdial "NomeConnessioneVPN" per osservare l’errore in chiaro.

Procedura guidata di risoluzione

Verifica immediata della risoluzione esterna
nslookup vpn.dominio.com 8.8.8.8 Se non restituisce l’IP pubblico giusto, correggere o ricreare il record nel servizio DNS ospitato.
Aggiornamento della cache
Sul server e sui client: ipconfig /flushdns ipconfig /registerdns Attendere qualche minuto e riprovare la connessione.
Ricontrollo del port forwarding
Per tunnel basati su SSL, inoltrare TCP 443 dall’IP pubblico all’IP privato del server. Confermare con un port‑scanner esterno o con Test-NetConnection.
Analisi dei log
Esaminare:
- Applications and Services Logs → Microsoft → Windows → DNS‑Server
- Custom Views → Server Roles → Remote Access
Ricercare eventi su lookup falliti o handshake abortiti.
Packet capture mirata
Con filtri su dns, tcp.port==443 o il protocollo scelto, verificare se le richieste raggiungono il server.
Verifica dei certificati per tunnel sicuri
Il nome nel certificato deve corrispondere al FQDN; sostituire o rinnovare certificati scaduti e ripetere il binding se necessario.

Indicazioni per casi particolari

Zone duplicate: una zona pubblica clonata accidentalmente nel DNS interno con record A verso IP privati può mandare fuori strada i client connessi da reti non fidate.
Record multipli: la presenza di più record A con bilanciamento casuale può dirigere parte dei client verso un IP non pubblicato per la VPN.
Preferenza verso IPv6: se esiste un record AAAA non raggiungibile, alcuni sistemi tenteranno prima IPv6, generando time‑out apparenti.
Verifica revoche: per tunnel SSL, se i client non raggiungono i punti di distribuzione CRL e OCSP, l’handshake può fallire anche con DNS corretto.

Piano di contingenza e prevenzione

Record alternativo: creare un alias addizionale (ad esempio vpn2.dominio.com) puntato allo stesso IP per test rapidi o cutover.
Ridondanza DNS: impostare un server DNS autorevole secondario o affidarsi a un hosting gestito con SLA e monitoraggio.
Monitoraggio esterno: configurare un controllo periodico sul record DNS e sulla porta della VPN per ricevere alert proattivi.
Documentazione: mantenere un inventario di record DNS, scadenze dei certificati e mappature NAT.
Connettività di backup: per ambienti critici, prevedere un percorso di fail‑over con connessione secondaria.

Esempio di sessione di verifica completa

# Risoluzione pubblica da un host esterno
nslookup vpn.dominio.com 8.8.8.8

Verifica con PowerShell

Resolve-DnsName -Name "vpn.dominio.com" -Server 1.1.1.1 | Select Name,IPAddress,TTL

Test raggiungibilità della porta per tunnel SSL

Test-NetConnection -ComputerName "vpn.dominio.com" -Port 443 -InformationLevel Detailed

Flush e registrazione DNS sul server

ipconfig /flushdns
ipconfig /registerdns

Stato del ruolo Remote Access

Import-Module RemoteAccess
Get-RemoteAccess
Get-RemoteAccessConnectionStatistics

Ispezione binding SSL del listener HTTP

netsh http show sslcert

Domande frequenti

Perché in LAN funziona ma da Internet no?
Perché la risoluzione interna punta all’IP privato corretto, mentre da Internet il FQDN non risolve oppure risolve verso un IP errato o non pubblicato. In alternativa, il DNS è corretto ma la porta non è inoltrata al server RRAS giusto.

Meglio record A o CNAME?
Per servizi VPN è spesso preferibile un record A con TTL moderato. Un CNAME aggiunge flessibilità, ma deve puntare a un host con record A gestito in modo affidabile.

Quanto incide la propagazione del DNS?
Dipende dal TTL e dalle cache lungo il percorso. Dopo una modifica, alcuni client potrebbero vedere la nuova risposta in pochi minuti, altri richiedono più tempo.

Serve aprire più porte se uso tunnel basati su SSL?
No, in genere basta TCP 443 verso RRAS. Assicurarsi però che il certificato e il binding del listener siano corretti.

Checklist finale

Il FQDN risolve all’IP pubblico atteso dai principali resolver.
La porta del protocollo prescelto è raggiungibile dall’esterno.
Il port‑forwarding punta all’IP privato attuale del server VPN.
I log RRAS non riportano errori di certificato o handshake.
Non esistono voci spurie nel file hosts o record duplicati nelle zone interne.
Monitoraggio impostato su DNS e porta per allerta proattiva.

In sintesi

Il messaggio indica un problema di risoluzione nomi. La priorità è convalidare i record DNS pubblici del FQDN della VPN, eliminando cache e incongruenze di split‑horizon. Completata la risoluzione, verificare il percorso di rete fino a RRAS e l’integrità dei certificati. Con la checklist e i comandi proposti è possibile riportare in linea l’accesso remoto in modo metodico e ripetibile.

Procedura di risoluzione suggerita condensata

Controllo DNS pubblico con nslookup vpn.dominio.com 8.8.8.8; correggere i record se l’IP non è quello atteso.
Flush della cache su server e client con ipconfig /flushdns e ipconfig /registerdns.
Verifica del forwarding: per tunnel SSL, assicurarsi che TCP 443 sia inoltrato correttamente; confermare apertura con strumenti di test esterni.
Analisi log in DNS‑Server e Remote Access per tracciare errori di lookup e handshake.
Packet capture mirata su DNS e sulla porta del tunnel per validare il percorso.
Verifica e, se necessario, sostituzione o nuovo binding del certificato del server.
Piano di contingenza: record alternativo, DNS ridondato e monitoraggio continuo.