Always On VPN bloccata su “Connessione in corso” in Windows 11: KB5127648 non basta

Articolo aggiornato al 22 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Microsoft rilascia nuove correzioni.

Gli utenti in smart working accendono il portatile, la VPN aziendale resta ferma su “Connessione in corso” e non va oltre. Se provano a disconnettere e riconnettere, compare l’errore “The specified port is already in use” (nella versione italiana di Windows, un messaggio che dice che la porta è già in uso). Il server VPN funziona, gli altri client si collegano, eppure quei PC restano fuori.

È il bug di Always On VPN introdotto dagli aggiornamenti di sicurezza di settembre 2026 per Windows 11. Microsoft lo aveva segnato come risolto con il Patch Tuesday di ottobre (KB5127648), ma in questi giorni ha fatto marcia indietro: lo stato era stato cambiato in Resolved per errore ed è tornato Mitigated. In pratica chi ha installato gli update di ottobre aspettandosi la correzione si ritrova con lo stesso problema, e il workaround va tenuto in piedi ancora per qualche settimana.

Chi è coinvolto

Il problema riguarda i client Windows 11 che usano Always On VPN con selezione automatica del protocollo, cioè profili che tentano un protocollo (per esempio IKEv2) e, se fallisce, ripiegano sull’altro (SSTP). Gli aggiornamenti di origine indicati da Microsoft sono:

• Windows 11 24H2 e 25H2: KB5124008 (aggiornamento di sicurezza di settembre 2026);
• Windows 11 26H1: KB5124012;
• gli update successivi, compreso KB5127648 di ottobre per 24H2, 25H2 e 26H2, che non contengono la correzione.

Se il vostro profilo usa un solo protocollo fisso non siete toccati. Lo stesso vale per chi usa client VPN di terze parti (FortiClient, GlobalProtect, WireGuard e simili), che non passano per questo meccanismo di Windows. Nelle PMI Always On VPN si trova soprattutto dove c’è un RRAS su Windows Server e i profili vengono distribuiti con Intune: è lì che conviene controllare.

Perché succede

Microsoft spiega che il problema si presenta quando la VPN è configurata per tentare automaticamente un altro metodo di connessione se il primo fallisce. La causa tecnica precisa non è stata documentata; il comportamento fa pensare che il primo tentativo fallito lasci qualcosa in sospeso e che i successivi si scontrino con quello, da cui l’errore sulla porta. Il punto pratico però è chiaro: togliendo il fallback il problema sparisce.

Microsoft ha comunicato che la correzione arriverà “in an update to be released in the coming weeks”, senza una data precisa. Chi ha accesso all’interfaccia di amministrazione di Microsoft 365 trova l’avviso nell’integrità dei servizi con il codice WI1482218.

Prima di iniziare

• Verificate su un PC colpito il tipo di tunnel configurato, da PowerShell come amministratore:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

• Se TunnelType vale Automatic e i sintomi corrispondono, siete nel caso giusto. Automatic da solo non basta a dire che il problema è questo.
• Capite quale protocollo regge davvero la vostra infrastruttura: IKEv2 richiede che le porte UDP 500 e 4500 arrivino al server, SSTP passa su TCP 443. Controllate i log del server RRAS o del firewall per vedere con cosa si collegano oggi i client.
• Esportate il profilo attuale da Intune o salvate una copia del ProfileXML, così da poter tornare indietro in un attimo quando arriverà la patch.

La soluzione: un solo protocollo nel profilo

Il workaround ufficiale è passare da selezione automatica a un solo protocollo, SSTP oppure IKEv2. La scelta dipende dalla vostra rete. Io, per gli utenti che si collegano da hotel, reti ospiti e hotspot del telefono, preferisco SSTP: passando su 443 attraversa quasi tutti i firewall, a costo di prestazioni un po’ inferiori. IKEv2 è più efficiente, ma dove UDP 500/4500 è filtrato l’utente resta fuori, e senza fallback non ha alternative.

Per i profili gestiti da Intune:

1. Aprite l’interfaccia di amministrazione di Intune → Dispositivi → Configurazione e selezionate il profilo VPN.
2. In Proprietà → Impostazioni di configurazione cambiate il tipo di connessione da Automatico a IKEv2 oppure a SSTP, a seconda delle opzioni disponibili per il vostro tipo di profilo.
3. Assegnate la modifica prima a un gruppo pilota di due o tre utenti, poi al resto.

Se distribuite il profilo con un ProfileXML personalizzato, la riga da cambiare è il NativeProtocolType:

<!-- prima -->
<NativeProtocolType>Automatic</NativeProtocolType>

<!-- dopo: solo SSTP (tunnel utente) -->
<NativeProtocolType>SSTP</NativeProtocolType>

<!-- oppure: solo IKEv2 -->
<NativeProtocolType>IKEv2</NativeProtocolType>

Attenzione: il device tunnel di Always On VPN supporta solo IKEv2, quindi l’opzione SSTP vale soltanto per il tunnel utente.

Per una prova veloce su un singolo PC, prima di toccare la configurazione centrale, potete forzare il protocollo da PowerShell (il nome della connessione è quello restituito da Get-VpnConnection):

Set-VpnConnection -Name "VPN DOMINIO" -TunnelType Sstp
Get-VpnConnection -Name "VPN DOMINIO" | Select-Object Name, TunnelType

Attenzione: su un profilo gestito da Intune questa modifica locale può essere sovrascritta alla sincronizzazione successiva. Serve solo per confermare la diagnosi; la correzione vera va fatta nel profilo distribuito.

Dopo la modifica scollegate la VPN, riavviate il PC e verificate che la connessione si completi, che le risorse interne (per esempio \\SRV01\condivisa) siano raggiungibili e che l’errore sulla porta non ricompaia.

Se il problema persiste

Se dopo il cambio di protocollo la connessione resta ancora appesa, controllate che il profilo sia stato davvero applicato (in Intune lo stato di distribuzione del dispositivo, sul PC di nuovo Get-VpnConnection) e che il protocollo scelto sia effettivamente raggiungibile da quella rete: un utente su un Wi-Fi ospite che blocca UDP non si collegherà mai in IKEv2.

Come ultima risorsa resta la disinstallazione dell’aggiornamento cumulativo (Impostazioni → Windows Update → Cronologia aggiornamenti → Disinstalla aggiornamenti). Lo sconsiglio: con gli update di ottobre dovreste togliere anche le correzioni di sicurezza del mese, e su un portatile che gira fuori dall’ufficio è un rischio peggiore di una VPN a protocollo fisso.

Quando Microsoft rilascerà la correzione definitiva, ripristinate il profilo esportato e tornate alla selezione automatica, sempre prima su un gruppo pilota. Non è l’unico problema di rete di questo ciclo di aggiornamenti: se avete anche Wi-Fi aziendali che non si collegano, guardate l’articolo su Wi-Fi 802.1X e KB5127648.

Vi è capitato di trovare utenti bloccati su “Connessione in corso” dopo gli aggiornamenti di settembre o ottobre? Raccontate nei commenti quale protocollo avete scelto e come si è comportato: possono essere utili ad altri.