When an Always On VPN connection is provisioned to a Windows 10 client, there’s nothing to prevent a user from disconnecting or even deleting the connection. Some administrators have expressed concern about this, fearful that users may disable the VPN to improve performance or circumvent access controls when force tunneling is enabled. Also, administrators may wish to prevent users from accidentally or purposefully making changes to the configuration, or even deleting the connection entirely.
LockDown Mode
To address these concerns, Microsoft included a feature called LockDown mode for Always On VPN. Once enabled, the following conditions apply.
- The LockDown VPN connection is always on.
- The LockDown VPN connection cannot be disabled.
- The user can’t make changes to or delete the LockDown connection.
- No other VPN connections can exist on the client.
- Force tunneling is enabled by default (split tunneling in LockDown mode is not supported).
Challenges with LockDown Mode
Always On VPN LockDown mode brings with it some unique challenges, however. Consider the following.
Limited Protocol Support
LockDown mode only supports IKEv2 and the native (built-in) VPN client. Third-party plug-in provider clients are not supported. IKEv2 is an excellent VPN protocol in terms of security, but operationally speaking it has some serious drawbacks.
Force Tunneling Only
LockDown mode uses force tunneling exclusively. All network traffic must go over the VPN connection. However, if the VPN connection is not available, the client will be unable to access any network resources at all, local or remote.
Captive Portal Issues
LockDown mode prevents clients from connecting to network resources from a network with a captive portal.
On-premises Connectivity
In LockDown mode all network traffic must flow over the VPN tunnel even if the client is on the internal network. This also means that if the VPN server is not reachable internally (unable to resolve public hostname, protocols/ports blocked by internal firewall, unable to route to VPN server, etc.) the client will not be able to access any internal or external network resources at all.
Deleting a LockDown VPN Connection
Deleting a LockDown VPN connection is also challenging. Administrators will find that trying to delete it using the UI or PowerShell often fails. To delete a LockDown Always On VPN connection, use psexec.exe to open an elevated PowerShell command window running in the system context using the following command.
.\psexec.exe -i -s C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe
In the new elevated PowerShell window run the following commands to delete the LockDown VPN connection.
$ConnectionName = ‘[LockDown VPN connection name]’
$ConnectionNameEscaped = $ConnectionName -replace ‘ ‘, ‘%20’
$CimInstance = Get-CimInstance -Namespace ‘root\cimv2\mdm\dmmap’ -ClassName ‘MDM_VPNv2_01′ -Filter “ParentID=’./Vendor/MSFT/VPNv2′ and InstanceID=’$ConnectionNameEscaped'”
Remove-CimInstance -CimInstance $CimInstance
Optionally, download and run Remove-LockDownVPN.ps1 here.
Summary
While Always On VPN LockDown mode might seem like a good idea initially, its implementation is heavy-handed and practically speaking ends up causing more problems than it solves. For administrators that plan to enable this feature, carefully consider the drawbacks and limitations outlined above and their impact on supportability and the user experience.
Additional Information
Windows Always On VPN Device Tunnel Config using Microsoft Intune
Windows 10 Always On VPN Security Configuration
Windows 10 Always On VPN Hands-On Training
Flo TPG
/ April 8, 2019I was so excited when I read the headline… practically this is useless. The only use case I can imagine would be tunneling wireless lan clients on the corporate campus (if you’re that paranoid).
Nice conclusion: “causing more problems than it solves”
Hannan
/ April 12, 2019Exactly, I have also used purevpn windows vpn for tunneling wireless lan clients it was useful,,,
Dietmar
/ May 7, 2019What if you hide the settings-page with group policy: ms-settings:network-vpn. The “users” are not able to delete the VPN connection anymore… 99.9% of our users are not able to use PowerShell I think.
Richard M. Hicks
/ May 8, 2019That could certainly be an option. 🙂
IL73
/ June 6, 2019Hi,
We have deployed AOVPN using a user profile and a ForceTunnel option. Yet still users are able to access resources on their local network and not all traffic is being routed down the VPN.
Has anyone else experienced this?
Thanks.
Richard M. Hicks
/ June 7, 2019That is expected behavior. Force tunneling still allows local subnet access, which is required for things like Wi-Fi captive portals and local printing. If you want to force all network traffic over the VPN, including local subnet traffic, you’ll have to enable LockDown mode. However, be advised the doing this will break captive portals. Details here: https://directaccess.richardhicks.com/2019/04/08/always-on-vpn-lockdown-mode/
IL73
/ June 7, 2019Has anyone successfully deployed lockdown mode? If so was this deployed as a device or user profile? Does anyone have a sample xml file?
Thanks.
Richard M. Hicks
/ June 7, 2019I’ve only ever deployed in test and PoC for evaluation purposes. No customer of mine has opted for it yet. LockDown mode is implemented as a device tunnel only. I don’t have a sample XML file to share, but it’s enabled by adding the LockDown element and setting it to “true”.
Michael van der Burg
/ August 29, 2019I have a customer who really wants this, I tried to convince them not to, but anyway. I’m testing it now, but when the notebook with a VPN lockdown connection is in the Corporate LAN it still wants to lockdown and networks are not accessable. The doesnt seem to work 🙁
Doe somebody know how to resolve this issue?
Richard M. Hicks
/ August 29, 2019There’s nothing to resolve. It is inherent in the design. When LockDown mode is enabled the client will only ever connect to the network (any network) if the VPN connection is established. That includes the internal network. This is one of the things that makes LockDown mode undesirable in most deployment scenarios.
Robert N
/ February 8, 2020Thanks for the info on LockDown VPN mode. It really helped me to understand the feature.
Ryan Young
/ February 13, 2020Hi Richard.
So ‘ForceTunnel’ comes off as a bit of a misnomer. Even in your article you write “LockDown mode uses force tunneling exclusively. All network traffic must go over the VPN connection”.
But in a reply above you mention that it’s expected by design that you can still access local resources to enable connectivity to captive portals and such. Our desired outcome is to allow captive portals, but once there is an active ‘truly working’ internet connection we want it to force tunnel (in the expected sense of the word). We’re using device tunnels with the ‘forcetunnel’ option.
Have you ever come across any solutions that limit connectivity on non-domain networks down to captive portals only, and then further limit the connectivity after the tunnel is up to force traffic over the tunnel?
On my end I can imagine using windows firewall to block incoming local traffic and allow outbound common known tcp web traffic to private/public networks. But I couldn’t possibly account for every obscure port some genius at some hotel decided to use for their captive portal. And it doesn’t accomplish the desired effect of limiting it further once the tunnel is up.
Any advice in getting at least half way towards our goal would be most helpful, and I think insightful for most persons who reach this page on lockdown.
Richard M. Hicks
/ February 14, 2020Indeed, in the Microsoft world “force tunneling” means tunneling all *non-local traffic* over the VPN. Typically that means that local traffic is allowed, which of course allows you to get to things like local printers and captive portals. Lockdown mode does address this scenario and forces all traffic (including local traffic) over the VPN, but it does break captive portals. Third-party solutions are much better at handling this in my experience.
Mike Dees
/ February 26, 2020How do I enable lockdown mode? I don’t see guides for enabling it anywhere. No sample XMLs, nada. If I can enable force tunneling on the device tunnel I’d be happy to, but all of my attempts have failed.
Richard M. Hicks
/ February 27, 2020Hi Mike,
You would enable LockDown mode by adding <LockDown>true</LockDown> to your ProfileXML. You can then remove the AlwaysOn and DeviceTunnel elements as they are implied.
Reach out to me directly if you’d like me to share an example with you.
Patrick
/ March 31, 2020Hello Richard,
I understand that LockDown mode is not supported by Microsoft even in a context of highly secure use. Which is really damaging, if you want to ban all access to a captive portal for example.
Do you have this information?
Thanks in advance.
Patrick
Richard M. Hicks
/ March 31, 2020That’s not my understanding. The lockdown mode configuration is documented on the Microsoft web site, so I would expect it to be fully supported.
ced666
/ April 1, 2020Thank you very much,
The only official document I found on this mode is this:
https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp which dates from 2017.
Acacio Fernandes
/ June 15, 2020We have followed your articles and impleted always on vpn and it works great so far it dramitically helped us to overcome the WFH situation during pandamic. Now we seems to have some issues cropped up when users are slowing returning back to office the always on vpn profile remains connected even when connected to locally (inside premises)
though not all but the users seems to be growing. we have setup the dns suffix and trusted network in the script sucessfully and it works most of the time. but user base is growing steadily while users start to return back to office.
any ideas anyone ?
Richard M. Hicks
/ June 18, 2020As long as trusted network detection is configured and the value matches the DNS suffix issued by your on-premises DHCP servers it should work. 🙂
Arthur Kurt
/ September 18, 2020Hello Richard,
thanks for all information you provided. MS site is really useless for Always On VPN scenarios. we are trying to enable LockDown in our VPN config. we added true to profile xml for Device tunnel, but users and admins still can delete or change device tunnel vpn connection from GUI. and even Device Tunnel is not connected users can access network.
Richard M. Hicks
/ September 18, 2020To start, I don’t recommend using LockDown mode for Always On VPN. However, if you really want to do this, you don’t use the DeviceTunnel element at all. You use the LockDown element instead, which implies it is a lockdown VPN connection. I can share a sample XML configuration file with you if you like. Just use the contact form on this site and let me know you’d like me to send it to you.
Arthur
/ October 5, 2020hi Richard,
is LockDown mode configures VPN as Split Tunnel or Forced Tunnel?
Thanks..
Richard M. Hicks
/ October 13, 2020Force tunnel only.
Peter Klaffehn
/ October 19, 2021Hi Richard,
we are currently using the Always On Device Tunnel without Lockdown Mode. As far as i understood the client will be able to access ressources on the local network it is connected to. But we have a problem with captive portals not working (Portal page doesn’t show up). Is there something special we have to consider?
Regards, Peter
Richard M. Hicks
/ October 20, 2021Are you using split or force tunnel?
Peter Klaffehn
/ October 20, 2021Hi Richard, we ar e using the forced tunnel. Regards, Peter
Richard M. Hicks
/ October 20, 2021The device tunnel does not support force tunnel configuration. You must use split tunnel for the device tunnel connection.
https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config
Bill Earp
/ November 10, 2021Hi Richard
The device tunnel does not support force tunnel configuration. You must use split tunnel for the device tunnel connection. https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config
We are using a forced device tunnel for many years now without any issues. Even added some exclusions. But learning now it is not supported. Do we need to worry?
Richard M. Hicks
/ November 16, 2021I don’t think so. No doubt Microsoft has a reason to call out this specific configuration as unsupported though. My guess is there are some cases where it causes problems. If it is working for you without issue, I’d say stick with it. 🙂