Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Operation and Best PracticesUnlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.

Device Tunnel Use Cases

The device tunnel is designed to allow the client device to establish an Always On VPN connection before the user logs on. This enables important scenarios such as logging on without cached credentials. This feature is crucial for organizations who expect users to log on to devices the first time remotely. The device tunnel can also be helpful for remote support, allowing administrators to manage remotely connected Always On VPN clients without having a user logged on. In addition, the device tunnel can alleviate some of the pain caused by administrators resetting remote worker’s passwords, or by users initiating a Self-Service Password Reset (SSPR).

Device Tunnel Requirements

The device tunnel requires Windows 10 Enterprise edition 1709 or later, and the client device must be joined to the domain. The device tunnel must be provisioned in the context of the local system account. Guidance for configuring and deploying a Windows 10 Always On VPN device tunnel can be found here.

Device Tunnel Authentication

The device tunnel is authenticated using a certificate issued to the client device, much the same as DirectAccess does. Authentication takes place on the Routing and Remote Access Service (RRAS) VPN server. It does not require a Network Policy Server (NPS) to perform authentication for the device tunnel.

Always On VPN Device Tunnel Operation and Best Practices

CRL Checking

Eventually an administrator may need to deny access to a device configured with an Always On VPN device tunnel connection. In theory, revoking the client device’s certificate and terminating their IPsec Security Associations (SAs) on the VPN server would accomplish this. However, Windows Server RRAS does not perform certificate revocation checking for Windows 10 Always On VPN device tunnel connections by default. Thankfully an update is available to enable this functionality. See Always On VPN Device Tunnel and Certificate Revocation for more details.

Configuration Best Practices

As the device tunnel is designed only to support domain authentication for remote clients, it should be configured with limited access to the on-premises infrastructure. Below is a list of required and optional infrastructure services that should be reachable over the device tunnel connection.


  • All domain controllers
  • Enterprise DNS servers (if DNS is running on servers other than domain controllers)


  • All issuing certification authority (CA) servers
  • All certificate services online HTTP responders
  • All certificate services Online Certificate Status Protocol (OCSP) servers
  • System Center Configuration Manager (SCCM) distribution point servers
  • Windows Server Update Services (WSUS) servers
  • Management workstations

Limiting Access

Limiting access over the Always On VPN device tunnel can be accomplished in one of the following two ways.

Traffic Filters

The administrator can configure traffic filters on the device tunnel to restrict access only to those IP addresses required. However, be advised that when a traffic filter is enabled on the device tunnel, all inbound access will be blocked. This effectively prevents any remote management of the device from an on-premises system over the device tunnel.

Host Routes

An alternative to using traffic filters to limit access over the device tunnel is using host routes. Host routes are configured with a /32 prefix size and define a route to a specific individual host. The following is an example of host route configuration in ProfileXML.

Always On VPN Device Tunnel Operation and Best Practices

Note: A PowerShell script that enumerates all enterprise domain controllers and outputs their IP addresses in XML format for use in ProfileXML can be found here.


Some organizations may have hundreds or even thousands of domain controllers, so creating individual host route entries for all domain controllers in profileXML may not be practical. In this scenario it is recommended to add host routes only for the domain controllers that belong to the Active Directory site where the VPN server resides.


Do not use the <DomainNameInformation> element in ProfileXML or enable force tunneling for the device tunnel. Neither of these configurations are supported.

Tunnel Coexistence

The device tunnel can be safely deployed in conjunction with the user tunnel whenever its functionality is required.

DNS Registration

If the device tunnel and user tunnel are both deployed, it is recommended that only one of the tunnels be configured to register in DNS. If the device tunnel is configured to register its IP address in DNS, be advised that only those devices with routes configured in the device tunnel VPN profile will be able to connect remotely to Always On VPN clients.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Leave a comment


  1. Michael Leeming

     /  March 30, 2020

    Tunnel Coexistence
    Will this use twice the amount of ip addresses for connected devices?
    Effectively many more, as RAS often have multiple device tunnels hanging from the same devices.

    • Michael Leeming

       /  March 30, 2020

      And if registerDns makes more sense with User tunnel regarding support scenarious, then leaving registerdns out of device tunnel, will make it hard for sccm etc. to contact a device, before it also has a user tunnel active?

      • Correct. If you decided to register the user tunnel, then SCCM and other management tools must wait until a user is currently logged on to connect remotely.

    • Absolutely. That’s why it is recommended only to deploy the device tunnel when absolutely necessary. If you have to deploy it, plan accordingly. It will require at least twice the address space, and certainly some more resources on the RRAS server to support the extra connections. Not much more though, as mos of the traffic will use the user tunnel anyway.

  2. Eric

     /  March 30, 2020

    Thanks a lot for answering questions and this clear post about device tunnel. Greetings from the Netherlands!

  3. Michael Leeming

     /  March 30, 2020

    Well, there is also the option to only install a device tunnel, but then you will miss out on SSTP fallback, which is only supported by user tunnels.
    I think maybe it is best to have 2 options, a group of devices with only user tunnels and a group of devices with only device tunnels.
    I wish there was an option for triggering a device tunnel before login and to have it close down completely after login, before a user tunnel is started.

    • I’ll be covering that topic in depth next week. 🙂 You could, in theory, hack something together yourself to accomplish this. You could set the device tunnel AlwaysOn option to ‘false’, then create a schedule tasks that triggers the connection upon system restart. You could then configure another scheduled task to disconnect the device tunnel when the user tunnel comes up. Not sure how well it will work, but it might be interesting to test sometime!

      • Michael Leeming

         /  March 30, 2020

        I have had the same thought, but I think the hardest part would be not to start the device tunnel when connected to company network already or trigger the device tunnel when Internet is available, cause it might not be at boot. Normally device tunnel would trigger as soon as Internet is available, this is a slightly different scenario and timing could be an issue. (mostly with WiFi)
        But it is very interesting to see if it is possible.

      • There are many other scenarios to consider as well, such as coming out of sleep/hibernate, what happens if a user tunnel connection drops, etc. No question this would likely cause more problems than it solves. It was just a thought really. Technically possible, just not practical.

      • Michael Leeming

         /  April 6, 2020

        I’m planning to go with the following.
        1.. Deployed device tunnel with always on disabled, but with register dns and routes to all internal subnets.

        2. Create a scheduled task which fetches a public available text or XML list. If device is in the list, the device tunnel should connect. Run scheduled task at boot and forever check the list every 5 or 10 minutes.

        3. Deploy user tunnels with always on enabled and also with register dns and routes to all internal subnets.

        4. Make it possible for IT administrators to add devices to the public list, when a device needs to allow non-cached logins or when a remote device needs to be managed by sccm, manually or similar.

        To some it up, the device tunnel will become a backup vpn connection, which remotely can be turned on when needed. But in day to day usage, only the user tunnel will be used and conflicts between the two tunnels, like register dns, will not be a big issue.

        Hope this makes sense 🙂

      • Clever! Hope this doesn’t cause more support overhead than it is worth though. 🙂

  4. Hi Richard, many thanks for these fantastic articles.

    Do you know if Read-Only Domain controllers are supported? We have a single AD site with 2 DC’s but we would prefer to only allow access to a RODC.

  5. I should have also said that we are looking at deploying device tunnel only so we will not need an NPS server. We are going to allow access to our SCCM DP, WSUS, AV server.

    In fact, please ignore me, I have answered my own question, we use LAPS so the remote clients will need to be able to update their AD computer account.

    Thanks anyway!!

  6. So we have found we need to include our DNS servers to the device tunnel otherwise get the domain controller cannot be found message.

    While logically this seems reasonable, your lack of mentioned it, makes me wonder if something isn’t working right.

    That said, my assumption (out of thin air), is that we use InfoBlox for DNS. Not entirely sure but believe we have been trying to remove at least some reliance on the Win/DC DNS services.

    Does this sound like a reasonable assumption?

    • Good point. I’ll update the post to reflect that. Most organizations have DNS running on their domain controllers so the guidance reflects that. But you’re right, if that’s not the case and you are using something else for DNS those would need to be included too.

  7. Ryan Arnold

     /  August 27, 2020

    Thanks for the great content as always, Richard! I have a question regarding DNS resolution. We are using a device tunnel setup on Windows 10 v2004 with Server 2019 and our internal domain is the same as our external. I’ve noticed that after creating the device tunnel, pinging a internal resource always returns external IP unless I change the metric of the device tunnel to something lower than the Ethernet adapter. Is there a way to set the metric lower in the xml or perhaps there is another way to address this altogether? Thank you.

    • This is a common complaint. Indeed, lowering the interface metric of the VPN interface to something lower than the Ethernet interface is the way to resolve it. Unfortunately you can’t do this in XML. However, you can update this setting after the VPN connection has been created by using my Update-Rasphone.ps1 PowerShell script. You’ll need to run it on each machine where you have this problem. Here’s the syntax.

      .\Update-Rasphone.ps1 -ProfileName [name of VPN profile] -InterfaceMetric 3

      You can find the script here:

  8. Jake Gilfillan

     /  October 20, 2020

    Richard, Curious if you’ve seen any issues with the user tunnel initiating its connection from the Device Tunnel like some sort of loopback? When checking the RRAS console, almost all of our user’s client address as the IP they’ve received from the Device Tunnel. Many of the users also have multiple user tunnels from the same device IP, some users taking 10 IPs between the tunnels.

    • Unusual. I’m curious though…is the public hostname resolvable over the device tunnel? I’m wondering if when the user tunnel tries to connect it is resolving to an IP address that is reachable over the device tunnel, so you have a tunnel-within-a-tunnel scenario?

  1. Always On VPN Device Tunnel Only Deployment Considerations | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Device Tunnel Status Indicator | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: