Always On VPN fails after installing KB5124008 on Windows 11

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

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.

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.

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