Always On VPN fails after installing KB5124008 on Windows 11

Question

Hello,

We are experiencing an issue with Always On VPN after installing the September 2026 Windows 11 security update KB5124008.

Environment

• Windows 11 clients (24H2/25H2)
• Always On VPN
• Certificate-based authentication
• RRAS + NPS on Windows Server 2019
• Microsoft Intune deployed VPN profile

Issue

After installing KB5124008, Always On VPN stops working.

Troubleshooting performed

We have been able to reproduce the issue consistently:

1. Always On VPN works normally before installing KB5124008.
2. Install KB5124008.
3. Always On VPN no longer connects/functions correctly.
4. Uninstall KB5124008.
5. Reboot the device.
6. Always On VPN works again immediately.

The behavior has been reproduced on multiple client devices.Hello,

We are experiencing an issue with Always On VPN after installing the September 2026 Windows 11 security update KB5124008.

Environment

• Windows 11 clients (24H2/25H2)
• Always On VPN
• Certificate-based authentication
• RRAS + NPS on Windows Server 2019
• Microsoft Intune deployed VPN profile

Issue

After installing KB5124008, Always On VPN stops working.

Troubleshooting performed

We have been able to reproduce the issue consistently:

1. Always On VPN works normally before installing KB5124008.
2. Install KB5124008.
3. Always On VPN no longer connects/functions correctly.
4. Uninstall KB5124008.
5. Reboot the device.
6. Always On VPN works again immediately.

The behavior has been reproduced on multiple client devices.

We stopped to rollout KB5124008

Answer 1

Hello,

what you are seeing with KB5124008 is consistent with a regression introduced in the September 2026 cumulative update. The fact that Always On VPN with certificate‑based authentication works normally before the patch, fails immediately after installation, and recovers once the update is removed, strongly indicates that the update has altered the networking stack or IPsec certificate handling. This is not a configuration error on your side, but a compatibility issue introduced by the patch.

The correct way to handle this until Microsoft publishes a hotfix is to block deployment of KB5124008 across your environment, which you have already done. In parallel, you should open a support case with Microsoft Premier or Unified Support referencing Always On VPN regression after KB5124008, and provide them with logs from rasphone.pbk, eventvwr.msc under Applications and Services Logs > Microsoft > Windows > RasClient, and NPS server logs. These will confirm that the VPN client fails at the certificate negotiation stage.

If you need to keep the patch for security compliance but still maintain VPN connectivity, one workaround is to temporarily switch affected profiles to EAP‑TLS authentication via Intune, which may bypass the broken certificate chain validation path. However, this is only a stopgap and not guaranteed to be stable. The long‑term resolution will be an updated cumulative patch or hotfix from Microsoft that restores Always On VPN functionality with certificate‑based authentication.

In short, the safest immediate action is to hold KB5124008 in WSUS/Intune until Microsoft releases a corrected build. Keep your RRAS/NPS servers fully patched, but defer this client update. Document the regression and escalate through Microsoft support channels to ensure your case is linked to the broader issue report.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo

Answer 2

Same symptom here (Win 11 24H2, KB5124008, RRAS/NPS on Server 2019, Intune user tunnel, PEAP/EAP-TLS). In our case it is not a certificate-handling regression – it is the IKEv2 → SSTP fallback in an "Automatic" profile (VpnStrategy 14, IKEv2 then SSTP).

With KB5124008, IKEv2 with certificate/EAP auth works end-to-end, and an SSTP-only profile works as well. What no longer works is the automatic transition to SSTP when the IKEv2 attempt fails: before the update RasClient showed 20223 (IKEv2) → 20222 (SSTP) → 20225 within a second; after the update the SSTP attempt never happens and the client reports "connected" without a tunnel.

So environments that were silently running on the SSTP fallback lose VPN after KB5124008. Fixing the IKEv2 leg restores service, as does switching the profile to SSTP-only. Blocking the update was not necessary for us.

Answer 3

We had the same problem here - after installing the September update (KB5124008), the AlwaysOn VPN user tunnel could no longer connect, displaying the error message “The port is already opened.” However, installing the subsequent out-of-band update KB5129195 resolved this issue. With this patch, AlwaysOn is working properly again (device tunnel + user tunnel)—on both 24H2 and 25H2 builds.

Answer 4

We have to switch to only sstp from IkeV2, and failover to sstp on usertunel (ForceTunnel). Devicetunnel with Ikev2 i working fine. When both tunnel is using ikev2 the second connecting says port is already in use.

Answer 5

We have no problem in our deployment but only user tunnel in place, maybe it helps someone

and we use https://github.com/ld0614/DPC for profile management, attached is a sample profile