Supporto Windows 13 min di lettura

VPN Aziendale Non Funziona su Windows 11: Guida Troubleshooting per l'Helpdesk

Guida pratica al troubleshooting VPN aziendale su Windows 11 per tecnici helpdesk: codici di errore spiegati, Always On VPN, comandi PowerShell pronti all'uso, fix WireGuard 25H2 e script diagnostico.

Editorial Team

Se lavorate nell'helpdesk nel 2026, lo sapete già: i ticket VPN sono esplosi. Non è un'impressione — tra aggiornamenti cumulativi di Windows 11 che rompono connessioni perfettamente funzionanti, la transizione forzata da DirectAccess ad Always On VPN, i conflitti con WireGuard su 25H2 e gli utenti in smart working che vi chiamano dicendo "non riesco ad accedere a nulla"... beh, la VPN è diventata il tema caldo del supporto IT.

E il bello è che il troubleshooting VPN è un vero labirinto. Può essere un certificato scaduto, un driver WAN Miniport corrotto, una policy NPS mal configurata o semplicemente il firewall che blocca la porta sbagliata. Ho messo insieme questa guida dopo mesi di ticket risolti sul campo, con comandi PowerShell pronti al copia-incolla, codici di errore spiegati uno per uno e procedure che funzionano davvero.

Perché le VPN aziendali danno più problemi che mai su Windows 11

Windows 11 ha cambiato parecchie cose nello stack di rete, e le VPN ne hanno risentito. Con la 24H2, Microsoft ha iniziato a deprecare PPTP e L2TP/IPsec per le nuove connessioni, spingendo tutti verso IKEv2 e SSTP. Con la 25H2 (rilasciata a fine 2025) sono arrivati ulteriori grattacapi, soprattutto legati a WireGuard e ai driver WAN Miniport.

Insomma, i fattori che complicano la vita nel 2026 sono diversi:

  • Deprecazione di PPTP e L2TP — Microsoft sta rimuovendo gradualmente questi protocolli, e le aziende che non hanno ancora migrato si trovano nei guai
  • Aggiornamenti cumulativi problematici — alcuni aggiornamenti di sicurezza hanno introdotto bug che rompono le connessioni VPN già funzionanti (sì, succede più spesso di quanto pensiate)
  • WSL che rompe le VPN — gli aggiornamenti di sicurezza recenti causano conflitti per chi usa Windows Subsystem for Linux, che ormai è parecchio diffuso tra gli sviluppatori
  • Modalità Stampa Protetta di Windows 11 24H2 — può interferire con i tunnel VPN in certi scenari di rete, ed è una di quelle cose che non ti aspetti
  • Transizione ad Always On VPN — la migrazione da DirectAccess porta con sé nuove complessità di certificati e NPS

Diagnosi rapida: i primi 5 minuti di troubleshooting

Prima di andare a scavare nei singoli errori, ecco la procedura da seguire nei primi 5 minuti di un ticket VPN. Questa checklist veloce — ve lo dico per esperienza — risolve circa il 40% dei casi senza bisogno di andare oltre.

1. Verificare la connessione Internet di base

Sembra banale, ma non avete idea di quanti ticket VPN si rivelano semplici problemi di connettività. Chiedete all'utente di aprire il browser e navigare verso un sito qualsiasi. Se non funziona, il problema non è la VPN.

Test-NetConnection -ComputerName www.google.com -Port 443

2. Controllare lo stato delle connessioni VPN configurate

# Elencare tutte le connessioni VPN dell'utente
Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, ConnectionStatus

# Elencare le connessioni VPN a livello dispositivo (Always On VPN)
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType, ConnectionStatus

3. Svuotare la cache DNS e rinnovare l'IP

ipconfig /flushdns
ipconfig /release
ipconfig /renew

4. Verificare che i servizi critici siano in esecuzione

# Controllare il servizio RasMan (Remote Access Connection Manager)
Get-Service -Name RasMan | Select-Object Name, Status, StartType

# Controllare il servizio IKEEXT (IKE and AuthIP IPsec Keying Modules)
Get-Service -Name IKEEXT | Select-Object Name, Status, StartType

# Se sono fermi, riavviarli
Restart-Service -Name RasMan -Force
Restart-Service -Name IKEEXT -Force

5. Testare la raggiungibilità del server VPN

# Verificare che il server VPN sia raggiungibile
Test-NetConnection -ComputerName vpn.azienda.it -Port 443

# Per IKEv2, testare la porta UDP 500
Test-NetConnection -ComputerName vpn.azienda.it -Port 500

Codici di errore VPN: la guida definitiva per l'helpdesk

Quando un utente vi segnala un errore VPN, il codice di errore è la vostra bussola. Andiamo a vedere i codici più comuni che incontrerete nel 2026, con cause e soluzioni per ciascuno.

Errore 800 — Il server VPN non è raggiungibile

Messaggio: "La connessione remota non è stata stabilita perché i tunnel VPN tentati non hanno funzionato."

Questo è probabilmente l'errore più generico che vedrete. Le cause possono essere diverse:

  • Firewall aziendale che blocca le porte VPN (UDP 500, UDP 4500 per IKEv2; TCP 443 per SSTP)
  • Server VPN offline o non raggiungibile
  • Nome server errato nel profilo di connessione
  • Parametri IPsec non configurati correttamente

Soluzione:

# Verificare raggiungibilità e porte
Test-NetConnection -ComputerName vpn.azienda.it -Port 500 -InformationLevel Detailed
Test-NetConnection -ComputerName vpn.azienda.it -Port 4500 -InformationLevel Detailed

# Controllare le regole firewall locali
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*VPN*" -or $_.DisplayName -like "*IKE*" -or $_.DisplayName -like "*IPsec*"} | Select-Object DisplayName, Enabled, Action

Errore 809 — Connessione bloccata da firewall o NAT

Messaggio: "Non è stato possibile stabilire la connessione di rete tra il computer e il server VPN perché il server remoto non risponde."

Questo errore lo vedrete tantissimo con gli utenti in smart working. È estremamente comune quando l'utente si trova dietro un NAT (tipicamente un router domestico) e sta usando L2TP/IPsec. Il traffico ESP viene bloccato dalla maggior parte dei router consumer.

Fix tramite registro di sistema:

# Abilitare NAT Traversal per L2TP/IPsec (richiede riavvio)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" `
  -Name "AssumeUDPEncapsulationContextOnSendRule" `
  -Value 2 -PropertyType DWORD -Force

# Riavviare il servizio IPsec
Restart-Service -Name PolicyAgent -Force

Errore 812 — Metodo di autenticazione non corrispondente

Messaggio: "La connessione è stata impedita a causa di un criterio configurato nel server RAS/VPN."

Questo è un classico: c'è un disallineamento tra il metodo di autenticazione configurato nel profilo VPN del client e quello impostato nel Network Policy Server. Verificate che le policy NPS accettino il tipo di autenticazione EAP-TLS o PEAP che il client sta cercando di usare. Spesso basta allineare le due configurazioni.

Errore 13806 — Certificato macchina non trovato

Messaggio: "IKE non ha trovato un certificato della macchina valido."

Questo errore fa impazzire perché sembra chiaro, ma le cause possono essere molteplici.

# Verificare i certificati installati nel computer store
Get-ChildItem -Path Cert:\LocalMachine\My | 
  Select-Object Subject, NotAfter, Thumbprint, 
  @{N="EKU";E={($_.EnhancedKeyUsageList | ForEach-Object {$_.FriendlyName}) -join ", "}} |
  Format-Table -AutoSize

# Verificare che il certificato abbia l'EKU "Client Authentication"
Get-ChildItem -Path Cert:\LocalMachine\My | 
  Where-Object {$_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"}

Se non trovate certificati con l'EKU corretto, dovete verificare che l'auto-enrollment sia configurato via GPO e che la CA aziendale sia raggiungibile. È una di quelle cose che una volta impostata funziona da sola, ma quando si rompe... ci vuole un po' per capire dove cercare.

Errore 13801 — Credenziali IKE non accettabili

Questo errore di solito indica che il certificato del server VPN è scaduto, non è firmato da una CA trusted dal client, oppure il nome nel certificato non corrisponde al FQDN usato nella connessione. Onestamente, 9 volte su 10 è un certificato scaduto.

# Verificare la catena di certificati del server VPN
Test-NetConnection -ComputerName vpn.azienda.it -Port 443 -InformationLevel Detailed

# Verificare i certificati root trusted
Get-ChildItem -Path Cert:\LocalMachine\Root | 
  Where-Object {$_.Subject -like "*NomeCA*"} | 
  Select-Object Subject, NotAfter, Thumbprint

Errore 0x80070040 — EKU Server Authentication mancante

Il certificato sul server VPN deve contenere l'Extended Key Usage "Server Authentication" (OID 1.3.6.1.5.5.7.3.1). Se manca, tutti i client IKEv2 rifiuteranno la connessione. La soluzione è semplice: richiedete un nuovo certificato dalla CA con il template corretto.

Always On VPN (AOVPN): troubleshooting avanzato

Always On VPN è quello che Microsoft vuole farvi usare al posto di DirectAccess. E nel 2026, sempre più aziende stanno completando la migrazione — il che significa nuove categorie di ticket che arrivano all'helpdesk.

Come funziona AOVPN

A differenza di una VPN tradizionale che l'utente attiva manualmente, AOVPN stabilisce automaticamente un tunnel quando il dispositivo si connette a una rete esterna. Usa due tipi di tunnel:

  • Device Tunnel — si connette prima del login utente, usando certificati macchina. Protocollo obbligatorio: IKEv2
  • User Tunnel — si connette dopo il login, può usare IKEv2 o SSTP, supporta PEAP e EAP-TLS

Verificare lo stato di AOVPN

# Controllare la configurazione del tunnel dispositivo
Get-VpnConnection -AllUserConnection | Format-List *

# Controllare la configurazione del tunnel utente
Get-VpnConnection | Format-List *

# Verificare l'EKU filter del tunnel dispositivo
Get-VpnConnection -AllUserConnection -Name "NomeTunnel" | 
  Select-Object MachineCertificateEkuFilter

Analizzare i log eventi

I log eventi sono fondamentali per capire cosa sta succedendo con AOVPN. Cercate gli eventi sotto la sorgente RasClient:

# Visualizzare gli ultimi 20 eventi RasClient (errori e avvisi)
Get-WinEvent -FilterHashtable @{
  LogName = "Application"
  ProviderName = "RasClient"
  Level = 1,2,3
} -MaxEvents 20 | Format-Table TimeCreated, Id, Message -Wrap

# Visualizzare gli errori di accesso remoto dal log di sistema
Get-EventLog -LogName System -EntryType Error -Source RemoteAccess -Newest 10 | 
  Format-List TimeGenerated, EventID, Message

Problemi comuni AOVPN e soluzioni

Il tunnel dispositivo non si connette dopo il riavvio:

  • Verificate che il certificato macchina sia valido e abbia l'EKU "IP security IKE intermediate"
  • Controllate che il profilo VPN sia distribuito come "All Users" e non come profilo utente — questo è un errore più comune di quanto si pensi
  • Assicuratevi che il servizio RasMan sia impostato su avvio automatico

L'utente si connette ma non raggiunge le risorse interne:

Questo scenario è frustrante sia per l'utente che per il tecnico. La VPN risulta connessa, ma niente funziona.

  • Verificate le impostazioni di split tunneling vs full tunneling nel profilo VPN
  • Controllate le route statiche con Get-VpnConnection | Select-Object Routes
  • Verificate la risoluzione DNS interna con Resolve-DnsName server.dominio.local (non usate nslookup, che bypassa la NRPT — ne parliamo tra poco)

DNS e VPN: la causa nascosta di molti problemi

Ecco, questo è un argomento che mi sta particolarmente a cuore. Una delle cause più subdole dei problemi VPN è il DNS. Quando una VPN è attiva, Windows deve sapere quali query DNS mandare attraverso il tunnel e quali risolvere localmente. La Name Resolution Policy Table (NRPT) gestisce tutto questo, ma spesso è configurata male.

Diagnostica DNS su VPN

# IMPORTANTE: NON usare nslookup per testare la risoluzione DNS su VPN!
# nslookup bypassa la NRPT. Usare invece Resolve-DnsName
Resolve-DnsName -Name server.dominio.local -DnsOnly

# Visualizzare le policy NRPT attive
Get-DnsClientNrptPolicy

# Verificare le regole NRPT configurate
Get-DnsClientNrptRule | Format-Table Namespace, NameServers, DnsSecValidationRequired

# Controllare i server DNS assegnati a ciascuna interfaccia
Get-DnsClientServerAddress | Select-Object InterfaceAlias, ServerAddresses

Errore tipico che vedrete spesso: l'utente connesso in VPN non riesce a raggiungere un file server interno per nome, ma ci riesce per indirizzo IP. Questo è quasi sempre un problema DNS. Controllate che la NRPT includa il suffisso DNS del dominio aziendale e che punti ai server DNS interni.

Conflitto WireGuard su Windows 11 25H2

Se avete utenti che usano WireGuard su Windows 11 Enterprise 25H2, preparatevi a un problema piuttosto fastidioso emerso a inizio 2026. In pratica, WireGuard stabilisce la connessione (l'handshake va a buon fine), ma poi i dati non passano. Oppure appare un errore L2TP sulla connessione VPN integrata di Windows.

Sintomi

  • WireGuard mostra "Handshake completed" ma nessun traffico transita
  • Errore "The L2TP connection attempt failed because the security layer encountered a processing error"
  • Il tunnel risulta attivo nel firewall ma di fatto non funziona

Soluzioni

# Fix tramite registro — modificare le chiavi PolicyAgent e RasMan
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" `
  -Name "AssumeUDPEncapsulationContextOnSendRule" -Value 2

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\Parameters" `
  -Name "ProhibitIpSec" -Value 0

# Riavviare il computer dopo le modifiche al registro
Restart-Computer -Force

Se il problema persiste, verificate la configurazione WireGuard: provate a rimuovere l'indirizzo IP del client dalla riga AllowedIPs nel file di configurazione. Questo risolve un conflitto noto con i gateway UniFi/Ubiquiti — un dettaglio che non è documentato da nessuna parte, ma che abbiamo scoperto dopo ore di debug.

Firewall e antivirus: quando la sicurezza blocca la sicurezza

C'è un certo paradosso nell'IT: il software di sicurezza che blocca la connessione sicura. Succede più spesso di quanto vorreste, e la diagnosi non è sempre immediata.

Windows Defender Firewall

# Verificare se il firewall sta bloccando la VPN
Get-NetFirewallRule | Where-Object {
  ($_.DisplayName -like "*VPN*" -or $_.DisplayName -like "*Remote*") -and 
  $_.Action -eq "Block"
} | Select-Object DisplayName, Direction, Action, Enabled

# Aggiungere un'eccezione per il client VPN (esempio con GlobalProtect)
New-NetFirewallRule -DisplayName "Consenti VPN GlobalProtect" `
  -Direction Inbound -Program "C:\Program Files\Palo Alto Networks\GlobalProtect\PanGPA.exe" `
  -Action Allow -Profile Domain,Private,Public

Antivirus di terze parti

Se sospettate un conflitto con l'antivirus, il test più rapido (e lo so, non è elegante) è disattivarlo temporaneamente e provare la connessione VPN. Se funziona, avete trovato il colpevole. A quel punto configurate un'eccezione per:

  • L'eseguibile del client VPN
  • Le porte UDP 500 e 4500 (IKEv2)
  • La porta TCP 443 (SSTP)
  • Il protocollo ESP (IP Protocol 50)

Driver WAN Miniport: il colpevole silenzioso

I driver WAN Miniport sono adattatori virtuali di rete che Windows usa per le connessioni VPN. Se sono corrotti o obsoleti, la VPN semplicemente non funziona. Il problema? Il messaggio di errore non vi dirà mai che il driver è la causa.

Reinstallare i driver WAN Miniport

# Elencare gli adattatori WAN Miniport presenti
Get-NetAdapter -IncludeHidden | Where-Object {$_.InterfaceDescription -like "*WAN Miniport*"} | 
  Select-Object Name, InterfaceDescription, Status

# Per reinstallare, usare Device Manager (devmgmt.msc):
# 1. Espandere "Schede di rete"
# 2. Trovare i dispositivi WAN Miniport (IKEv2, IP, SSTP, ecc.)
# 3. Click destro > Disinstalla dispositivo
# 4. Menu Azione > Rileva modifiche hardware
# Windows reinstallerà automaticamente i driver corretti

Script di diagnostica VPN completo

Questo è lo script che uso con i tecnici L1 — raccoglie automaticamente tutte le informazioni utili per il troubleshooting e genera un report da allegare al ticket. Fatelo girare come amministratore e vi risparmierà un sacco di tempo.

# Script diagnostica VPN - Helpdesk L1
# Eseguire come Amministratore

$report = @()
$report += "=== REPORT DIAGNOSTICA VPN ==="
$report += "Data: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
$report += "Computer: $env:COMPUTERNAME"
$report += "Utente: $env:USERNAME"
$report += ""

# Versione Windows
$report += "--- VERSIONE WINDOWS ---"
$os = Get-CimInstance Win32_OperatingSystem
$report += "OS: $($os.Caption) Build $($os.BuildNumber)"
$report += ""

# Connessioni VPN configurate
$report += "--- CONNESSIONI VPN ---"
$vpns = Get-VpnConnection -ErrorAction SilentlyContinue
if ($vpns) {
    foreach ($vpn in $vpns) {
        $report += "Nome: $($vpn.Name)"
        $report += "Server: $($vpn.ServerAddress)"
        $report += "Protocollo: $($vpn.TunnelType)"
        $report += "Stato: $($vpn.ConnectionStatus)"
        $report += ""
    }
} else {
    $report += "Nessuna connessione VPN utente configurata"
}

# Connessioni AllUser (Device Tunnel)
$allUser = Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue
if ($allUser) {
    $report += "--- TUNNEL DISPOSITIVO ---"
    foreach ($vpn in $allUser) {
        $report += "Nome: $($vpn.Name)"
        $report += "Server: $($vpn.ServerAddress)"
        $report += "Stato: $($vpn.ConnectionStatus)"
    }
    $report += ""
}

# Servizi critici
$report += "--- SERVIZI VPN ---"
$services = @("RasMan", "IKEEXT", "PolicyAgent", "RasAuto")
foreach ($svc in $services) {
    $s = Get-Service -Name $svc -ErrorAction SilentlyContinue
    if ($s) {
        $report += "$($s.DisplayName): $($s.Status)"
    }
}
$report += ""

# Adattatori di rete
$report += "--- ADATTATORI DI RETE ---"
Get-NetAdapter | Where-Object {$_.Status -eq "Up"} | ForEach-Object {
    $report += "$($_.Name): $($_.InterfaceDescription) - $($_.Status)"
}
$report += ""

# DNS
$report += "--- CONFIGURAZIONE DNS ---"
Get-DnsClientServerAddress | Where-Object {$_.ServerAddresses} | ForEach-Object {
    $report += "$($_.InterfaceAlias): $($_.ServerAddresses -join ', ')"
}
$report += ""

# NRPT
$report += "--- POLICY NRPT ---"
$nrpt = Get-DnsClientNrptRule -ErrorAction SilentlyContinue
if ($nrpt) {
    $nrpt | ForEach-Object {
        $report += "Namespace: $($_.Namespace) -> DNS: $($_.NameServers -join ', ')"
    }
} else {
    $report += "Nessuna regola NRPT configurata"
}
$report += ""

# Certificati client VPN
$report += "--- CERTIFICATI VPN ---"
Get-ChildItem Cert:\LocalMachine\My -ErrorAction SilentlyContinue | ForEach-Object {
    $report += "Subject: $($_.Subject) | Scadenza: $($_.NotAfter) | Thumbprint: $($_.Thumbprint)"
}

# Salva report
$path = "$env:TEMP\VPN_Diagnostica_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
$report | Out-File -FilePath $path -Encoding UTF8
Write-Host "Report salvato in: $path" -ForegroundColor Green

Quando il problema è lato server: cosa chiedere al team infrastruttura

Non tutti i problemi VPN si risolvono dal client. Se avete fatto tutti i controlli e il problema persiste, è il momento di coinvolgere il team infrastruttura. Ecco le domande giuste da fare (e fidatevi, vi faranno risparmiare tempo):

  1. Il certificato del server VPN è scaduto? — È la prima cosa da controllare. I certificati scadono, e non sempre qualcuno se ne accorge
  2. Le policy NPS sono state modificate di recente? — Un cambio nelle policy di autenticazione può bloccare categorie intere di utenti da un giorno all'altro
  3. Il pool di indirizzi IP è esaurito? — Con lo smart working, il numero di connessioni simultanee è cresciuto. Se il pool è troppo piccolo, le nuove connessioni falliscono
  4. Ci sono stati aggiornamenti firmware sul firewall? — Gli aggiornamenti dei firewall perimetrali possono modificare le regole NAT-T senza che nessuno se ne accorga
  5. Il servizio RRAS è in esecuzione? — Sembra ovvio, ma verificare lo stato del servizio Routing and Remote Access sul server è sempre una buona idea

Domande frequenti

Perché la VPN si disconnette continuamente su Windows 11?

Le disconnessioni frequenti sono spesso causate dalla modalità risparmio energetico dell'adattatore di rete. Windows 11 può spegnere l'adattatore per risparmiare batteria, interrompendo il tunnel VPN. Per risolvere, andate in Gestione Dispositivi, trovate il vostro adattatore di rete, aprite le Proprietà e nella scheda Risparmio energia deselezionate "Consenti al computer di spegnere il dispositivo per risparmiare energia". Controllate anche che non ci siano aggiornamenti cumulativi problematici installati di recente.

Come si configura Always On VPN tramite Intune?

La configurazione passa attraverso il VPNv2 CSP (Configuration Service Provider). In Intune, create un profilo di configurazione dispositivo, selezionate il template VPN per Windows 10/11, specificate il tipo di connessione (IKEv2 o SSTP), il server VPN, il metodo di autenticazione EAP e abilitate l'opzione "Always On". Nel 2026, Microsoft consiglia la distribuzione tramite MDM come metodo principale per i deploy aziendali.

Perché nslookup funziona ma non riesco ad accedere alle risorse interne via VPN?

Questa è una trappola classica. nslookup bypassa la Name Resolution Policy Table (NRPT) e interroga direttamente il server DNS configurato sull'adattatore. Usate invece Resolve-DnsName in PowerShell, che rispetta le regole NRPT. Se Resolve-DnsName non risolve il nome interno, il problema è nella configurazione NRPT del profilo VPN, non nel DNS.

Devo migrare da PPTP a IKEv2: quali sono i passaggi principali?

La migrazione richiede: (1) una PKI aziendale per i certificati server e client, (2) la configurazione di IKEv2 sul server RRAS o firewall, (3) l'apertura delle porte UDP 500 e 4500 sul firewall perimetrale, (4) la distribuzione dei nuovi profili VPN ai client tramite Intune, GPO o script PowerShell, e (5) un periodo di coesistenza con entrambi i protocolli attivi. Pianificate almeno 2-4 settimane per la transizione — meglio non avere fretta con queste cose.

La VPN funziona su Wi-Fi ma non su rete cablata (o viceversa): cosa controllare?

Il problema è quasi sempre legato al profilo firewall di Windows. Le reti cablate e Wi-Fi possono essere classificate in profili diversi (Dominio, Privato, Pubblico). Verificate con Get-NetConnectionProfile il profilo assegnato a ciascuna interfaccia e assicuratevi che le regole firewall per la VPN siano abilitate per tutti i profili necessari. Un dettaglio che sfugge facilmente ma che fa la differenza.

Sull'Autore Editorial Team

Our team of expert writers and editors.

Articoli Correlati