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.

Required

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

Optional

  • 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.

Caveats

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.

Supportability

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

70 Comments

  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.

    Reply
    • 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?

      Reply
      • 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.

      Reply
  2. Eric

     /  March 30, 2020

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

    Reply
  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.

    Reply
    • 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!

      Reply
      • 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.

    Reply
  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!!

    Reply
  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?

    Reply
    • 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.

      Reply
  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.

    Reply
    • 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: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.

      Reply
      • Ryan Arnold

         /  August 27, 2020

        Awesome – thank you!

      • James

         /  July 24, 2021

        Using the update ras phonebook script seems to successfully update the phonebook file, and the device tunnel picks this up after a reboot, but for some reason the user Tunnel ignores the setting in the pbk file and remains on its previous value… any ideas why ?

      • Not sure. Is the VPN profile deployed in the all users context? If so, the rasphone.pbk will be in a different location (C:\ProgramData\Microsoft\Network\Connections\Pbk\).

  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.

    Reply
    • 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?

      Reply
  9. David

     /  November 17, 2020

    Hello Richard, I am trying to find information about Always On VPN and PCI DSS compliance. Currently my company uses Checkpoint vpn with two-factor authentication (AD password + RSA Token). Besides the fact that clients have to be manually deployed, connection process is also inconvenient for users. There is no way to manage devices and change expired user passwords. I decided to implement Always On VPN device and user tunnels or at least device tunnel and leave Checkpoint vpn instead of user tunnel. My collogues argue that this kind of setup is not secure and cannot be PCI DSS compliant as it does not use MFA. I can’t find any source about this topic on the internet. Maybe you can answer these questions:
    1) Can device tunnel with only machine certificates be accepted by PCI?
    2) Is user tunnel technically considered 2FA using NPS and Peap-TLS authentication?
    3) If it is possible to add RSA Token authentication on top of user certificate or password authentication for Always On VPN?

    Reply
    • I’m not familiar at all with the PCI/DSS specifications, so I don’t know specifically if Always On VPN would meet their compliance requirements. However, if you are using certificate authentication (device or user) I would argue that is defacto multifactor authentication. The “something you have” is the corporate-issued device and the “something you know” is the credentials to log on to the device itself. Remember, MFA is implemented to mitigate the risk of lost or stolen credentials. However, that risk is effectively mitigated when you use certs for authentication, essentially making MFA redundant.

      For the record, it is possible to integrate MFA with Always On VPN when using either MSCHAPv2 and in some cases PEAP, depending on your MFA provider.

      Reply
      • David

         /  November 24, 2020

        Thanks for reply. I agree with you about MFA definition and hopefully I can use it as an argument.
        For reference, PCI DSS has very strict rules. It requires use of MFA, jump servers and other things that complicate life. As for vpn connections, it several requirements. One of them is: “Multi-factor authentication must be used for all VPN connections”, that does not tell much.
        ( https://bit.ly/2J6CrWL )

      • I think that client authentication certificates satisfy the “spirit” of the rules, but perhaps not the “letter” of them. My guess is that it would depend on the auditor, and you know how that can go. πŸ™‚

  10. Tiifrali

     /  January 19, 2021

    Just wondering.. Has anyone succeeded to deploy a user certificate through device tunnel? πŸ™‚ If there is a new remote user who don’t yet have remote connectivity with always on user user tunnel.

    Should just ca.contoso.com .. do the trick? Or is it unsecure.

    Reply
    • That won’t work. The user must sign on to request the certificate, but the user tunnel won’t connect without the certificate. Chicken/egg. πŸ™‚

      Reply
      • Michal K.

         /  March 10, 2021

        comparing to DA, if Cert cant be used as a requirement, how would you secure the user profile connection so users cant just add the vpn connection to personal devices?

      • You’ll need to issue the certificates and ensure they are only enrolled with a TPM on your client devices.

      • MichalK

         /  March 10, 2021

        if cert cant be used to secure user profile, how would you prevent users from adding vpn connection on their personal devices?

      • If the VPN server accepts standard credentials (username/password) then nothing. That’s the advantage of using certificates for client authentication. Not only do they provide higher assurance, they can’t (easily) exported and used on another device. This ensures that VPN connections only from your managed devices can be made.

  11. Hi Richard, right now I have a deployment with User and Device Tunnel. The “Manage Out” feature is only available on the User Tunnel. Device Tunnel never works. Is that a feature or a bug?

    Reply
    • It depends. If you’ve configured only specific host routes on the device tunnel, then you’ll only be able to manage from those hosts specified in the routing configuration on the client. Also, make sure you configure DNS registration on only one of the connections (most commonly the device tunnel). Make sure any on-premises servers/workstations you want to manage out from are in the routing configuration on the device tunnel for your clients. Should work then.

      Reply
  12. Paul Kecun

     /  February 24, 2021

    Hi Richard, we’ve been making use of Always On Device Tunnels for about 12 months now without much in the way of issues.

    Everyone is on Win10 20H2 and the RRAS Server is Windows 2019 with the IKEv2 Fragmentation key set.

    Recently started to find that a number of clients are regularly disconnecting at the same time every day but I haven’t been able to find a reason – and it’s very intermittent!

    There’s no packet loss at the client end or the server end. It can’t be an idle timeout as sometimes it will disconnect when you’re actively using it and it always reconnects again within 30 seconds.

    There’s is nothing else of note in the event logs anywhere. I’ve tried increasing UDP timeouts on the firewall / RRAS (clutching at straws) but no joy.

    Client end –
    20226, RasClient
    The user SYSTEM dialed a connection named xxxxxxx which has terminated. The reason code returned on termination is 631.

    Server end –
    20272, RemoteAccess
    RoutingDomainID- {00000000-0000-0000-0000-000000000000}: CoID={xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}: The user xxxxx.xxxxxxx.xxx connected on port VPN2-248 on 23/02/2021 at 22:57 and disconnected on 24/02/2021 at 13:38. The user was active for 881 minutes 31 seconds. 41198811 bytes were sent and 30714340 bytes were received. The reason for disconnecting was administrative settings or explicit request. The tunnel used was WAN Miniport (IKEv2). The quarantine state was .

    Don’t suppose you’ve seen similar in your travels and have any suggestions?

    Reply
    • I’ve heard others report similar issues. No one specific cause has been identified though. Sometimes it is related to group policy processing. Others it was third-party security software interference (client or server).

      Reply
    • Johan Janssen

       /  September 21, 2021

      Hi Paul,

      Did you ever solve this issue? Seeing the same here and no idea what is causing it ….

      Kind regards,

      Johan

      Reply
  13. db

     /  May 8, 2021

    Hi Richard,

    I am in the process of enabling device tunnel on an existing setup. I limit the certificate ekus to a custom value.

    When I ran the this setting on the RRAS server it said the EKU is invalid for a machine certificate.

    Is EKU filtering invalid for device tunnels?

    PS U:\> Set-VpnAuthProtocol -CertificateEKUsToAccept “AlwaysOnVPN”,” AlwaysOnVPN – DeviceTunnel”
    WARNING: Configuration parameters will be modified after the Remote Access service is restarted.
    WARNING: Machine Certificate EKU filter AlwaysOnVPN is invalid
    WARNING: Machine Certificate EKU filter AlwaysOnVPN – DeviceTunnel is invalid

    Reply
  14. Panos83

     /  May 25, 2021

    Hello, i face a strange issue. When the users are working from home they can connect and stay connected. When they are working through office premises we get some random disconnects and the user moves from WiFi to Ethernet and vice versa to quickly solve the issue. What could be the problem? Always on Device Tunnel! Thank you in advance

    Reply
    • Could be any number of things. You might want to try reducing the IKE Mobility timeout value or disabling it altogether.

      Reply
      • Panos83

         /  May 27, 2021

        an event 828 also for the termination can explain something?Is there any settings to disable mobike just for testing?

      • Yes, you can disable IKE mobility on the endpoint itself by looking at advanced security properties on the VPN connection itself. You can change the outage time or simply disable it completely.

  15. Methio

     /  May 27, 2021

    Thanks for the detailed explanation on this topic. I have implemented Device Tunnel based Always on VPN, with customer requests. One thing I could not figure out is, how to add multiple routes to the tunnel so that users can reach multiple networks/subnets in the company. They are only able to reach the subnet where the device tunnel belongs to for now. Also the configuration is with Split-Tunnel enabled. Customer want to run only Device Tunnel, and requested not to add User Tunnel in the configurations. Appreciate your help, thanks.

    Reply
    • You can add multiple routes in the Microsoft Endpoint Manager UI, or if you are using custom XML you simply add multiple Route statements in your XML.

      Reply
      • Methio

         /  May 27, 2021

        I was using custom XML, and thought the “Route” is for host routes with /32, is it possible to add something like 192.168.20.0</Address and 24 in the XML file, I only saw /32 on PrefixSize. Just confirming, thanks

      • You can specify any prefix size you like. The examples here use /32, as using host routes for the device tunnel is recommended. That doesn’t prevent you from using something else if you want, though. πŸ™‚

  16. pun84

     /  June 21, 2021

    Richard,

    How do you control device tunnel access? It appears that you cannot utilize NPS firewall policies in device tunnel mode like one can with user tunnels.

    Reply
    • The quickest/easiest way is to use routing. For example, instead of routing the entire internal network over the device tunnel, simply add host routes to individual hosts as required. Commonly this would be domain controllers, but it could also be any infrastructure services that you’d want the device to connect to without a user logged on.

      Reply
      • pun84

         /  June 24, 2021

        Hi Richard,

        I already allow access via single hosts in the routing table, I realized it would be a security risk if someone was able to just add routes without some other restriction in place. I suppose its still secure since they would need administrative privileges to add additional routes.

        It just seemed a bit strange that user tunnel could work with NPS firewall while device tunnel does not.

        Thanks,

      • “Secure” here is subjective, of course. πŸ˜‰ Indeed, using routes to limit traffic isn’t the best option. Using traffic filters would be a better choice, but they are difficult to manage. Also, until recently, enabling traffic filters broke outbound management, so many organizations couldn’t accept that trade-off. You’re right though if someone can add routes on your endpoint, you’re already in trouble. If you’re looking for something more positive, have a look at traffic filters. They now support inbound and outbound rules so you can enable manage out with them.

      • pun84

         /  July 5, 2021

        Hi Richard,

        It wouldn’t let me respond to the other comment, so ill use this one. You mentioned traffic filters, I assume you are talking about the client side filters that can be applied in the profile XML. Do you think I can just apply windows firewall rules on the RRAS server using the client ip pool as the local address range?

        Thanks,

      • Correct. You can certainly try using configuring rules on the Windows firewall on the RRAS server to see if that works. I don’t see why it wouldn’t. πŸ™‚

  17. RB

     /  June 28, 2021

    Anyone found documentation on how to specify IPv6 routes in the ProfileXML?

    Reply
  18. pun84

     /  July 14, 2021

    Hi Richard,

    How do you handle the fact that device tunnel doesn’t support SSTP? We have about a 1/4 of our user working on SSTP currently while on user tunnel. If we deploy device tunnel to them I assume we will lose them as potential connected users.

    I have looked into a few things to try and remedy the issue but so far we’ve been classifying it as an endpoint ISP issue

    Thanks,

    Reply
    • Since the device tunnel only supports IKEv2, you just have to accept the limitations associated with it. Not much else you can do, really. That said, the device tunnel is only required in very specific scenarios. More often than not, if the device tunnel isn’t working, it doesn’t affect users much at all if the user tunnel is configured to use SSTP. Where you users might feel the pain is if they are trying to log on without cached credentials, such as when they have been given a new device and need to log on to the domain the first time remotely, or when they have changed their password. Other than that, the device tunnel isn’t really important.

      Reply
  19. Brandon

     /  August 23, 2021

    If we wanted to have the device tunnel use NPS, for example to force the computer to also be a member of a group to allow connection instead of just the certificate, would that be possible?

    Say for example a users laptop is stolen, what’s the best way to prevent that system from connecting to the network using device tunnel?

    (Or is certificate revocation the only way to control/prevent access of a lost device?)

    Reply
  20. Richard Gibbons

     /  November 5, 2021

    Hi Richard

    I am currently facing an issue where by we have a device and user tunnel connected however this seems to affect traffic and ping requests become timed out.
    If i just have the device tunnel connected all seems fine but as soon as i connect the user tunnel the same happens.
    I know tunnel co-existence is supported but this seems to be an issue.

    Many Thanks

    Richard

    Reply
  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.
  3. Always On VPN Class-Based Default Route and Intune | Richard M. Hicks Consulting, Inc.

Leave a Reply to Richard M. Hicks Cancel reply

%d bloggers like this: