All posts in category Always On VPN

Always On VPN with PEAP Fails in Windows 11 26H1

Always On VPN RasMan Errors in Windows 10 1903

There appears to be a bug in the latest Windows 11 26H1 (no, that’s not a typo – 26H1) build affecting Protected Extensible Authentication Protocol (PEAP). In my testing, all VPN connection attempts (Always On VPN and manual/ad-hoc) failed when PEAP was used for authentication.

Windows 11 26H1

Recently, while reviewing downloads and product keys in Visual Studio, I noticed a new Windows 11 release listed: Windows 11 26H1 (business and consumer editions). I initially thought 26H1 would be ARM-only, but the download is available for x64 as well.

I’m not sure whether this is intended as a general release, because Microsoft describes it as an Insider Experimental Preview Build (28200.1873). I also don’t recall seeing Insider builds offered through Visual Studio downloads, so I’m not sure what to make of it. Either way, if you’re evaluating this build, the notes below document a VPN issue I was able to reproduce.

Troubleshooting

After preparing a Windows 11 26H1 test client, I found that the Always On VPN user tunnel would not connect. The same configuration worked on earlier Windows 11 versions. In the event log, I observed the following errors.

Error 619

When using SSTP, the event log records error code 619 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 619.

Error 691

When using IKEv2, the event log records error code 691 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 691.

Workaround

At the time of writing, the only workaround I’ve found to restore Always On VPN connectivity is to switch authentication from PEAP to EAP-TLS. This may not be a drop-in change for every environment, so evaluate the security and operational impact before rolling it out broadly. You’ll need to enable EAP-TLS on both the client and the NPS/RADIUS server.

Summary

I’m not convinced Windows 11 26H1 will be widely deployed soon, since it appears to be an experimental/Insider build rather than a general release. If you decide to evaluate it, plan to use the workaround above to maintain Always On VPN connectivity.

Feedback

Have you tested Always On VPN with Windows 11 26H1? If so, do you see the same behavior? Share your findings in the comments.

Additional Information

Windows 11 Insider Experimental (26H1) Preview Build 28200.1873

Leave a comment
by Richard M. Hicks on April 27, 2026  •  Permalink
Posted in Always On VPN, AOVPN, authentication, EAP, EAP-TLS, Microsoft, PEAP, user tunnel, VPN, Windows 11
Tagged , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on April 27, 2026

https://directaccess.richardhicks.com/2026/04/27/always-on-vpn-with-peap-fails-in-windows-11-26h1/

Always On VPN IKEv2 Security Vulnerability April 2026

Microsoft published its Security Updates for April 2026 today, and the good news is that there are no Windows Server Routing and Remote Access (RRAS) vulnerabilities this month. However, they disclosed a critical remote code execution (RCE) vulnerability that impacts deployments using Internet Key Exchange version 2 (IKEv2).

IKE Service Extensions RCE

CVE-2026-33824 addresses a security vulnerability in the Windows Internet Key Exchange (IKE) Service Extensions. This vulnerability is a Remote Code Execution (RCE) vulnerability, with a CVSS 3.1 base score of 9.8 (Critical). Always On VPN implementations that use the device tunnel or IKEv2 for the user tunnel are affected.

Impact

This vulnerability presents a unique challenge to Always On VPN administrators as IKEv2 is required to support device tunnel connections. Some implementations also use IKEv2 for the user tunnel. In either case, the vulnerable VPN server, often domain-joined, is reachable from the Internet, greatly increasing the attack surface and exposure to this vulnerability.

Recommendations

For deployments that use IKEv2 (device or user tunnel), administrators should update their RRAS server as soon as possible to protect against potential attacks on this service.

Not Using IKEv2?

If you are not using the device tunnel or IKEv2 for the user tunnel, ensure the following IKEv2 ports are blocked at the edge firewall.

  • Inbound UDP port 500 (IKE)
  • Inbound UDP port 4500 (IKE NAT-T)

In addition, consider disabling IKEv2 on the RRAS server by opening an elevated command window and running the following command.

netsh.exe ras set wanports device = "WAN Miniport (IKEv2)" rasinonly = disabled ddinout = disabled ddoutonly = disabled maxports = 0

Optionally, you can use the Routing and Remote Access management console (rrasmgnt.msc) to perform this task.

  1. Right-click on Ports and choose Properties.
  2. Select WAN Miniport (IKEv2).
  3. Click Configure.
  4. Uncheck Remote access connections (inbound only).
  5. Uncheck Demand-dial routing connection (inbound and outbound).
  6. Enter 0 in the Maximum ports field.
  7. Click Ok.

Additional Information

Microsoft Security Updates for April 2026

CVE-2026-33824 – Windows Internet Key Exchange (IKE) Service Extension RCE

1 Comment
by Richard M. Hicks on April 14, 2026  •  Permalink
Posted in Always On VPN, AOVPN, CVE, device tunnel, Enterprise, enterprise mobility, IKEv2, Infrastructure, Microsoft, Patch Tuesday, RCE, Remote Access, routing and remote access service, RRAS, Security, Security Update, Update, user tunnel, VPN, Vulnerability, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , , , , , ,

Posted by Richard M. Hicks on April 14, 2026

https://directaccess.richardhicks.com/2026/04/14/always-on-vpn-ikev2-security-vulnerability-april-2026/

Entra Private Access and VPN Migration Strategies on Entra.News

I recently had the opportunity to connect with Merill Fernando from Microsoft as a guest on his popular Entra.News podcast to discuss Microsoft Entra Private Access, which is part of the Entra Global Secure Access Security Service Edge (SSE) service. We spent the hour talking about the similarities and differences between classic VPN technologies and zero-trust network access (ZTNA). In addition, we discussed some technical aspects of Entra Private Access, and I shared migration and coexistence strategies to help ease the transition to zero trust. Also, we discussed the importance of integrating Entra Conditional Access and the shift from network to application access. You’ll find the interview at Entra.News and also on YouTube. Enjoy!

Additional Information

How to Migrate from Legacy VPN to Entra Private Access – Entra.News

Microsoft Entra Private Access

Always On VPN vs. Entra Private Access

Microsoft Entra Private Access Network Connector Overview and Deployment Strategies

Microsoft Entra Private Access Intelligent Local Access

Leave a comment
by Richard M. Hicks on March 17, 2026  •  Permalink
Posted in Always On VPN, AOVPN, Entra, Entra Conditional Access, Entra Global Secure Access, Entra ID, Entra Private Access, Entra Private Network Connector, Global Secure Access, GSA, Microsoft, Microsoft Entra, Microsoft Entra Global Secure Access, Microsoft Entra Private Access, migration, Private Network Connector, SASE, Secure Service Edge, Security, Security Service Edge, SSE, video, VPN, Windows 10, Windows 11, Zero Trust, Zero Trust Network Access, ZTNA
Tagged , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 17, 2026

https://directaccess.richardhicks.com/2026/03/17/entra-private-access-and-vpn-migration-strategies-on-entra-news/

« Older Posts