Windows 10 Always On VPN hands-on training classes now forming. Details here.
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.
Additional Resources
Configure a VPN Device Tunnel in Windows 10
Always On VPN and the Future of DirectAccess
5 Things DirectAccess Administrators Should Know about Always On VPN
Stefaan Pouseele
/ November 23, 2017So, 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.
Is that correct?
Regards,
Stefaan
Richard M. Hicks
/ November 24, 2017You 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.
Daniel Rapp
/ February 7, 2018Hi, have you happen to find any guide for deploying device tunnels with sccm, seems a bit messy with the psexec and all that..
Richard M. Hicks
/ February 8, 2018I don’t have that information at the moment. Someone with SCCM knowledge will have to provide that. If I find a resource though I’ll be sure to post here.
Thomas Malkewitz
/ February 12, 2018so, 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
Richard M. Hicks
/ February 13, 2018If 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. 🙂
Thomas Malkewitz
/ February 13, 2018I 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?
thanks.
Richard M. Hicks
/ February 15, 2018If 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.
andychips
/ May 24, 2018I’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?
Richard M. Hicks
/ May 24, 2018You’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. 🙂
andychips
/ May 29, 2018Thanks Richard. I’m always amazed at your rapid response times.
RegisterDNS seems to be working just fine with 1709.
Much appreciated.
Andy.
Richard M. Hicks
/ May 30, 2018Great to hear! 🙂
andychips
/ May 30, 2018Richard, could you possibly comment on this, please?:
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?
Richard M. Hicks
/ May 30, 2018There’s a known issue with the device tunnel in v1709 – https://directaccess.richardhicks.com/2018/04/09/always-on-vpn-rasman-device-tunnel-failure/. I’d suggest updating to 1803 and testing again. 🙂
andychips
/ June 5, 2018Happily (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.
Richard M. Hicks
/ June 5, 2018My pleasure. 🙂
RealWheel
/ May 28, 2018I 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.
Richard M. Hicks
/ May 30, 2018Are 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
/ September 14, 2018The 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.
Richard M. Hicks
/ September 15, 2018Great news. Thank you Jason!
realwheel
/ May 31, 2018Okay, thanks.
I was testing on v1709, so I’ll check 1803 soon to see if that will fix it.
Richard M. Hicks
/ May 31, 2018Let me know how it goes!
Rune Flo
/ June 14, 20181803 (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.
Rune Flo
/ June 14, 2018ProfileXML “Servers” element (original text disappeared when posting?).
Richard M. Hicks
/ June 15, 2018Thanks 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! 😉
andychips
/ July 3, 2018Richard, 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.
Richard M. Hicks
/ July 4, 2018Always On VPN doesn’t support NAP, but it does support Azure conditional access. Details here: https://blogs.technet.microsoft.com/microscott/add-conditional-access-to-your-windows-10-vpn-with-intune-and-azure-ad/.
Ian Burnell
/ September 4, 2018Interested 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
Richard M. Hicks
/ September 4, 2018It’s likely possible to do this using WMI in PowerShell, but how that’s done I’m not certain. That’s way past my PowerShell abilities. 🙂
Jason Jones
/ September 14, 2018The 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.
Richard M. Hicks
/ September 15, 2018Great news. Thank you Jason!
Colin
/ October 19, 2018Do traffic filters only work with device tunnels? I have been trying to use traffic filters for remote addresses in a user tunnel and it just doesn’t work.
Richard M. Hicks
/ October 20, 2018No, you should be able to define traffic filters on either the device or user tunnel.
sebus
/ May 30, 2019restrict 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?!
Richard M. Hicks
/ May 30, 2019That’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.
lonewaffle (@lonewaffle)
/ April 23, 2020I’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?
Richard M. Hicks
/ April 24, 2020No idea at all. I typically avoid the use of traffic filters so I don’t have much experience using them. :/
LanDI
/ April 28, 2020Hi 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?
Richard M. Hicks
/ April 28, 2020You 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.
Mostafa Mahmoud
/ December 28, 2020thanks Richard for the great information and instructions
i really appreciate your efforts
keep up the good work 👏
Richard M. Hicks
/ January 6, 2021My pleasure!
Priya
/ May 19, 2020Hi Richard,
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.
Thanks,
Priya
Richard M. Hicks
/ May 21, 2020Split 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.
Randy Large
/ October 13, 2020Hi Richard, thanks for your brilliant guides.
If I need to push apps to a device that is connected via a device tunnel, am I right in saying that I need to remove the traffic filters that are configured.
If so, do you have a sample .XML to compare, I don’t know how to remove the filters in the XML.
Richard M. Hicks
/ October 16, 2020That’s correct. By default, once a traffic filter is defined on the client, all inbound traffic is implicitly denied. You’ll need to edit your ProfileXML and remove any references to [TrafficFilter] and redeploy the connection.
Robin Beismann
/ December 2, 2020Hey Richard,
is there any advantage in your eyes to use Traffic Filters over Host Based /32 Routes?
At the moment, we do have one /32 route for every DC, PKI and SCCM related server, however this results in a pretty large routing table.
I do push a metric of 5 to the user tunnel and 10 to the device tunnel, so as soon as the user tunnel is connected, it takes precedence anyway and routes all private networks (3 Routes).
Best regards
Robin
Richard M. Hicks
/ December 3, 2020Using traffic filters would provide better security, but they are difficult to manage especially at scale. Also, until recently (blog post coming soon), enabling traffic filters prevented remote clients from being managed by internal hosts, which was often a show-stopper. If you have many DCs, you don’t have to provide access over the device tunnel to all of them. You really need only one DC in the site where the VPN server belongs (I would suggest using two at a minimum for redundancy).
Robin
/ December 3, 2020Thanks for the fast reply!
Since both Traffic Filters and VPN Routes are both maintained in the same configuration on the client, I don’t really see the security enhancement or am I missing something?
A local admin could modify both.
We do have that many routes as we do have 5 different AOVPN Hubs via GSLB plus multiple domains, the Computer is mostly not in the same domain as the user, therefor it requires both for proper authentication.
I mean, in the end it doesn’t really matter if I have a large list of traffic filter IPs or routes, right? I’m compiling the list via Powershell anyway, so thats ok for me.
Always happy to hear about the design possibilities though!
Richard M. Hicks
/ December 3, 2020The advantage of using traffic filters over routes is that access is further restricted by protocol/port in addition to IP address. When using routes the client would have access to all protocols/ports, whereas the traffic filter would further limit access to only specific protocols/ports. I agree that if an endpoint is compromised an attacker could modify either, but the attack surface is reduced when using traffic filters.