Always On VPN administrators migrating their endpoints to Windows 11 may encounter a scenario where Always On VPN randomly disconnects when the VPN profile is deployed using Microsoft Intune. The same configuration deployed to Windows 10 devices works reliably, however. In addition, Always On VPN profiles deployed using PowerShell (natively or with SCCM) or Dynamic Profile Configurator (DPC) do not experience this problem.
Troubleshooting
Administrators troubleshooting this issue will find the root cause is associated with the Always On VPN profiles being removed and replaced each time the device syncs with Intune. This occurs even if there are no changes to the configuration. Removing and replacing the Always On VPN profiles on each device sync is unnecessary, of course, but is also highly disruptive to connected users.
Intune and XML
The Intune team identified the issue, and a fix was made available in the August update. However, many of you have reported the issue persists with some Windows 11 clients after installing the latest updates. Further investigation indicates that although the issue has been resolved when using Intune and the native VPN device configuration profile template, the problem still occurs when using the Custom device configuration template.
Workaround
Microsoft is aware of the issues with deploying Always On VPN client configuration settings using XML in Intune, but there’s no indication when or if they will fix it. Until then, administrators have two options to address this problem.
Native VPN Template
When deploying Always On VPN client configuration settings to Windows 11 endpoints, use the native VPN device configuration template, as shown here.
Using the native VPN template does have some limitations, however. The following settings are not exposed using the native VPN template and can only be configured using XML.
- Disable class-based default route
- Application-specific traffic filters
- IPv6 routes (UI doesn’t allow /64 prefix!)
- Exclusion routes
- VPN protocol preferences
XML
If you must use XML, I’ve had some success by ensuring the order and syntax of XML settings is exactly as Intune expects. Follow the steps below to confirm the XML settings order in your XML configuration file.
- Deploy your XML file with Intune.
- Run Get-VpnClientProfileXML.ps1 to extract the deployed XML settings.
- Compare the order of settings to your existing XML.
- Compare the syntax of all settings. For example, the <Servers> section should list the server FQDN twice, separated by a semi-colon.
- Make changes to ensure all settings in your XML are in the same order as the extracted XML.
- Publish a new XML configuration file using Intune and test.
I’ll caution you that this workaround doesn’t always work reliably. Some customers report that this solved their problems entirely, while others have indicated it does not. My testing shows the same results. Let us know in the comments below if this works for you!
Reference XML
I have published an Always On VPN XML configuration file on GitHub for reference. It includes all common settings using the order and syntax required to ensure reliable operation. As a reminder, the sample file includes many settings that aren’t required. It is published as guidance for reference only.
Joe Bartlett
/ March 15, 2024Hi Richard,
Thanks for writing this article, it’s really helpful (as usual). I thought I was doing something silly with my configuration, so it’s good to know it’s just a bug.
I’ve tried using the Get-VpnClientProfileXML.ps1 script to mirror the configuration on a device in Intune, but unfortunately this doesn’t seem to have helped.
We really need some of the features not available in the Intune template so would prefer to use custom XML if at all possible.
I was wondering if you, or anyone else reading this comment, had any other tips or experiences from the last few months that you might be able to share? Or perhaps some news from MS as to when the bug might be properly fixed?
Thanks again,
Joe
Richard M. Hicks
/ March 15, 2024Hi Joe. Unfortunately, the order and syntax for XML in Windows 11 is more strict than previous versions of Windows. If you’ll reach out to me directly, I’d be happy to review your configuration file and offer any suggestions that might help.
Alex
/ April 8, 2024Hi Richard, i cant leave a commet, “nonce verification failed” mabe over the reply function.
Did you encounter a problem, that the user tunnel doesn’t connect autmatically under windows 11? Currently we are upgrading to Win 11 (22H2) and after that upgrade or reinstall, many users have the problem not to get connected automatically. I enclose the problem, the device tunnel doesnt come up and then the user tunnel can’t connect (after rasdial device tunnel, the user tunnel comes up automatic). There is no Eventlog (RasClient) error, the client just dont notice that there is an internet connection, maybe something with the nlasvc but my client, win 11, always connects automatically. the ncsi log shows no internet connection, but we can’t find out why. LAN or WLAN doesnt matter.
HOpe you have some hints for us.
Thanks
Alex
Richard M. Hicks
/ April 8, 2024Sorry about that error message. It’s related to caching somehow. If you perform a hard refresh (Ctrl-F5) it should work after that.
I’ve heard many reports about Always On VPN connections not connecting automatically after upgrading to Windows 11. I’ve had customers report success after removing and replacing the VPN profiles post upgrade. Also, as you indicated, the client must detect an Internet connection before Always On VPN connections are attempted. If network location awareness isn’t working correctly Windows doesn’t try to establish the VPN.
James Gledson
/ May 2, 2024Can I ask what event IDs this issue leaves? We have Intune Win11 laptops with Eap (peap) XML user tunnel. Having lots of disconnects as well.
Thnaks
Richard M. Hicks
/ May 2, 2024There are a few to lookout for. 619 and 631 are common. You’ll see 829 as well.
jgledsona67123ba15
/ May 2, 2024Hello. Thanks for useful article.
What event IDs are found with this bug. We have Win11 Intune laptops using user tunnel, with XMP eap(peap) profile. They regularly disconnect.
Richard M. Hicks
/ May 2, 2024There are a few to lookout for. 619 and 631 are common. You’ll see 829 as well.
Andrew J
/ May 22, 2024For anyone having this issue where you have the file formatted exactly as Get-VPNClientProfileXML.ps1 returns but still having the intune sync issue.
Make sure you have an additional character return at the end of your xml before uploading it to intune. This resolved the problem for me after days trying different formats.
Richard M. Hicks
/ May 22, 2024Good to know. Thanks for the tip!
Michael Jensen
/ September 4, 2024Hi Richard.
I’m currently troubleshooting an issue with AOVPN devie tunnel, where the tunnel is connected as soon as user logs in, but that’s not really the case. Eventhough event log indicates a connection, there’s no connection to on-prem ressources. I saw your blog, and thought is this the issue? Because after 10-12 min. the rasclient terminates the connection, and now I get connection to on-prem ressources.
Is this issue with Windows 11 still persistent?
I have checked my XML file several times now, and It lines up perfectly with the result from Get-VPNClientProfileXML.ps, although I don’t have dns suffix – would that be required?
Richard M. Hicks
/ September 4, 2024Yes, this issue is still present. I’m not sure if it’s contributing to your problem, but it’s possible. The best way to check is to run Get-VpnConnection and note the GUID value. Next, issue a device sync and run the command again. If it changes, there’s a problem with your XML. If not, it’s something else.
Let me know what you find!
instantlygroovy9034449ab1
/ September 5, 2024Hi. So I found out that I had GUID changing after sync. After some fidling, I manage to get them aligned, so there’s a match. Although that didn’t help with my issue. Tested different things without any change, although I do get different “readings” Some time the tunnel comes up after just a few min. but most of the time it takes 10-12 min. There’s some weird stuff going on. Back in June when we craeted the setup, there was no issue. So something must have changed – either in the backed services (DNS, Azure VPN GW) or could it be my Windows 11 itself that has the “bug”. Could It be that CU from Juli and/or August introduced an issue with OMA URI VPN? Currently i’m doing a fresh install of Windows 11 from an June image – using autopilot. Actually the device tunnel is up and running very short after started enrollment. So far so god – keen to see what happens after device is done and Hybrid joined. I’ll keep you posted.
Tnx for your help so far.
Richard M. Hicks
/ September 6, 2024Let me know how it goes!
instantlygroovy9034449ab1
/ February 8, 2025Hi Richard. Is It still recommended to use native vpn profile in Intune for Windows 11, and not XML based profile_
Richard M. Hicks
/ February 8, 2025You can use either. I prefer XML because it provides more control over the configuration and exposes settings that aren’t supported in the native Intune VPN template. However, if you are using custom XML with Windows 11 you must configure the XML file in the precise order Intune expects to avoid having the VPN profile removed and replaced on each device sync. So, it’s a little more work, but it’s worth it in the end, IMO. 🙂
instantlygroovy9034449ab1
/ February 20, 2025Thx. I know about the XML issue with Win 11, where they need to match up.
Btw. Talking about WML. I have this customer that have both device and user vpn deployed, and i see some strange behaviour with network traffic. In the Device xml there is only specifik host listed as routes. Dc’s and so. Like 10.2.2.15/32 and so on. All fine there. But in User xml i see they have a route for 10.0.0.0/8. + a lot of /32 hosts Could 10.0.0.0/8 route cause routing problems, when hosts in 10.2.2.0 network is reacable from both tunnels?
Richard M. Hicks
/ February 20, 2025This is a common problem. I solve it by adding the same host routes (/32) to the user tunnel but with a lower metric. That way when both tunnels are active the user tunnel is always preferred.
instantlygroovy9034449ab1
/ February 20, 2025Ahh. I see. But as both tunnels are always active, i suppose the 10.0.0.0/8 could be removed from user XML – or?
Richard M. Hicks
/ February 20, 2025Perhaps, but I’m assuming you’ll need that route to access resources over the tunnel.
instantlygroovy9034449ab1
/ February 20, 2025Agreed! I need the route to 10.0.0.0. If i understand correctly, i need to add a metric line of ex. 1 on each host in my device xml, and then copy those host routes to my user xml, and change metric to 0?
Btw. i noticed the DomainName line in the github user xml where actual domain name is starting with an .
Is that a typo or is that required?
Another fun fact 🙂 Some users reports, when working from home, they have bad performance when connected with cable, but much better on WiFi. Could that have something to do with xml config?
Sorry for my questions – i’m more of a Intune guy 🙂
Richard M. Hicks
/ February 20, 2025I usually define the routes for the user tunnel with a metric of ‘1’ and the routes for the device tunnel with a metric of ‘2’. Works perfectly for me. Although I don’t recommend using the setting, if you do use it the entry must begin with ‘.’ if you want the entire namespace to be included. Otherwise, it’s just an individual host. As for the users having issue with VPN over Ethernet connections it could be due to a known issue related to network interface metrics. I suggest changing the Interface Metric for VPN connections (user and device) to ‘3’ to ensure it is preferred when the tunnels are active. Details here.
https://directaccess.richardhicks.com/2023/09/25/always-on-vpn-and-interface-metrics/
instantlygroovy9034449ab1
/ February 20, 2025Thx Richard. You just saved my day 😅
I will follow your suggestions. Btw. Should i for best practice set metric for ALL routes, or only for those conflicting?
I see that for Windows 11 24H2 and newer, It’s supported to define interface metric in xml file – correct?
Hope to see you on next Workplace Ninja summit, and get a chance to buy you a beer or 2 😁🍻
Richard M. Hicks
/ February 20, 2025Glad I could help! I usually set the interface metric for ALL user tunnel routes to ‘1’ and ALL device tunnel routes to ‘2’ just to ensure no conflicts.
I won’t be at the summit in Baden, CH this year. However I will be at the US Workplace Ninjas event in Dallas in December. I’m planning to be back in Switzerland for next years event, though. 🙂
instantlygroovy9034449ab1
/ February 20, 2025Most appreciated 😉
Maybee I can buy you a beer next year in CH, If we both are going.
Richard M. Hicks
/ February 20, 2025That works for me. Chopfab Amber is my favorite CH beer. 🙂
instantlygroovy9034449ab1
/ February 24, 2025Hi Ricard. Just to let you know, that i now have my Always-On VPN XML profiles working as expected, including Metrics for each route 😅 So far so god. But i’m not getting ny head around the interface metric = 3. I have tested the remediation scripts you have in Github, and i see the pbk file being updated, but i don’t see the change when i run get-netipinterface. I also tryíed adding the lines in user xml. like in your “template” i github, but same result.
Another thing. If customer has, in this case a Exchange on-prem url, that is resolveable both externally and internally, i assume that could cause issues as well (split DNS)
Richard M. Hicks
/ February 24, 2025When the Intune remediation script updates the rasphone.pbk file the changes are not reflected on the VPN tunnel interface immediately. The change only takes effect after the connection restarts. However, if your XML isn’t configured correctly Intune might be replacing your VPN profile on each device sync, thus overwriting your changes to rasphone.pbk (and trigger another remediation event). Run the following PowerShell command and note the output.
(Get-VpnConnection).Guid
Issue a device sync and run the command again. If the GUID changes, your XML isn’t configured correctly.
Let me know what you find!
Richard M. Hicks
/ February 24, 2025Also, regarding the interface metric, that’s just to ensure that DNS replies on that interface are preferred by Windows. It’s critically important when you are using split DNS and have endpoints that are hard-wired. If you are using Windows 11 24H2 you can define the interface metric values in XML. It doesn’t work on earlier versions, unfortunately.
instantlygroovy9034449ab1
/ February 28, 2025Hi Richard. I got that one sorted and worked like a dream 😅 I’m now working on a POC for Always-On Device VPN on cloud-only devices with Azure VPN gw with certificate. I sort og got It working, although I can’t figure out why the device tunnel is not connecting automatically 🤔 I have to trigger rasphone manually to get it connected. And another thing. Even though i have cloud trust setup, and i see the “msds-keycredentiallink” attribute in AD, i don’t get onpremtgt.
I’m using NDES/SCEP on-prem and the scep profile in intune is device based with CN={{Devicename}} as Subject name format.
Richard M. Hicks
/ February 28, 2025The device tunnel requires domain-join and Enterprise edition to work. You can deploy it in other scenarios, but it won’t connect automatically. 🙂 As for the Kerberos issue, two things: First, try setting UseRasCredentials to ‘0’ in your rasphone.pbk file. Also, I’d suggest including the FQDN of the device in the Subject Alternative Name section of the certificate. You can do that by adding a DNS attribute with the value {{DeviceName}}.yourdomain.net in your Intune policy.
Let me know if that helps!
instantlygroovy9034449ab1
/ February 28, 2025Hi. Thx.
So what i’m trying to accomplish won’t work, because device are not domain joined?
Richard M. Hicks
/ February 28, 2025That’s correct. The device tunnel won’t connect automatically if your endpoint isn’t running Enterprise edition and domain-joined.
instantlygroovy9034449ab1
/ February 28, 2025Just an update – I do have Windows Enterprise, and regarding kerberos issue, i can access on-prem ressources if i log in to Windows with password instead of pin. And even now as i have onpremtgt. So i’m thinking device tunnel for cloud only is a no go 😞
Richard M. Hicks
/ February 28, 2025That’s correct. You’ll need an authenticated user tunnel to support what you are doing. 🙂
instantlygroovy9034449ab1
/ February 28, 2025Hmm! I suppose that’s a total different setup? Do you have any guides/blog post about this setup?
Richard M. Hicks
/ February 28, 2025Yes, very much so. Here are two excellent guides for reference. 🙂
https://aovpnbook.com/
https://richardhicks.com/pluralsight/
Enjoy!
Adam Marks
/ November 6, 2024Hi Richard!
We’ve been attempting to implement class-based routing on our AOVPN configs recently, using a preconfigured XML (and following your templates) on our Windows 11 endpoints.
Despite much fiddling and attempting to get the order exactly as displayed in the exported XML, the configuration is still routinely getting removed and reapplied on IME sync.
Have you noticed an increase in issues associated with this? Has Microsoft revealed any plans to fix this seemingly crippling problem? With things as they are currently, we’re basically stuck without the ability to disable the class-based default route, and the native Intune policy simply doesn’t offer that option.
Hoping that perhaps there’s a glimmer of light on the horizon, given that they apparently fixed the original problem with the Intune policies?
Richard M. Hicks
/ November 6, 2024I haven’t noticed an increase in issues, but it certainly isn’t fixed either. I have no idea if Microsoft has plans to fix this or not. However, you might consider using the native VPN Intune policy then using Intune Remediation to disable class-based default route post-deployment. I have a remediation script posted in my GitHub for this if you are interested.
https://github.com/richardhicks/endpointmanager/
Adam Marks
/ November 8, 2024Thanks, I’ll give that a shot! Might be a working option until Microsoft finally sort this out.
Adam Marks
/ November 8, 2024Sidenote here – one of your older blog posts states that the only way to disable class-based default route is to use an XML-based profile. This is apparently not the case, so you may want to update that post 🙂
https://directaccess.richardhicks.com/2021/03/04/always-on-vpn-class-based-default-route-and-intune/
Richard M. Hicks
/ November 8, 2024Thanks for bringing this to my attention. I will update the post with that information soon!