Windows Server 2019 RRAS VPN: niente Internet e unità mappate offline — cause, diagnosi e fix

La VPN RRAS su Windows Server 2019 si connette, assegna IP e consente i ping interni, ma Internet e alcuni servizi restano irraggiungibili e le unità mappate appaiono offline? Ecco diagnosi puntuale e correzioni definitive: NAT, split tunneling, DNS, firewall, routing e SMB.

Indice

Scenario e sintomi

Ambiente tipico: un Domain Controller (DC) con ruolo Routing and Remote Access (RRAS) offre l’accesso VPN ai client remoti. I dispositivi ottengono correttamente un indirizzo IP dal pool RRAS, possono eseguire ping su host interni, ma:

le unità di rete mappate risultano offline o non accessibili;
la navigazione Internet e l’accesso a servizi esterni (SaaS/posta) è impossibile;
l’icona di rete in Windows mostra il globo “Nessun accesso a Internet”.

Questi sintomi convergono quasi sempre su problemi di NAT/routing, configurazione del gateway, DNS o firewall. Più raramente entrano in gioco MTU/MSS, IPv6 o sovrapposizioni di subnet.

Comprendere il flusso: perché si rompe la connettività Internet

Quando un client è collegato alla VPN, il traffico con destinazione Internet può seguire due strategie:

Tunnel intero (default gateway remoto): tutto il traffico (0.0.0.0/0) passa nel tunnel verso il server RRAS. Per tornare al client, i pacchetti diretti a Internet devono essere tradotti (NAT) da un IP pubblico/nattabile. Se manca il NAT, le risposte si perdono.
Split tunneling: solo le reti aziendali (es. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) viaggiano nella VPN; il resto esce direttamente verso la WAN del client. In questo caso Internet funziona anche senza NAT sul server, ma i percorsi interni devono essere instradati correttamente e il DNS deve risolvere i nomi aziendali.

Il globo in systray è l’indicatore NCSI: se Windows non raggiunge endpoint di controllo (HTTP/HTTPS/DNS) secondo la strategia di routing vigente, mostra “Nessun accesso a Internet”. È un segnale utile, ma la prova decisiva è nei traceroute e nelle tabelle di routing.

Cause tecniche più probabili e verifiche lampo

Area	Perché può bloccare Internet / risorse	Controllo rapido
Routing & NAT	Se RRAS non effettua NAT verso la WAN o l’appliance di front‑end non nativa la subnet VPN, i pacchetti non ricevono risposte.	In RRAS → IPv4 > NAT verifica che l’interfaccia WAN sia Public con NAT abilitato oppure che esistano regole NAT sull’appliance per la subnet VPN.
Split tunneling / Default gateway	Con “Usa gateway predefinito sulla rete remota”, l’intero traffico passa nella VPN: senza NAT funzionante, Internet si blocca.	Client VPN → Proprietà → IPv4 → Avanzate → deseleziona la casella per fare split tunneling (opzionale), oppure mantienila ma assicura NAT.
DNS	I client puntano ai DNS del DC; se il DC non inoltra verso DNS esterni, la risoluzione dei nomi pubblici fallisce e i browser “non escono”.	In DNS Manager → Proprietà → Forwarders aggiungi resolver affidabili (o DNS ISP). Testa `nslookup`.
Firewall	Mancano regole in uscita per la subnet VPN (80/443), conflitti o priorità “Block” in Windows Defender Firewall o nel firewall perimetrale.	Permetti TCP 80/443 dalla subnet VPN verso WAN; controlla che le regole “RRAS” siano attive e non sovrascritte da policy più restrittive.
Routing table	Route statiche/metriche errate dirottano il traffico o eliminano la default route corretta.	`route print` su client/Server: la 0.0.0.0/0 deve puntare al gateway giusto (WAN o VPN a seconda della scelta).
Permessi/SMB & Nome	Le unità mappate crollano se il client non risolve correttamente i nomi interni o non è autenticato come membro di dominio.	Usa path FQDN (`\\fileserver.dominio.local\share`), verifica Kerberos (tempo/NTP), GPO SMB e suffisso DNS.
Sovrapposizione indirizzi	La LAN del client coincide con la LAN aziendale (es. 192.168.1.0/24): i pacchetti non possono essere instradati nella VPN.	Confronta `ipconfig` del client con le subnet aziendali. Usa pool VPN non sovrapposti (es. 10.99.0.0/24).
IPv6	Una default route IPv6 sul tunnel senza NAT IPv6 blocca la navigazione o crea asimmetria.	`route print -6`; se non gestisci IPv6, disabilita IPv6 per il profilo VPN o rimuovi la default route v6.
MTU/MSS	Frammentazione bloccata su path (soprattutto SSTP/IKEv2 dietro NAT) rende irraggiungibili solo alcuni siti/servizi.	Prova `ping -f -l 1300 8.8.8.8`; se funziona a MTU ridotta, fissa MSS/MTU sul tunnel.
Split DNS / Hairpin NAT	Accesso interno via FQDN pubblico del sito/SMTP: senza hairpin NAT o split DNS, il traffico rimbalza.	Preferisci FQDN interni per risorse interne o configura una zona DNS interna con gli stessi nomi (split‑horizon).

Diagnosi in 5 minuti (checklist operativa)

Verifica che il client stia davvero instradando nel tunnel ipconfig /all route print Se vedi una default route verso l’interfaccia VPN, stai usando tunnel intero: serve NAT lato server/perimetro.
Test di rete punto‑per‑punto ping 8.8.8.8 tracert -d 8.8.8.8 nslookup www.google.com Test-NetConnection -ComputerName 8.8.8.8 -Port 443 Il traceroute che si ferma al server VPN indica assenza di NAT o blocco firewall tra RRAS e Internet.
Controlla DNS dal client nslookup www.dominiointerno.local nslookup www.microsoft.com Se i nomi pubblici non si risolvono, imposta Forwarders su DNS del DC.
Connettività SMB \\fileserver.dominio.local\share net use z: \\fileserver.dominio.local\share /user:DOMINIO\utente /persistent:yes Se chiede credenziali “diverse”, il client non sta usando l’identità di dominio o non risolve il DC/KDC.

Procedura di risoluzione consigliata (passo‑passo)

Abilita e verifica il NAT su RRAS

Apri Server Manager → Routing and Remote Access.
Espandi il server → IPv4 → NAT.
Aggiungi l’interfaccia WAN (quella connessa a Internet) e spunta Enable NAT on this interface.
Assicurati che l’interfaccia Internal (quella della VPN) sia presente e non marcata come pubblica.

Nota importante: scegli un solo punto di traduzione. Se il NAT lo fa il firewall perimetrale, non abilitarlo anche in RRAS: in questo caso il firewall deve avere una regola di NAT source per la subnet del pool VPN e una route di ritorno verso il server RRAS.

(Opzionale) Configura lo split tunneling sui client

Dal client: Proprietà VPN → Rete → IPv4 → Avanzate.
Deseleziona Usa gateway predefinito sulla rete remota.
Aggiungi rotte statiche per le reti aziendali se il profilo VPN lo consente, oppure distribuiscile via script/GPO.

Se vuoi forzare tutto il traffico nella VPN (tunnel intero), lascia selezionato il gateway remoto e verifica con cura il NAT lato server/appliance.

Configura Forwarders DNS sul Domain Controller

Apri DNS Manager sul DC.
Click destro sul nome server → Properties → scheda Forwarders.
Aggiungi resolver esterni affidabili (o i DNS dell’ISP) e applica.

In questo modo i client che usano il DNS del DC risolveranno correttamente sia i nomi interni che quelli pubblici.

Regole firewall: Windows e perimetrale

Sul server RRAS consenti il transito in uscita verso Internet per il traffico originato dalla subnet VPN (HTTP/HTTPS, DNS se necessario):

New-NetFirewallRule -DisplayName "VPN Outbound Web" -Direction Outbound -Action Allow -Protocol TCP -RemotePort 80,443
New-NetFirewallRule -DisplayName "VPN Outbound DNS" -Direction Outbound -Action Allow -Protocol UDP -RemotePort 53

Sul firewall perimetrale inoltra le porte verso il server RRAS in base al tipo di VPN utilizzata:

Protocollo	Porte/Protocolli	Note
PPTP	TCP 1723 + GRE 47	Obsoleto, usare solo se indispensabile.
L2TP/IPsec	UDP 500, 4500, 1701	Richiede certificati/PSK e NAT‑T.
SSTP	TCP 443	Ottimo dietro proxy/NAT, necessita certificato valido.
IKEv2	UDP 500, 4500	Performante su Windows 10/11.

Controlla la tabella di routing sul server

Get-NetRoute -AddressFamily IPv4 | Where-Object {$_.DestinationPrefix -eq '0.0.0.0/0'} | Format-Table -AutoSize

La next hop deve essere il router/WAN reale. Se la default route punta all’interfaccia errata o ha metrica sfavorevole, il traffico non esce.

Test diagnostici mirati (dal client)

nslookup www.google.com
tracert 8.8.8.8
ping 8.8.8.8

Se tracert si ferma al server VPN, manca il NAT o il firewall blocca la traversata verso Internet. Se nslookup per host pubblici fallisce ma i ping a IP funzionano, il problema è il DNS.

Ricollega le unità mappate (dopo aver ripristinato rete/DNS)

Usa sempre FQDN interni: net use z: \\fileserver.dominio.local\condivisa /persistent:yes
Controlla l’ora e la sincronizzazione NTP (Kerberos è sensibile al time skew).
Se necessario, ripulisci ticket: klist purge
Verifica che la connessione VPN applichi il suffisso DNS del dominio (per i nomi brevi); da PowerShell: Set-VpnConnection -Name "AziendaVPN" -DnsSuffix "dominio.local" -PassThru

Problemi particolari: come riconoscerli e risolverli

Sovrapposizione di subnet (overlap)

È una delle cause più insidiose: se la LAN del telelavoratore (es. 192.168.1.0/24) coincide con la LAN aziendale, i pacchetti destinati al file server locale non passeranno mai nel tunnel. Soluzioni pratiche:

Usa un pool VPN dedicato non sovrapposto (es. 10.99.0.0/24).
Se possibile, cambia la subnet della sede o della VPN in un intervallo meno comune (es. 10.77.0.0/16).
In ambienti gestiti, distribuisci client router con policy‑based routing per la rete aziendale.

IPv6 preso “di traverso”

Alcuni profili RRAS creano una default route IPv6 all’interno del tunnel, ma l’infrastruttura non traduce/naviga su IPv6. Il risultato è un Internet “a tratti”. Contromisure:

Disabilita IPv6 soltanto sulla connessione VPN (non sull’intero OS).
Rimuovi la default route IPv6 sul client (route delete ::/0) se non la usi.

MTU/MSS e siti che “non aprono”

SSTP e IPsec aggiungono overhead. Se il path blocca frammentazione, le sessioni TLS possono piantarsi. Indicazioni:

Trova l’MTU massimo con ping -f -l verso un IP pubblico.
Imposta MTU sul NIC WAN o MSS‑clamp sul profilo (sui firewall perimetrali questa opzione è spesso disponibile). In Windows: netsh interface ipv4 show interfaces netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent

Split DNS e hairpin NAT

Utenti che accedono a mail.azienda.com (record pubblico) per raggiungere un servizio interno dietro NAT: in VPN il traffico può uscire e rientrare sullo stesso firewall (hairpin) e venire bloccato. Due vie:

Implementare split‑horizon DNS (zona interna con gli stessi nomi ma IP interni).
Abilitare l’hairpin NAT sull’appliance (se supportato) per consentire il loopback.

SMB, Kerberos e modalità “Offline”

Se i drive si mappano ma appaiono offline dopo pochi minuti:

Controlla i Criteri di rete lenta di “File offline” (GPO).
Verifica che il Client per reti Microsoft sia attivo sull’interfaccia VPN.
Assicurati che il tempo client <> DC sia entro ±5 minuti.

Best practice di sicurezza e architettura

Evita server “tuttofare”: tenere RRAS/NAT sul Domain Controller espone ruoli critici (AD DS, DNS) a superfici di attacco e carichi imprevisti. Se possibile, sposta RRAS su un member server o su un’appliance dedicata.
Certificati solidi per SSTP/IKEv2: usa certificati attendibili e CRL raggiungibili dai client esterni.
Log e auditing: abilita i log di RRAS/IKE per facilitare diagnosi (Event Viewer > Applications and Services Logs > RemoteAccess, IKEEXT).
Principio del minimo privilegio: limita chi può stabilire VPN e accedere alle condivisioni tramite gruppi AD dedicati.

Piano d’azione riassuntivo

NAT: abilitalo in RRAS oppure configura NAT sul firewall perimetrale per l’intera subnet del pool VPN (una sola posizione di NAT).
Gateway: decidi se usare tunnel intero o split tunneling; regola il flag del gateway remoto sui client.
DNS: imposta i Forwarders sul DC; verifica nslookup di nomi interni/esterni.
Firewall: consenti 80/443 in uscita dalla subnet VPN; inoltra le porte del protocollo VPN in uso.
Routing: controlla la default route del server; correggi metriche se necessario.
Test: usa tracert e Test-NetConnection per capire dove si interrompe il percorso.
Unità: mappa con FQDN, verifica Kerberos/NTP e suffisso DNS della VPN.

Appendice: comandi utili (pronti all’uso)

Client

:: Informazioni IP e route
ipconfig /all
route print

:: Test DNS e connettività
nslookup [www.google.com](http://www.google.com)
tracert -d 8.8.8.8
Test-NetConnection -ComputerName 1.1.1.1 -Port 443

:: Ping senza frammentazione per stimare MTU
ping -f -l 1300 8.8.8.8

:: Pulizia ticket Kerberos
klist purge

:: Mappatura drive (FQDN)
net use Z: \fileserver.dominio.local\condivisa /persistent:yes

Server RRAS / Windows Server 2019

# Verifica default route
Get-NetRoute -AddressFamily IPv4 | ? DestinationPrefix -eq '0.0.0.0/0' | ft -AutoSize

Regole firewall in uscita

New-NetFirewallRule -DisplayName "VPN Outbound Web" -Direction Outbound -Action Allow -Protocol TCP -RemotePort 80,443
New-NetFirewallRule -DisplayName "VPN Outbound DNS" -Direction Outbound -Action Allow -Protocol UDP -RemotePort 53

Mostra interfacce e metriche

Get-NetIPInterface | Sort-Object -Property InterfaceMetric | ft ifIndex,InterfaceAlias,AddressFamily,InterfaceMetric -Auto

(Facoltativo) Adegua MTU su interfaccia WAN

netsh interface ipv4 show interfaces
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent

FAQ rapide

Il globo “nessun accesso a Internet” scompare appena abilito lo split tunneling. È normale?
Sì: in split tunneling il traffico Internet esce dal gateway locale del client, quindi NCSI torna a vedere Internet. Con tunnel intero, il globo sparisce solo se il NAT lato server funziona e non ci sono blocchi.

Meglio NAT su RRAS o sul firewall perimetrale?
Dal punto di vista funzionale vanno bene entrambi, ma scegli un solo posto e mantieni le route coerenti. La scelta più pulita è spesso il firewall perimetrale (che già gestisce NAT/ACL), con una route di ritorno verso RRAS per la subnet VPN.

Le unità continuano a diventare “offline”.
Verifica GPO di “File offline”, latenza del link, tempo NTP e che le condivisioni siano raggiunte via FQDN interno. Se usi nomi brevi, configura suffisso DNS sulla VPN o una zona GlobalNames.

Alcuni siti non si aprono, altri sì.
Classico problema di MTU/MSS: regola l’MTU o abilita MSS‑clamp sul percorso.

Conclusione

Nel 90% dei casi, un accesso VPN RRAS che “pinga” ma non navighi si risolve ripristinando il NAT (o attivando lo split tunneling), impostando correttamente i Forwarders DNS e allineando route e regole firewall. Una volta ristabilite le basi, le unità mappate tornano online e i servizi esterni riprendono a funzionare. Per la sicurezza e la manutenibilità, evita di concentrare DC, DNS e RRAS sullo stesso host quando possibile.

Nota finale: su un Domain Controller che funge anche da RRAS, il rischio principale è sovraccaricare un singolo server con ruoli critici (AD DS, DNS, VPN, NAT). Se possibile, sposta RRAS/NAT su un member server o su un’appliance dedicata: migliora la sicurezza, riduce l’esposizione e semplifica la gestione delle regole firewall.