Come configurare una VPN su Windows Server 2012 e 2019

VPN su Windows Server: quando ha senso usare RRAS

Se l’obiettivo è dare accesso remoto sicuro a utenti, tecnici o sedi periferiche, su Windows Server la strada più lineare resta RRAS, cioè Routing and Remote Access Service. È una scelta pratica quando vuoi restare dentro l’ecosistema Microsoft, integrare autenticazione con Active Directory e avere un punto unico per gateway VPN, routing e, se serve, NAT.

Windows Server 2012 e 2019 seguono lo stesso impianto logico, ma cambiano alcuni dettagli operativi: su 2019 la gestione è più pulita, i protocolli moderni sono più semplici da sostenere e la parte di sicurezza TLS è meno “tollerante” verso configurazioni vecchie. Il punto non è fare clic a caso nella console, ma decidere prima tre cose: protocollo, autenticazione e piano di rete.

La configurazione che regge meglio in produzione è questa: RRAS come server VPN, autenticazione tramite NPS o Active Directory, certificato server valido, indirizzi client assegnati da pool dedicato o da DHCP ben controllato, regole firewall chiare e split tunneling deciso a monte. Se salti uno di questi passaggi, la VPN “sale” ma poi diventa fragile, lenta o ingestibile.

Scelta del protocollo: SSTP, L2TP/IPsec o IKEv2

Su Windows Server 2012 e 2019 la scelta del protocollo è il primo bivio serio. SSTP è spesso il più semplice da pubblicare verso Internet perché viaggia su TCP 443 e attraversa con meno attriti proxy e firewall. Richiede però un certificato server corretto e una catena fidata lato client. L2TP/IPsec è più classico, ma richiede più attenzione su NAT, porte UDP e pre-shared key o certificati. IKEv2 è solido e moderno, ma non sempre è il più comodo da esporre in ambienti eterogenei.

Se devi fare una scelta pragmatica per utenti remoti su Internet, SSTP è spesso il compromesso più lineare. Se invece hai client controllati, policy più rigide e vuoi un profilo più “pulito” sul piano crittografico, IKEv2 merita attenzione. L2TP/IPsec resta valido, ma è quello che più spesso genera ticket perché qualcuno ha dimenticato una porta, un NAT-T, o una chiave condivisa non allineata.

In pratica: scegli il protocollo in base al percorso di rete reale, non alla teoria. Una VPN perfetta su carta che non attraversa il firewall aziendale non serve a nessuno.

Prerequisiti minimi su Windows Server 2012 e 2019

Prima di toccare la console, verifica questi elementi. Sono banali solo finché non mancano.

1. Il server ha un IP statico e un nome DNS coerente con il certificato.
2. Il certificato server è valido, con nome soggetto o SAN corrispondente al FQDN usato dai client.
3. Il firewall perimetrale consente le porte necessarie al protocollo scelto.
4. Active Directory e DNS interni rispondono correttamente dal server VPN.
5. Esiste un piano per gli indirizzi client VPN che non collida con LAN, VLAN o subnet remote.

Per verificare rapidamente il nome del server e la reachability base, usa comandi semplici e guarda l’output, non le supposizioni.

hostname
ipconfig /all
nslookup vpn.tuodominio.example
ping -n 4 server-dc01

Se `nslookup` non risolve il nome pubblico o il certificato non combacia con il FQDN, la VPN può anche autenticarsi, ma il client si fermerà prima della connessione. Questo è uno dei punti in cui molti confondono “servizio up” con “servizio utilizzabile”.

Installazione del ruolo Remote Access con RRAS

Su Windows Server 2012 e 2019 il ruolo si installa da Server Manager, ma in ambienti amministrati conviene sapere anche la strada PowerShell, perché è più ripetibile e meno soggetta a click errati.

Da interfaccia grafica: apri Add Roles and Features, seleziona Remote Access, poi abilita DirectAccess and VPN (RAS) e Routing se ti serve anche il forwarding. Completa l’installazione e riavvia se richiesto.

Da PowerShell, il percorso è più diretto:

Install-WindowsFeature RemoteAccess, Routing -IncludeManagementTools

Dopo l’installazione, verifica che i componenti ci siano davvero e che il servizio RRAS sia presente.

Get-WindowsFeature RemoteAccess, Routing
Get-Service RemoteAccess

Se il servizio non compare o il ruolo risulta non installato, non andare avanti: il problema è a monte e non nella configurazione VPN.

Configurazione di RRAS come server VPN

Una volta installato il ruolo, apri la console Routing and Remote Access, fai click destro sul server e avvia la configurazione guidata. La scelta corretta, nella maggior parte dei casi, è Custom configuration, poi abilita VPN access. Se ti serve anche routing tra reti, abilita pure la parte di LAN routing, ma non mescolare tutto senza motivo.

Il servizio RRAS deve risultare avviato e configurato per accettare connessioni remote. Se stai usando un solo server per la VPN, lascia tutto il resto il più semplice possibile: meno componenti attivi, meno ambiguità da risolvere quando una sessione non sale.

Per controllare lo stato del servizio:

Get-Service RemoteAccess | Format-List Name,Status,StartType

Se il servizio è fermo, avvialo solo dopo aver verificato che la configurazione di rete e autenticazione sia già pronta. Avviare RRAS senza indirizzi, certificati o policy chiari produce solo debug inutile.

Certificato server: il punto che rompe più spesso SSTP e IKEv2

Per SSTP il certificato non è un dettaglio: è il requisito che fa funzionare o fallire la connessione. Deve essere un certificato server con EKU corretto, chiave privata disponibile sul server, catena attendibile e nome coerente con l’URL usato dal client. Se il nome pubblico è `vpn.azienda.example`, quello deve comparire nel certificato, non un nome interno qualsiasi.

Su Windows Server 2019 la gestione dei certificati è più comoda, ma il principio non cambia. Importa il certificato nel repository Local Computer e verifica che la chiave privata sia presente. Da MMC, il controllo è immediato. In PowerShell puoi almeno vedere che l’oggetto esista nel negozio corretto:

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,NotAfter,Thumbprint

Se usi una CA interna, ricordati che i client esterni devono fidarsi della root o della catena intermedia. Se questa fiducia non c’è, la VPN può sembrare “giusta” dal lato server ma il client rifiuterà il tunnel. Il modo corretto di chiudere il problema è distribuire la CA ai client, non disabilitare i controlli.

Assegnazione indirizzi: pool statico o DHCP

RRAS può assegnare indirizzi da un pool statico oppure delegare a DHCP. Il pool statico è più prevedibile, quindi spesso è la scelta migliore se vuoi tenere il controllo completo del range VPN. DHCP ha senso quando hai già una governance precisa sugli indirizzi e vuoi centralizzare il rilascio, ma aggiunge dipendenza da un altro servizio.

Il criterio corretto è semplice: la subnet VPN deve essere separata da quelle già usate in LAN e in eventuali sedi collegate. Se assegni ai client un range che collide con una rete raggiungibile altrove, il routing diventa ambiguo e i ticket arrivano sotto forma di “alcuni siti interni non si aprono”.

Per vedere gli indirizzi assegnati e lo stato della sessione, la console RRAS è spesso più rapida del CLI. In alternativa, puoi verificare le lease e le connessioni attive dal server, osservando che il client riceva un IP del range previsto e che la route sia coerente.

Autenticazione: NPS, gruppo AD e policy di accesso

La VPN non dovrebbe essere aperta a “chiunque riesca a passare”. La pratica corretta è limitare l’accesso a un gruppo di Active Directory e, se possibile, centralizzare la policy in NPS. Questo ti permette di separare il ruolo di chi può autenticarsi da chi può davvero entrare nel tunnel.

Su un’implementazione pulita, il flusso è questo: RRAS riceve la richiesta, NPS valuta l’utente, il gruppo AD autorizza, e solo allora la sessione parte. Se usi un server membro di dominio, verifica che il servizio abbia accesso ai controller di dominio e che la sincronizzazione oraria sia corretta. Un clock fuori tolleranza rompe Kerberos e innesca errori che sembrano “misteriosi” solo perché non si guarda il tempo.

Per diagnosticare un problema di autenticazione, i log utili sono quelli di NPS e degli eventi di sicurezza. In pratica, cerca eventi di rifiuto, mismatch di policy o errori di credenziali. Se il problema è lato gruppo, il fix è quasi sempre la membership corretta e non una nuova installazione del ruolo.

Firewall e porte: non dare per scontato il percorso esterno

Una VPN Windows funziona solo se il percorso tra client e server è coerente fino all’ultimo hop. Per SSTP devi esporre TCP 443 verso il server VPN. Per L2TP/IPsec servono UDP 500, UDP 4500 e, in certi casi, UDP 1701. Per IKEv2 i requisiti ruotano attorno a UDP 500 e 4500. Se c’è un firewall perimetrale, un reverse path filtering aggressivo o una policy cloud, il collo di bottiglia può stare lì e non su Windows.

La verifica minima è banalmente un test di reachability sul servizio esposto. Non basta un ping: serve vedere se la porta è aperta dal punto di vista del client esterno. Su Windows puoi usare `Test-NetConnection` per TCP; per UDP devi appoggiarti a strumenti o log più adatti al caso.

Test-NetConnection vpn.azienda.example -Port 443

Se il test fallisce ma il server risponde localmente, il problema è quasi certamente nel perimetro. Prima di modificare RRAS, controlla firewall host, firewall di rete e NAT pubblico. È un errore classico intervenire sulla VPN quando la porta non arriva nemmeno al server.

Split tunneling o tunnel completo: deciderlo prima, non dopo

Lo split tunneling lascia uscire su Internet il traffico non aziendale, mentre il tunnel completo manda tutto dentro la VPN. Dal punto di vista operativo, lo split tunneling riduce saturazione e latenza percepita, ma richiede policy più attente perché il client resta connesso sia alla rete locale sia a Internet. Il tunnel completo semplifica alcune regole di sicurezza, ma può peggiorare l’esperienza utente e aumentare il carico sul gateway.

Per molte organizzazioni la scelta ragionevole è lo split tunneling con rotta solo verso subnet interne, DNS aziendali e risorse sensibili. Se vuoi forzare tutto nel tunnel, assicurati che il server VPN regga il traffico e che il DNS remoto sia coerente, altrimenti gli utenti si troveranno con Internet lento e applicazioni interne ancora più lente.

La verifica pratica è osservare le route sul client dopo la connessione. Se la tabella mostra le reti interne con gateway VPN e il resto continua a uscire dalla rete locale, hai ottenuto uno split tunneling corretto.

route print
ipconfig /all

Client Windows: connessione manuale e distribuzione controllata

Dal lato client, Windows 10/11 si integra bene, ma anche i client più vecchi possono collegarsi se il protocollo e il certificato sono compatibili. Il profilo VPN va creato con l’FQDN corretto, il tipo di VPN coerente con il server e, se necessario, con il certificato della CA già fidato. Su ambienti gestiti, la distribuzione tramite GPO o Intune è preferibile rispetto all’inserimento manuale, perché elimina errori di digitazione e rende ripetibile la configurazione.

Un test utile è creare una connessione manuale su un solo client pilota, verificare autenticazione, DNS, accesso alle risorse interne e disconnessione pulita. Solo dopo passi alla distribuzione su larga scala. È il modo più veloce per isolare errori di configurazione prima che diventino un problema di supporto.

Verifiche finali: cosa controllare prima del go-live

Una VPN pronta in console non è ancora una VPN pronta per gli utenti. Prima di considerarla operativa, verifica questi punti con un client esterno reale.

1. Il client risolve il nome pubblico della VPN nel record DNS corretto.
2. La porta del protocollo scelto è raggiungibile dall’esterno.
3. Il certificato presentato dal server è valido e fidato.
4. L’utente autenticato riceve un indirizzo dalla subnet prevista.
5. Le risorse interne raggiungibili corrispondono al perimetro definito, senza route anomale.

Per un controllo rapido, osserva eventi, connessioni attive e traffico. Se qualcosa si rompe, la priorità non è “rifare tutto”, ma capire in quale layer si interrompe la catena: DNS, porta, certificato, autenticazione, assegnazione IP o routing.

Get-EventLog -LogName System -Newest 20 | Select-Object TimeGenerated,EntryType,Source,EventID,Message
Get-RemoteAccessConnectionStatistics

Rollback operativo: se la modifica ha introdotto regressioni, disabilita temporaneamente il protocollo appena attivato o ripristina la configurazione salvata del server RRAS. Tieni sempre una copia della configurazione precedente, perché su questo tipo di servizio il rollback rapido vale più di una correzione teoricamente elegante ma lenta da applicare.

Assunzione: il server è membro di dominio, il gateway è esposto con FQDN pubblico e l’obiettivo è accesso remoto per utenti autorizzati, non site-to-site complesso.

Problemi tipici su Windows Server 2012 e 2019

Su 2012 i problemi più frequenti sono certificati gestiti male, regole firewall incomplete e configurazioni RRAS lasciate a metà. Su 2019 emergono più spesso incoerenze con TLS, naming e policy di accesso troppo rigide o troppo permissive. In entrambi i casi, la diagnosi efficace parte dai log e non dalla reinstallazione del ruolo.

Se la VPN si connette ma non raggiunge le risorse interne, controlla i DNS distribuiti ai client, le route e la reachability verso i server interni. Se invece la connessione fallisce prima dell’autenticazione, il focus va su certificato, protocollo e firewall. Se l’autenticazione riesce ma la sessione cade, guarda NPS, time sync e policy di session timeout.

La regola pratica è questa: ogni volta che cambi un parametro, verifica subito il punto successivo della catena. Così eviti di accumulare tre problemi diversi e poi doverli separare a mano dopo ore di troubleshooting.