Always On VPN stuck connecting? Check IKEv2–SSTP fallback
Diagnose Windows Always On VPN fallback failures, check the corrected October 2026 patch status, and try a reversible single-protocol workaround.

If Windows Always On VPN stays at Connecting after a failed attempt, or the next attempt says “The specified port is already in use,” check whether the profile uses automatic protocol selection or fallback. These are reported symptoms of the September 2026 Windows 11 regression—not proof that every VPN connection failure has the same cause. BleepingComputer’s updated report describes the affected configuration.
Status as of October 24, 2026: do not treat KB5127648 or KB5127646 as the fallback fix. Microsoft’s October 20 change logs removed the earlier fix claim and say the change will arrive in a future release. See the corrected notes for KB5127648 and KB5127646.
The temporary workaround is to use one supported protocol—IKEv2 only or SSTP only—instead of fallback. On a work-managed computer, ask IT to make that change; do not delete the corporate VPN profile or weaken its authentication settings.
1. Check that this is the right failure
Record three things before changing anything:
- Run
winverand note the Windows version and OS build. The reported regression affects Windows 11 24H2 and later after the September 2026 security updates. - Note whether the first attempt fails and later attempts hang or produce the port-in-use message.
- Ask IT whether this is a user tunnel or device tunnel, and whether the deployed profile uses automatic selection or an explicit protocol list.
The tunnel distinction matters: Microsoft supports IKEv2 and SSTP for the user tunnel, but the device tunnel supports IKEv2 only, with no SSTP fallback. Do not convert a device tunnel to SSTP. Microsoft’s Always On VPN overview documents that boundary.
If the VPN already says Connected but websites or internal resources do not load, start with the connected-but-no-internet checks instead. That is a different symptom from failure to establish the tunnel.
2. Inspect the profile without changing it
For the native Windows VPN client, open Windows PowerShell and run:
Get-VpnConnection |
Select-Object Name, TunnelType, ConnectionStatus, AllUserConnection
Get-VpnConnection -AllUserConnection |
Select-Object Name, TunnelType, ConnectionStatus, AllUserConnection
The first command reads the current user’s phone book; the second reads the global phone book. Microsoft’s Get-VpnConnection reference explains both scopes.
Interpretation: Automatic is a reason to investigate fallback, not confirmation of the regression. If you cannot find the profile, or it is centrally deployed, have IT inspect the original configuration. The deployed NativeProtocolType may be Automatic or ProtocolList; a protocol list defines an ordered set of protocols. Microsoft’s VPNv2 documentation describes these settings.
3. Pin the user tunnel to one supported protocol
Microsoft’s temporary mitigation, quoted in the updated connection-issue report, is SSTP-only or IKEv2-only according to the deployment’s requirements.
Choose a protocol that the VPN gateway and existing authentication configuration support:
- IKEv2-only: appropriate when IT confirms IKEv2 works on the networks you use. Removing SSTP fallback also removes the alternate path intended for some firewall or proxy environments.
- SSTP-only: an option for a user tunnel when IT confirms the gateway supports SSTP. It is not an option for a device tunnel.
Neither is universally better. The immediate trade-off is avoiding the failing fallback path while losing automatic protocol redundancy. Microsoft documents fallback as a way to accommodate clients behind firewalls or proxies in its Always On VPN overview.
Local test, only if IT permits it
For a locally controlled, current-user native user-tunnel profile using Automatic, disconnect it and inspect its settings:
$vpnName = Read-Host "Enter the exact VPN profile name"
Get-VpnConnection -Name $vpnName |
Select-Object Name, TunnelType, AuthenticationMethod, SplitTunneling
Record the output before proceeding. If the read fails, or IT confirms the profile uses ProtocolList, stop and have IT handle the deployment instead. Then, if IKEv2 is approved and supported, run:
Set-VpnConnection -Name $vpnName -TunnelType Ikev2 -PassThru
Use Sstp instead of Ikev2 only if SSTP is approved and supported. For a global user-tunnel profile, IT should use an elevated PowerShell session and add -AllUserConnection to both the read and change commands. The Set-VpnConnection reference documents the tunnel-type and scope parameters.
For Intune, MDM or ProfileXML deployments, IT should preserve the original profile and change the authoritative configuration to a single NativeProtocolType value, IKEv2 or SSTP, rather than retaining the fallback configuration. Microsoft recommends redeploying the complete profile for VPNv2 changes. Do not manually delete your managed connection. VPNv2 configuration guidance
Leave certificates, authentication, encryption, DNS and routing unchanged during this test.
4. Reconnect, then interpret the result
Test a fresh connection on the same network and open an approved internal resource.
- Single protocol works: keep the approved mitigation while IT checks for a confirmed repair. Success is consistent with a fallback problem, but does not prove the update regression caused it.
- Single protocol still fails: record the exact error. In Event Viewer, check Windows Logs → Application for RasClient events around the attempt. Microsoft identifies these as useful client-side VPN logs; IT can correlate them with NPS logs where NPS is used. Always On VPN troubleshooting
- Failure changes to authentication errors: investigate authentication separately. KB5127648 also documents an NTLMv1-related change that might affect MS-CHAPv2-based VPN connections when Credential Guard is disabled and the
BlockNtlmv1SSOregistry value is not set. Do not disable security protections as a fallback workaround. KB5127648 release notes
To undo the local Automatic-profile test, disconnect and run:
Set-VpnConnection -Name $vpnName -TunnelType Automatic -PassThru
Use the same profile scope as before, including -AllUserConnection if applicable. For managed or protocol-list profiles, have IT restore the saved deployment configuration. Restoring Automatic re-enables the potentially failing fallback path; restore it after a confirmed repair and testing, or when ending an unsuccessful test—not merely because an October update is installed.
Send IT the Windows build, update history, tunnel type, original protocol configuration, error and timestamp, and the single-protocol test result. Remove usernames, internal hostnames and addresses before sharing logs outside your organization.