All posts tagged workaround

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 Device Tunnel Issues with April 2024 Security Update

Always On VPN administrators may find that their device tunnel connections no longer connect automatically after applying the April 2024 security updates. The device tunnel connection is optional and only required under specific conditions, so end users may not be immediately impacted. However, administrators should be aware of this issue.

Note: The issues outlined in this post have been resolved with the May 14, 2024, security updates.

Error Messages

When manually establishing an Always On VPN device tunnel connection using rapshone.exe or rasdial.exe, you may receive one of the following error messages.

Rasphone.exe

Error 0x80070057: The parameter is incorrect.

Rasdial.exe

Connecting to <Name of Device Tunnel>…The parameter is incorrect.

Affected Devices

The issue affects all supported versions of Windows with an Always On VPN device tunnel connection configured to require a specific Enhanced Key Usage (EKU) OID. Administrators can run the following PowerShell command to identify this configuration.

Get-VpnConnection -AllUserConnection -Name <Name of Device Tunnel> | Select-Object MachineCertificateEkuFilter

If the output of this PowerShell command returns data, it is affected by this issue.

Workaround

To restore Always On VPN device tunnel functionality on devices with the April 2024 security updates installed, open an elevated PowerShell command window and run the following command.

Set-VpnConnection -AllUserConnection -Name ‘Always On VPN Device Tunnel’ -MachineCertificateEKUFilter $Null

After running this command, the output should now be blank.

Caveat

The problem with implementing the workaround described here is that you likely enabled this configuration to address an issue where the wrong certificate was selected for use with the device tunnel. In this case, the workaround may result in unexpected behavior and may not restore full functionality.

Known Issue Rollback

Currently, Microsoft is aware of the issue and is actively working to resolve it. If you are experiencing this issue, open a support case with Microsoft, and they will provide you with more information and possibly a private Known Issue Rollback (KIR). I will update this post as soon as Microsoft publishes a permanent fix.

Additional Information

Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Only Deployment Considerations

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

Leave a comment
by Richard M. Hicks on April 23, 2024  •  Permalink
Posted in Always On VPN, AOVPN, Certificate Authentication, certificates, device tunnel, Enterprise, enterprise mobility, IKEv2, Microsoft, Mobility, Operational Support, PowerShell, Remote Access, Security, Security Update, troubleshooting, Update, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on April 23, 2024

https://directaccess.richardhicks.com/2024/04/23/always-on-vpn-device-tunnel-issues-with-april-2024-security-update/

When Always On VPN Isn’t

Microsoft Always On VPN is a beautiful thing. VPN profiles are assigned to the user (and, optionally, their device). When users power up their device and log on, they are automatically connected to the corporate network and can access all the applications and data they need on-premises. Until recently, though, end users could disconnect the VPN. Why they would do this is beyond comprehension, but sadly, it happens all too often. When it does, it presents a problem for Always On VPN administrators because they must now rely on the user to re-enable this feature. And until they do, they often suffer productivity loss, and their devices may fall out of compliance.

Connect Automatically

When an Always On VPN profile is provisioned to a user (or a device), the VPN profile has the option to ‘Connect automatically’ enabled by default. Unfortunately, this setting is cleared if a user terminates the VPN.

This setting will remain cleared until the user rechecks the box to enable it. Until then, the VPN will no longer connect automatically.

Workarounds

Instead of relying on the grace of the end user to restore Always On functionality, administrators have a few options to correct this problem programmatically.

Intune Remediation

Administrators can use Intune Remediations to deploy a set of detection and remediation scripts I’ve published to update this setting. Now, administrators can enforce ‘Always On’ VPN connections with the assurance that if the user turns off this feature, it will be quickly re-enabled.

Detect-AutoTriggerDisabledProfile.ps1

Remediate-AutoTriggerDisabledProfile.ps1

SCCM

You can find a standalone version of this script here if you use System Center Configuration Manager (SCCM) or another systems management solution to manage your endpoints.

Clear-AutoTriggerDisabledProfile.ps1

AovpnTools

In addition, you will find the Clear-AutoTriggerDisabledProfile function is included in my AOVPNTools PowerShell module, which can be installed from the PowerShell gallery.

Install-Module -Name AOVPNTools -Force

Disable Disconnect Button

To avoid this pain in the future, Always On VPN administrators can prevent users from disconnecting the VPN using the UI by leveraging the DisableDisconnectButton option in ProfileXML. This setting is supported for both user and device tunnels on Windows 11 and later devices.

Additional Information

AOVPNTools PowerShell Module

AOVPNTools PowerShell Module on GitHub

Always On VPN and Intune Remediations

6 Comments
by Richard M. Hicks on January 15, 2024  •  Permalink
Posted in administration, Always On VPN, AOVPN, Compliance, Deployment, Device Management, device tunnel, Endpoint Manager, Enterprise, enterprise mobility, GitHub, InTune, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, Operational Support, PowerShell, ProfileXML, Remote Access, SCCM, Security, System Center Configuration Manager, systems management, troubleshooting, user tunnel, VPN, Windows 10, Windows 11, XML
Tagged , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 15, 2024

https://directaccess.richardhicks.com/2024/01/15/when-always-on-vpn-isnt/

« Older Posts