VPN Windows Server 2019 connessa ma senza Internet: diagnosi e soluzioni RRAS

VPN su Windows Server 2019 connessa, ma niente Internet e risorse interne irraggiungibili? Ecco una guida completa, pratica e pronta all’uso per risolvere il classico scenario “il traffico resta confinato al server RRAS” con istruzioni passo‑passo, check rapidi, tabelle e comandi.

Indice

Panoramica del problema

Hai attivato il ruolo Routing & Remote Access (RRAS) su un domain controller (o su un server membro) con Windows Server 2019. I client si collegano alla VPN e riescono persino a fare RDP verso il server. Tuttavia:

le unità di rete mappate appaiono “rosse” o disconnesse;
applicazioni come SQL Server e Sage non rispondono;
non si aprono siti web, non partono e‑mail (HTTP/HTTPS/SMTP inaccessibili).

In pratica il traffico rimane “intrappolato” sull’RRAS e non raggiunge né Internet né le reti interne dietro il server.

Cosa sta succedendo davvero (in breve)

RRAS crea un’interfaccia virtuale Internal per i client dial‑in. Se NAT, instradamento, DNS e ACL/Firewall non sono coerenti, i pacchetti non sanno dove andare, o non vengono tradotti, o non risolvono i nomi. Il risultato è un tunnel attivo ma inutile.

Diagnostica rapida in 10 minuti

Dal client VPN:
- ipconfig /all: controlla Gateway, DNS, Suffisso DNS, Metriche.
- route print: verifica dove puntano default route (0.0.0.0/0) e route per le subnet aziendali.
- ping 8.8.8.8 e tracert 8.8.8.8: se falliscono con full‑tunnel, manca NAT o l’uscita Internet dal server.
- ping 192.168.x.y (un server di LAN) e tracert relativo: se falliscono in split‑tunnel, mancano le route.
- nslookup server.dominio.local: se non risolve, i DNS non sono interni o non funzionano i forwarder.
- Test-NetConnection server-sql -Port 1433 (PowerShell): verifica raggiungibilità SQL.
Sul server RRAS:
- Apri Routing and Remote Access → IPv4 → NAT: verifica che l’interfaccia verso Internet sia Public con Enable NAT attivo e che l’interfaccia Internal sia impostata come Private.
- Controlla che il server abbia un solo gateway predefinito e che punti effettivamente verso l’esterno.
- In Proprietà del server RRAS → IPv4: verifica se l’assegnazione IP è DHCP o Static address pool e che non ci siano sovrapposizioni con reti domestiche comuni (192.168.0.0/24, 192.168.1.0/24).
- Event Viewer: log di RRAS e NPS (se presente) per errori di autenticazione o assegnazione parametri.

Cause tecniche più comuni

Ambito	Possibile anomalia
Instradamento/NAT	Il server VPN non traduce o non inoltra il traffico Internet perché NAT non è configurato o manca una seconda interfaccia (o l’interfaccia Internal non è marcata come Private).
Split tunneling	L’opzione Usa gateway predefinito sulla rete remota instrada tutto nel tunnel: se il server non fa NAT, la navigazione fallisce; se l’opzione è disattivata senza route statiche, non si raggiungono le reti interne.
DNS	I client ricevono DNS pubblici o usano solo la cache locale, quindi non risolvono i nomi interni (SMB, SQL, Sage) né quelli Internet quando il traffico è forzato nel tunnel.
Firewall/ACL	Porte HTTP/HTTPS, SMTP, SQL o l’intera subnet VPN sono bloccate da Windows Firewall, da un firewall perimetrale o da ACL su switch/router.
Permessi share/DB	SMB, SQL o Sage non autorizzano la subnet del pool VPN oppure la risoluzione SPN/Kerberos fallisce (porte RPC/LDAP chiuse, orologi fuori sync).

Soluzioni operative (riassunto)

Area	Intervento consigliato
Configurare NAT in RRAS	In Routing & Remote Access → IPv4 → NAT, seleziona l’interfaccia verso Internet, attiva Enable NAT on this interface, Internal come Private, quindi riavvia RRAS.
Gestire lo split tunneling	Internet locale al client: deseleziona Usa gateway predefinito sulla rete remota nelle proprietà IPv4 della VPN (o usa PowerShell client). Full‑tunnel: lascia l’opzione attiva ma assicurati che il server faccia NAT e abbia un gateway verso l’esterno.
Aggiungere route statiche	Definisci route per le subnet interne (es. `192.168.10.0/24`) lato client (preferito: GPO/PowerShell) o in RRAS/NPS quando supportato.
Pool IP e DNS	Assegna ai client VPN DNS interni (il DC/DNS, es. `192.168.10.2`). Sul DNS interno configura Forwarder pubblici per la risoluzione esterna.
Verificare firewall e ACL	Consenti 80/443, SMTP, 1433 (SQL), 445 (SMB), 88/389/636/135 + range dinamico RPC, per la subnet del pool VPN, su RRAS e sui server applicativi.
Test di connettività	`ipconfig /all`, `ping`/`tracert`, `nslookup`, `Test-NetConnection`. Isola l’anello che rompe la catena (NAT, DNS, ACL).
Logging	Event Viewer → Microsoft → Windows → Routing and Remote Access. Abilita tracing RRAS per dettagli.

Procedure guidate passo‑passo

Configurare correttamente NAT in RRAS

Obiettivo: permettere ai client VPN di uscire a Internet tramite l’IP pubblico del server (o del firewall a monte) e di raggiungere tutte le reti interne.

Apri Server Manager → Tools → Routing and Remote Access.
Espandi IPv4 → NAT. Se NAT non è presente, aggiungilo (dipende dalla vista della console: in alcune installazioni è già elencato).
Aggiungi l’interfaccia esterna:
- Right‑click su NAT → New Interface… → seleziona la scheda che esce a Internet (es. Ethernet0).
- Spunta Public interface connected to the Internet e Enable NAT on this interface.
Configura l’interfaccia interna:
- Aggiungi l’interfaccia Internal (creata da RRAS) come Private interface connected to private network.
- Se il server ha una NIC verso la LAN, anche quella deve essere Private (senza NAT).
Verifica che il server abbia un solo default gateway sull’interfaccia esterna. Sulle NIC interne non impostare gateway; se servono altre subnet, usa route statiche.
Riavvia il servizio RRAS dal Routing and Remote Access o con: net stop remoteaccess && net start remoteaccess

Nota su server con una sola NIC: funziona ugualmente. L’interfaccia Internal rappresenta i client VPN e viene vista da NAT come rete privata; l’unica NIC fisica è quella pubblica. Accertati che sia Public + NAT e che il default gateway della macchina punti al router ISP.

Gestire lo split tunneling (o full‑tunnel) in modo consapevole

Scelta A – Split tunneling: il client usa Internet locale e il tunnel solo per le reti aziendali.

In Windows client: Connessioni di rete → tua VPN → Proprietà → tab Rete → seleziona Protocollo Internet versione 4 (TCP/IPv4) → Avanzate… → disattiva Usa gateway predefinito sulla rete remota.
Aggiungi le route alle subnet interne (in modo persistente e solo quando la VPN è connessa). Da PowerShell sul client: # Abilita split tunneling su una VPN esistente Set-VpnConnection -Name "VPN-Azienda" -SplitTunneling $true -AllUserConnection Aggiunge una route che si attiva con la VPN Add-VpnConnectionRoute -ConnectionName "VPN-Azienda" -DestinationPrefix 192.168.10.0/24 Add-VpnConnectionRoute -ConnectionName "VPN-Azienda" -DestinationPrefix 192.168.20.0/24

Scelta B – Full‑tunnel: tutto passa nel tunnel. Devi obbligatoriamente avere NAT funzionante sull’RRAS (o su un firewall a valle dell’RRAS) e un percorso Internet valido. Se manca NAT, il traffico Internet “muore” dentro la VPN.

Aggiungere route statiche lato server e lato client

Se in LAN hai più subnet dietro router di core (es. 192.168.10.0/24 e 192.168.20.0/24), il server RRAS deve conoscere il percorso:

In Routing and Remote Access → IPv4 → Static Routes → New Static Route…:
- Destination: 192.168.20.0 – Mask: 255.255.255.0 – Gateway: IP del router LAN (es. 192.168.10.254) – Interface: NIC interna.

Con split tunneling, oltre a ciò, i client devono avere le route verso tutte le subnet interne. Il modo più pulito in dominio è una GPO (Group Policy Preferences → Network Options → Routes), oppure i comandi PowerShell visti sopra.

Impostare correttamente pool IP e DNS per i client VPN

Apri le Proprietà del server RRAS → tab IPv4:
- IP address assignment: scegli Static address pool e definisci un range dedicato ai client VPN (es. 10.20.50.10–10.20.50.200), non sovrapposto alla LAN.
- In ambienti con DHCP centralizzato puoi scegliere DHCP, ma accertati che il DHCP rilasci DNS interni e che RRAS sia autorizzato a inoltrare le richieste DHCP.
DNS dei client: assegna come primario l’IP del DC/DNS (es. 192.168.10.2). Evita DNS pubblici sui client quando il traffico passa nel tunnel, altrimenti la risoluzione interna fallisce.
DNS interno (sul DC): imposta Forwarder pubblici (es. resolver del tuo ISP) per consentire la risoluzione dei nomi Internet; attiva ricorsione e verifica che le zone AD siano integre.
Suffix di ricerca DNS: spingi il suffisso dominio.local ai client (GPO: Computer Configuration → Policies → Administrative Templates → Network → DNS Client).

Firewall e ACL: regole minime per far lavorare tutto

Apri le porte dal pool VPN verso i server interni necessari. Esempi comuni:

Servizio	Porte/Protocolli	Note
DNS	UDP/TCP 53	Risoluzione nomi interni ed esterni via forwarder.
SMB (Condivisioni)	TCP 445	Evita NetBIOS; usa solo SMB su 445.
Kerberos/LDAP	TCP/UDP 88, TCP/UDP 389, TCP 636	Login in dominio, GPO, lookup utenti.
RPC	TCP 135 + range dinamico 49152–65535	Necessario per vari servizi AD/gestione.
SQL Server	TCP 1433 (+ browser 1434 UDP se usato)	Imposta porte statiche se vuoi restringere.
Sage (esempio)	TCP 5493 (verifica la tua edizione)	Alcune release usano porte diverse.
HTTP/HTTPS	TCP 80/443	Portali interni e proxy aziendali.

Suggerimento: sul Windows Defender Firewall dei server applicativi crea regole Scope che limitino l’accesso in base alla subnet del pool VPN.

Check specifici per SMB, SQL e Sage

SMB (unità mappate “rosse”)

Verifica DNS: nslookup fileserver.dominio.local deve risolvere l’IP corretto.
Controlla l’orario client vs DC (Kerberos): scarti >5 minuti rompono l’autenticazione.
Firewall del fileserver: File and Printer Sharing (SMB‑In) abilitato per il pool VPN.
Prova una mappatura forzata: net use Z: \\fileserver\condivisione /user:DOMINIO\utente

SQL Server

SQL Server Configuration Manager → Protocols for MSSQLSERVER: TCP/IP abilitato.
SQL Server Network Configuration → TCP/IP → scheda IP Addresses: assegna porta statica (es. 1433) e riavvia servizio SQL.
Firewall: regola in ingresso TCP 1433 limitata al pool VPN.
Test dal client: Test-NetConnection sqlserver.dominio.local -Port 1433

Sage

Individua la porta della tua versione (esempio comune: 5493) e crea la regola in firewall.
Se il client usa nome host, assicurati che il DNS interno risolva sempre verso l’IP LAN del server Sage.

Playbook per tre scenari reali

Scenario 1 – Full‑tunnel, 1 sola NIC sul server

NAT attivo sull’unica NIC (Public + Enable NAT), interfaccia Internal come Private.
Gateway predefinito del server: router ISP.
DNS del server: solo DC/DNS interni (non pubblici). NIC esterna: no registrazione DNS.
Pool VPN dedicato e DNS interni assegnati ai client.
Verifica ping 8.8.8.8 dal client e Test-NetConnection sulle porte interne.

Scenario 2 – Full‑tunnel, 2 NIC (consigliato)

NIC esterna: Public + NAT e unico default gateway.
NIC interna: Private, senza gateway. Aggiungi rotte statiche verso altre subnet LAN se presenti.
Regole firewall serrate per traffico dal pool VPN.

Scenario 3 – Split tunneling per prestazioni

Sui client disattiva Use default gateway on remote network o usa: Set-VpnConnection -Name "VPN-Azienda" -SplitTunneling $true -AllUserConnection Add-VpnConnectionRoute -ConnectionName "VPN-Azienda" -DestinationPrefix 192.168.10.0/24
Distribuisci le route con GPO per evitare errori manuali.
Proteggi comunque le porte interne con ACL specifiche per la subnet VPN.

Strumenti di verifica e logging

Event Viewer: Applications and Services Logs → Microsoft → Windows → Routing and Remote Access.
Tracing RRAS: netsh ras set tracing * enabled ...riprodurre il problema... netsh ras set tracing * disabled
Test puntuali: ipconfig /all route print ping 192.168.10.2 tracert 8.8.8.8 nslookup fileserver.dominio.local Test-NetConnection fileserver -Port 445 Test-NetConnection sqlserver -Port 1433
Packet capture (server): pktmon start --etw -m real-time oppure con Wireshark se disponibile

Attenzioni speciali quando RRAS gira su un Domain Controller

NIC esterna e DNS: sulla NIC esterna rimuovi i DNS pubblici e disattiva la registrazione in DNS per evitare che l’IP pubblico finisca nelle zone AD.
Un solo default gateway (sull’interfaccia esterna). Sulla NIC interna nessun gateway; usa route statiche per eventuali subnet.
Orario NTP coerente (Kerberos): DC e client devono essere allineati.

Risoluzione per categorie: cosa fare se…

…la VPN è connessa ma non navigo in Internet

Se full‑tunnel: verifica NAT sull’interfaccia pubblica e che il server esca a Internet.
Se split tunneling: assicurati di non avere default route sul tunnel e che le route di Internet puntino alla scheda locale.
Controlla se un proxy aziendale è richiesto (e raggiungibile) dal pool VPN.

…vedo il server via RDP ma nessuna condivisione

DNS interni corretti ai client.
SMB su 445 consentito dal firewall del fileserver verso il pool VPN.
Ticket Kerberos validi (sincronizzazione oraria); in caso di dubbi prova con credenziali esplicite su net use.

…SQL Server non risponde

TCP/IP abilitato e porta statica impostata.
Regole firewall inbound su 1433 per pool VPN.
Test-NetConnection dalla postazione remota per isolare DNS vs connettività.

Checklist finale (metodo “zero sorprese”)

Topologia: disegna le subnet LAN, il pool VPN e dove sta il default gateway.
NAT: interfaccia pubblica = Public + Enable NAT, interfaccia Internal = Private.
Routing: rotte statiche per subnet interne lato RRAS; split‑tunnel = rotte lato client.
DNS: client VPN usano DNS interni; sul DNS interno forwarder pubblici attivi.
Firewall/ACL: apri porte necessarie dal pool VPN; vieta tutto il resto.
Test: ipconfig, route print, nslookup, Test-NetConnection, tracert.
Log: Event Viewer RRAS/NPS; netsh ras tracing per casi ostinati.

Suggerimenti aggiuntivi e buone pratiche

Con una sola NIC, verifica che il gateway predefinito del server punti al router ISP; valuta NAT loopback se i client devono raggiungere FQDN pubblici che risolvono al tuo IP.
Se possibile, distribuisci IKEv2 con autenticazione a certificati al posto di PPTP/L2TP (sicurezza e stabilità superiori).
Documenta chiaramente le subnet interne e il pool IP VPN per evitare conflitti con reti domestiche (192.168.0.0/24, 192.168.1.0/24, 192.168.100.0/24, 10.0.0.0/24).
Per ambienti regolamentati, valuta MFA su NPS (EAP‑TLS + fattore addizionale) e auditing delle sessioni.
Riduci la superficie d’attacco: limita il traffico dal pool VPN a gruppi di server e porte necessarie, non a Any‑Any.

Esempi di comandi utili (pronti da incollare)

:: Lato client Windows
ipconfig /all
route print
nslookup server.dominio.local
ping 192.168.10.2
tracert 8.8.8.8
powershell -command "Test-NetConnection fileserver -Port 445"
powershell -command "Test-NetConnection sqlserver -Port 1433"

:: Abilita split tunneling e aggiunge route alla LAN
powershell -command "Set-VpnConnection -Name 'VPN-Azienda' -SplitTunneling $true -AllUserConnection"
powershell -command "Add-VpnConnectionRoute -ConnectionName 'VPN-Azienda' -DestinationPrefix 192.168.10.0/24"

:: Lato server: riavvia RRAS
net stop remoteaccess && net start remoteaccess

:: Tracing RAS
netsh ras set tracing * enabled
netsh ras set tracing * disabled

:: Esempi firewall Windows (scope: subnet VPN 10.20.50.0/24)
netsh advfirewall firewall add rule name="VPNSMBIN" dir=in action=allow protocol=TCP localport=445 remoteip=10.20.50.0/24
netsh advfirewall firewall add rule name="VPNSQLIN" dir=in action=allow protocol=TCP localport=1433 remoteip=10.20.50.0/24
netsh advfirewall firewall add rule name="VPNDNSIN" dir=in action=allow protocol=TCP localport=53 remoteip=10.20.50.0/24
netsh advfirewall firewall add rule name="VPNDNSIN_UDP" dir=in action=allow protocol=UDP localport=53 remoteip=10.20.50.0/24

Domande frequenti

È obbligatoria la seconda NIC per fare NAT?
No. Con RRAS la rete dei client VPN è rappresentata dall’interfaccia virtuale Internal e puoi NATtare verso l’unica scheda pubblica. Con due NIC gestisci meglio la separazione dei domini di rete.

Posso usare DNS pubblici sui client?
Solo se usi split tunneling e non devi risolvere nomi interni via VPN. In tutti gli altri casi usa DNS interni e forwarder sul DNS aziendale.

Le unità mappate compaiono “rosse” subito dopo il login remoto
Sui laptop fuori dominio (o con VPN che si connette dopo il login) le GPO non montano le share. Usa GPP Item‑level targeting o script di logon che si attivano dopo l’up della VPN.

Con full‑tunnel i siti si aprono lentamente
Verifica MTU sul percorso e frammentazione. In molti casi MTU 1400–1472 risolve. Puoi testare con ping -f -l <bytes> 8.8.8.8.

Ho più subnet interne e solo alcune sono raggiungibili
Mancano route: aggiungi rotte statiche sul server RRAS verso le subnet dietro router di core e, se usi split tunneling, aggiungi le corrispondenti route sui client.

Conclusione

Quando una VPN su Windows Server 2019 risulta “connessa ma senza Internet e risorse interne”, la causa è quasi sempre una combinazione di NAT non attivo, routing incompleto, DNS errato o ACL troppo restrittive. Con i passaggi di questa guida (NAT su RRAS, scelte chiare su split/full‑tunnel, route corrette, DNS interni e firewall mirati) riporti rapidamente i client a navigare e ad accedere a file, SQL e applicazioni come Sage.

Riferimento operativo sintetico

NAT: Public+NAT sull’uscita Internet; Internal come Private; riavvia RRAS.
Split/Full‑tunnel: scegli consapevolmente; se full‑tunnel, NAT obbligatorio.
Route: lato server verso tutte le subnet; lato client in split‑tunnel.
DNS: client → DNS interno; DNS interno → forwarder pubblici.
Firewall: apri porte a scope pool VPN; prova con Test-NetConnection.
Log: Event Viewer RRAS; netsh ras set tracing.

Appendice: modello di tabella per la tua documentazione

Voce	Valore	Note
Pool VPN	10.20.50.10–10.20.50.200	Non sovrapposto alle reti domestiche comuni
Subnet interne	192.168.10.0/24; 192.168.20.0/24	Route lato server e lato client (split)
DNS clienti	192.168.10.2	DC/DNS con forwarder pubblici
Gateway server	IP router ISP	Unico default gateway
Porte aperte	53, 88/389/636, 135+49152–65535, 445, 1433, 80/443	Scope: subnet del pool VPN

Seguendo questi controlli si risolve la maggior parte dei casi in cui “la VPN si connette ma non c’è Internet e le risorse di rete risultano disconnesse” su Windows Server 2019.