Windows 11 Always On VPN Fix: Stop VPN Connections Getting Stuck
Microsoft confirmed a September 2026 Windows 11 issue affecting Always On VPN profiles that automatically switch between IKEv2 and SSTP. Here is the documented workaround.
On this page
If an organization's Always On VPN connection suddenly stays on “Connecting” after the September 2026 Windows 11 update, the problem may not be the VPN server or the user's credentials. Microsoft has confirmed an issue affecting Windows 11 24H2, 25H2, and 26H1 when an Always On VPN profile is configured to automatically switch between tunneling protocols. The immediate workaround is to stop automatic protocol selection and configure the profile to use either IKEv2 or SSTP, depending on the organization's setup.
Why the Windows 11 Always On VPN fix is needed
Always On VPN is Microsoft's enterprise remote-access technology for automatically establishing a secure connection between a Windows device and a corporate network. Unlike a VPN that a user starts manually, the connection can be configured to establish in the background, which makes it useful for remote employees who need access to internal resources without remembering to start a VPN application. The September problem affects a narrower configuration: profiles that can automatically try another tunneling method when the first one fails. Microsoft specifically gives automatic protocol selection between IKEv2 and SSTP as an example.
The affected Windows releases are Windows 11 24H2 and 25H2 with KB5124008, and Windows 11 26H1 with KB5124012. Microsoft lists KB5124008 as the September 8 security update for Windows 11 24H2, while its Windows 11 release information lists KB5124012 as the corresponding September security update for 26H1. The issue therefore does not mean every Windows 11 VPN installation is broken; the profile configuration is a key part of the failure.
Check the VPN symptoms before changing anything
The easiest way to distinguish this problem from a general VPN outage is to look at what happens during connection attempts. Microsoft says affected connections can remain stuck in the “Connecting” state or repeatedly try to connect without completing. A later attempt may also report “The specified port is already in use,” which can misleadingly suggest a local port conflict even though the underlying problem is the automatic protocol-selection path.
Check whether the problem started after the September Windows update and whether the affected machines use an Always On VPN profile rather than a conventional VPN application. If only users on the updated Windows clients are affected while the VPN infrastructure continues to serve other clients normally, that comparison is useful evidence. Do not assume that uninstalling the security update is necessary simply because the timing matches; first determine whether the affected profile actually uses automatic protocol selection.
Find out which Windows update is installed
On an affected client, press Windows + R, type winver, and press Enter. You can also open Windows Settings and check the installed update history. For Windows 11 24H2 and 25H2, Microsoft's September security update is KB5124008; for Windows 11 26H1, the corresponding update is KB5124012. Microsoft lists these as the originating updates for the Always On VPN problem.
This check matters because several other Windows 11 problems were also associated with the September servicing cycle, including Remote Desktop Services failures, USB audio problems, and Hyper-V folder-sharing failures. Some of those issues received the out-of-band KB5129195 update, but that does not mean every September update regression has been eliminated. Treat the VPN problem as its own configuration-specific issue rather than assuming that installing another cumulative update automatically changes the VPN behavior.
Change Always On VPN from automatic selection to one protocol
Microsoft's temporary mitigation is straightforward in principle: remove automatic protocol selection from the affected Always On VPN profile and select one tunneling protocol. The two choices Microsoft identifies are IKEv2, Internet Key Exchange version 2, and SSTP, Secure Socket Tunneling Protocol. The correct choice depends on how the organization's VPN infrastructure is configured, so there is no universal instruction to choose one over the other.
- Open the management system your organization uses to deploy Always On VPN profiles.
- Locate the affected Always On VPN profile.
- Find the setting responsible for automatic protocol selection or automatic fallback between tunneling methods.
- Change the profile so that it uses IKEv2 only or SSTP only.
- Deploy the modified profile to a test device before applying the change across the organization.
- Confirm that the VPN establishes a connection and that the user can reach the internal resources normally available through the tunnel.
The important part is the fourth step, not a particular management console. Microsoft does not prescribe one deployment tool for this workaround because organizations can manage Always On VPN profiles through different enterprise-management systems. The protocol should be selected according to the organization's existing VPN infrastructure, security requirements, and deployment configuration.
Test IKEv2 and SSTP instead of changing both at once
If the organization supports both protocols, test the protocol already known to work reliably in that environment rather than making an arbitrary choice. IKEv2 is one of the modern tunneling protocols supported by Always On VPN, while SSTP provides a different connection path. The Windows update problem is specifically associated with automatically moving between connection methods, so the workaround removes that fallback decision from the connection process.
Run the test with a small group first. Have an affected device restart or refresh its VPN configuration, establish the tunnel, and then test the applications that require corporate connectivity. Test from an external network as well if the VPN is primarily used by remote employees. A successful VPN connection alone is not enough if internal DNS, file shares, business applications, or other required services cannot be reached through the selected protocol.
Why uninstalling the Windows update is not the first fix
Removing KB5124008 or KB5124012 may appear attractive because the VPN problem began after those updates, but doing so also removes the security and quality changes delivered by the monthly update. The documented Microsoft workaround does not require administrators to remove the Windows update; instead, it changes the affected VPN profile so the problematic automatic protocol-selection behavior is avoided.
That distinction is particularly relevant for managed computers. A temporary profile change can be tested, documented, and rolled back when Microsoft releases a permanent correction. Removing a security update across an enterprise creates a different operational decision because administrators then have to account for the security fixes that are no longer installed. If the VPN profile workaround restores connectivity, keeping the Windows security update installed avoids solving one operational problem by creating another.
Do not confuse this with every VPN failure after September updates
The Microsoft-documented issue is specific to Always On VPN and automatic connection-method fallback. A manually launched consumer VPN client, a VPN profile that uses only one protocol, or a server-side VPN outage can produce similar symptoms without being caused by this Windows 11 regression. Microsoft's affected-platform list for this issue names Windows 11 24H2, 25H2, and 26H1, with KB5124008 and KB5124012 as the originating updates.
This also separates the VPN problem from other September Windows failures. Microsoft's release-health documentation records separate issues involving Remote Desktop Services, USB Audio Class 1.0 devices, domain trust, and Hyper-V-based Linux folder sharing. Some of those have already been resolved or mitigated through later servicing, so applying a fix intended for one symptom to another can make troubleshooting harder rather than easier.
What administrators should monitor next
Microsoft says it is working on a permanent fix for the Always On VPN issue and has provided the single-protocol configuration as the temporary mitigation. That means administrators should treat the profile change as an interim measure rather than redesigning the organization's VPN architecture around it. Keep a record of which protocol was selected, which Windows builds were affected, and which devices were changed so the temporary configuration can be revisited when Microsoft publishes the resolution.
The useful test is simple: an affected Windows 11 client should no longer depend on automatic fallback between IKEv2 and SSTP, and the resulting tunnel should stay connected long enough for normal corporate applications and services to work. If that restores access, the evidence fits Microsoft's documented issue. If it does not, the next investigation should move back toward the VPN server, authentication, certificates, network path, or client configuration instead of assuming every connection failure comes from the September Windows update.
Written by
