Always On VPN Device Tunnel Configuration Guidance Now Available

When Always On VPN is configured for Windows 10, the VPN connection is established automatically when the user logs on to their device. This differs fundamentally from DirectAccess, where the connection is established by the machine, before the user logs on. This subtle but important difference has some important ramifications. For example, it means that a user cannot use Always On VPN until they’ve logged on to their device at least once while connected to the corporate network. DirectAccess doesn’t have this limitation, as a connection to an on-premises domain controller is available to authenticate a new user upon first logon.

Device Tunnel Support

To address this shortcoming with Always On VPN, and to provide better feature parity with DirectAccess, Microsoft introduced an update to Windows 10 in the recent Fall Creators update (v1709) that allows for the configuration of a device tunnel for Windows 10 Always On VPN. Once enabled, the device itself can automatically establish a secure remote connection before the user logs on. This enables scenarios such as device provisioning for new remote users without cached credentials. It also enables support for password reset using CTRL+ALT+DEL.

Manage Out

Device tunnel for Windows 10 Always On VPN also enables important manage out scenarios that DirectAccess administrators have come to rely upon. With a device tunnel configured, administrators can initiate connections to remote connected Always On VPN clients to provide remote management and support, without requiring a user to be logged on at the time.

Requirements

To support an Always On VPN device tunnel, the client must be running Windows 10 Enterprise or Education v1709 or later. The computer must be domain-joined and have a machine certificate installed. Device tunnel can only be configured using the built-in Windows 10 VPN client (no support for third-party clients) and the IKEv2 protocol must be used.

Caveat

When configuring a device tunnel, traffic filters can be implemented to restrict communication to only those internal resources required, such as domain controllers, Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM) servers. However, when traffic filters are used, no inbound traffic to the client is allowed. If manage out is required over the device tunnel, traffic filters cannot be configured. Microsoft expects to remove this limitation in a future update.

Provisioning and Documentation

Configuring and provisioning a Windows 10 Always On VPN device tunnel is similar to the process for the Always On VPN connection itself. A VPN profileXML file is created and then deployed via a Mobile Device Management (MDM) solution such as Microsoft Intune. Optionally, the VPN profileXML can be deployed using SCCM or PowerShell. Additional information about Windows 10 Always On VPN device tunnel configuration, including a sample profileXML and PowerShell script, can be found here.

41 Comments

Stefaan Pouseele

So, when configuring a device tunnel without any traffic filter, you don’t need a user tunnel at all. In other words, it’s very much like a classic IKEv2 VPN with machine certificate but it’s automatically established.

You would think, but no. 🙂 The user has no access to anything over the machine tunnel. Machine tunnel access is limited to the local system account. In a machine tunnel only configuration, a user could log n and authenticated to the domain without having cached credentials, but they wouldn’t be able to access anything themselves. They’d have to have a user tunnel provisioned in order to access any internal resources.

UPDATE: My original response was incorrect. 🙂 Indeed, the user will have access to any resources available over the device tunnel. The general recommendation is to restrict access over the device tunnel to only those resources required to support user logon (DCs, DNS, PKI, etc.). All other access should be granted via the user tunnel.

so, how can I test it make sure this even working? I can see the client in my RRAS, but I cannot ping it. I tried letting another user log in, but that didn’t work either. And I’m not really sure on the point of this because with 2 tunnels, 1 for the user, and 1 for the machine, that means twice as many ports will be needed on the RRAS

If the client computer shows up as a connection in RRAS then it is connected. If you configured the device tunnel to use a traffic filter, that will (unfortunately) prevent manage out from working. Right now if you want to reach out and touch connected Always On VPN clients you can’t specify a traffic filter. Hoping that will be fixed in a future release of Windows though. 🙂

I removed the and sections when I was testing yesterday. But this means that new user should be able to log in yes? And do you have any thoughts on why to really use this when it will take two Ports/IPs?

If your device tunnel is operational then yes, a user should be able to log on without using cached credentials. If that doesn’t happen, I would suspect that the device tunnel may be connected, but probably isn’t fully allowing internal network access somehow. Also, you are right about the device tunnel now using twice as many connections. That is something you’ll have to consider when deploying Always On VPN. If you plan to support both device and user tunnels you’ll need to figure that in to your capacity planning efforts.

I’ve got AlwaysOn working in a test lab and all seems good so far. I had to use SCCM to roll out the VPN_Profile.ps1 (SCCM is a monster in itself).

What the script doesn’t do is to enable “Register this connection’s address in DNS”. I’ve enabled it manually and then re-captured the VPN profile again but the resulting script still ignores this setting.

Do I have to manually add a PowerShell line in the VPN_Profile.ps1 script to achieve this?

You’ll need to make sure that RegisterDns element is defined in your ProfileXML. Also, I’m hearing that even with that configured, it wasn’t working in v1709. I do understand that it has been resolved and is now working in 1803. If you have that set and it isn’t working, make sure you’re on 1803 and test again. 🙂

I’m using Windows 10 1709 and have successfully created and established a device tunnel – *just* a device tunnel. The connection is stable, right up to the point where the user logs in. At that point it disconnects, never to reconnect.

So, I thought I’d try best practice and create a user tunnel to work alongside it and take over once the user logs in. I assume that’s how it works?

What happens now is that the device tunnel still comes up OK, the user logs in and the user tunnel briefly connects then disconnects as the desktop appears. All the while the device tunnel stays up, and stays that way.

End result? The user experience is good and I have access to all I need on the network but what bugs me I’m sure that the user tunnel should stay up and take over network comms after logging in. Any thoughts?

Happily (and sadly) the upgrade to 1803 seems to have ironed out all the niggly bugs, including the one I mention here. I say ‘sadly’ because all 500 company laptops are now going to have a forced upgrade. Not quite the outcome I wanted. Despite this, the device tunnel I’ve deployed using SCCM is working very well and appears extremely stable, despite the interruption incurred by moving between WiFi hotspots.
Many thanks to Richard for all the ongoing help.

RealWheel

I am facing a strange issue.
I have configured the device tunnel.
However when the computer is already connected to the device tunnel, the user Always On VPN does not connect automatically anymore, because TrustedNetworkDetection thinks it is connected to the corporate network already.

Are you running Windows 10 v1709? If so, try updating to 1803. I believe that is a bug in the detection that is fixed in the latest release. In theory the VPN connection should only search physical interfaces for the DNS suffix. However, many have reported this issue that you are seeing where it is detecting it on a tunnel (VPN) interface. Again, that appears to have been resolved in 1803.

Jason Jones

The fix which addresses logic errors in Trusted Network Detection when using User and Device Tunnels in parallel will be released for Windows 10 v1803 on September 18th as KB4458469 – hopefully this should resolve a majority of the Device Tunnel issues experienced, but other reported problems are also being investigated/triaged.

1803 (Enterprise) Device tunnel Only. This is what I like to share (Powershell method):
Be aware, the ProfileXML parser is very sensitive. I’ve reduced ProfileXML to a minimum, moved elements up/down changed XML editors trimmed Tabs/spaces, but suspect the tunnel not getting all setting active. There is currently one single method to verify what’s interpreted and set. Note! This command must be run in SYSTEM context

Get-WmiObject -Class MDM_VPNv2_01 -Namespace root\cimv2\mdm\dmmap

Compare the ProfileXML elements from this output to your custom ProfileXML.XML input file. If they match you are good to go.

The next you may check out is NRPT namespaces (for VPN_CONNECTION) use: Get-DnsClientNrptRule
to verify the NameServers parameter are set correct. The command list what seems to be duplicate entries with different name. I haven’t figured out why.

Another odd findings is duplicate entries in the interpreted ProfileXML …;… element.

Thanks for the information! I agree, the ProfileXML formatting is extremely sensitive. I’ve had issues where not using the exact case used in the CSP caused it to fail! Also, I typically use plain old notepad for editing, as I’ve seen other editors cause problems. Always a party with Always On VPN! 😉

Richard, do you know whether AlwaysOn VPN supports NPS/NAP? We would like to quarantine any client (device or tunnel) which isn’t up-to-date with anti-virus definitions. I’ve searched on Technet but found no clear advice.
Thank you.

Ian Burnell

Interested to read Andy’s comments about “Register this Connection’s address in DNS”. Our estate is 1703 (1803 in testing) so I need to ensure this box is ticked – any thoughts?. I tried adding true into the profile/PS script but seems to tick box to use default gateway. Also tried using Powershell but at present can’t see an easy way – wanted to add line into the VPN_Profile.ps1 to do the job

Jason Jones

The fix which addresses logic errors in Trusted Network Detection when using User and Device Tunnels in parallel will be released for Windows 10 v1803 on September 18th as KB4458469 – hopefully this should resolve a majority of the Device Tunnel issues experienced, but other reported problems are also being investigated/triaged.

sebus

restrict access over the device tunnel to only those resources required to support user logon
But in my case these are the SAME servers (DNS/DC, SCCM, SCCM DP, FS (as I keep on FS share some of the GPO referenced objects)
So it looks to me like the user tunnel is totally for nothing in my case?!

That’s why we say “recommended”. 😉 It’s not always feasible depending on your infrastructure. Since clients can access any resources available via the device tunnel, if everything they need is on those servers then perhaps the user tunnel is redundant. In most environments that’s not the case though.

I’ve got a odd issue where, a few minutes after a login and establishing the user tunnel, I can’t get to anything that’s defined in the traffic filters of the device tunnel. Both tunnels are connected and I can reach anything else that I’m connected to via the user tunnel, but the specific hosts defined in the device tunnel’s traffic filter can no longer be pinged.

I say a few minutes after log in because, initially, everything is working fine and then these connections stop. If I take down the user tunnel, the hosts defined for the device tunnel start responding again.

I added a metric to the device tunnel routes and that seemed to help for a bit, but the problem ended up coming back. Any thoughts on this?

LanDI

Hi Richard, we have Device Tunnel (only) up and running on 1909.
dont think i have any traffic filters but how do i test the “manage-out” functionality? should i be able to ping/rdp back to my Pcs? do i have to have some sort of static route in place? presumably of the everything in the subnet my remote pcs use go back out via the external interface?

You should be able to connect to remote Always On VPN clients using their IP address at a minimum. This of course assumes that the client firewall allows this inbound traffic. If you configure the Always On VPN client to register its IP address in DNS then you should be able to resolve their names internally as well.

Priya

Thank you for this article. I do have a question regarding traffic filters. I’m not interested in Always On VPN but do want to use traffic filters to restrict traffic over vpn tunnel. Under VpnNativeProfile hierarchy, I configured RoutingPolicyType as “Force Tunnel” and then under traffic filters, I’ve configured RoutingPolicyType as “splitTunnel”. I was expecting all the traffic to take vpn tunnel except the application(eg: Internet Explorer in my case configured in traffic filter rule) to go thru splitTunnel. But it doesn’t seem to work. As I wasn’t sure, I turned on Always ON VPN flag too. What I noticed is it simply doesn’t care about the filter I have added. How do I verify if my traffic filter is properly created and applied to this profile? I’d really appreciate for any help here.

Split tunnel and force tunnel are mutually exclusive options. You’ll have to choose one or the other. Once you’ve done that you can enable traffic filters to allow specific IP addresses, protocols, ports, FQDNs, applications, or any combination of all of those.