Always On VPN Device Tunnel Only Deployment Considerations

Always On VPN Device Tunnel Only Deployment ConsiderationsRecently I wrote about Windows 10 Always On VPN device tunnel operation and best practices, explaining its common uses cases and requirements, as well as sharing some detailed information about authentication, deployment recommendations, and best practices. I’m commonly asked if deploying Always On VPN using the device tunnel exclusively, as opposed to using it to supplement the user tunnel, is supported or recommended. I’ll address those topics in detail here.

Device Tunnel Only?

To start, yes, it is possible to deploy Windows 10 Always On VPN using only the device tunnel. In this scenario the administrator will configure full access to the network instead of limited access to domain infrastructure services and management servers.

Is It Recommended?

Generally, no. Remember, the device tunnel was designed with a specific purpose in mind, that being to provide pre-logon network connectivity to support scenarios such as logging on without cached credentials. Typically, the device tunnel is best used for its intended purpose, which is providing supplemental functionality to the user tunnel.

Deployment Considerations

The choice to implement Always On VPN using only the device tunnel is an interesting one. There are some potential advantages to this deployment model, but it is not without some serious limitations. Below I’ve listed some of the advantages and disadvantages to deploying the device tunnel alone for Windows 10 Always On VPN.


Using the device tunnel alone does have some compelling advantages over the standard two tunnel (device tunnel/user tunnel) deployment model. Consider the following.

  • Single VPN Connection – Deploying the device tunnel alone means a single VPN connection to configure, deploy, and manage on the client. This also results in less concurrent connections and, importantly, less IP addresses to allocate and provision.
  • Reduced Infrastructure – The device tunnel is authenticated using only the device certificate. This certificate check is performed directly on the Windows Server Routing and Remote Access Service (RRAS) VPN server, eliminating the requirement to deploy Network Policy Server (NPS) servers for authentication.
  • User Transparency – The device tunnel does not appear in the modern Windows UI. The user will not see this connection if they click on the network icon in the notification area. In addition, they will not see the device tunnel connection in the settings app under Network & Internet > VPN. This prevents casual users from playing with the connection settings, and potentially deleting the connection entirely. It’s not that they can’t delete the device tunnel however, it’s just not as obvious.
  • Simplified Deployment – Deploying the device tunnel is less complicated than deploying the user tunnel. The device tunnel is provisioned once to the device and available to all users. This eliminates the complexity of having to deploy the user tunnel in each individual user’s profile.


While there are some advantages to using the device tunnel by itself, this configuration is not without some serious limitations. Consider the following.

  • IKEv2 Only – The device tunnel uses the IKEv2 VPN protocol exclusively. It does not support SSTP. While IKEv2 is an excellent protocol in terms of security, it is commonly blocked by firewalls. This will prevent some users from accessing the network remotely depending on their location.
  • Limited OS Support – The device tunnel is only supported on Windows 10 Enterprise edition clients, and those clients must be joined to a domain. Arguably the device tunnel wouldn’t be necessary if the client isn’t domain joined, but some organizations have widely deployed Windows 10 Professional, which would then preclude them from being able to use the device tunnel.
  • Machine Certificate Authentication Only – The device tunnel is authenticated using only the certificate issued to the device. This means anyone who logs on to the device will have full access to the internal network. This may or may not be desirable, depending on individual requirements.
  • No Mutual Authentication – When the device tunnel is authenticated, the server performs authentication of the client, but the client does not authenticate the server. The lack of mutual authentication increases the risk of a man-in-the-middle attack.
  • CRL Checks Not Enforced – By default, RRAS does not perform certificate revocation checking for device tunnel connections. This means simply revoking a certificate won’t prevent the device from connecting. You’ll have to import the client’s device certificate into the Untrusted Certificates certificate store on each VPN server. Fortunately, there is a fix available to address this limitation, but it involves some additional configuration. See Always On VPN Device Tunnel and Certificate Revocation for more details.
  • No Support for Azure Conditional Access – Azure Conditional Access requires EAP authentication. However, the device tunnel does not use EAP but instead uses a simple device certificate check to authenticate the device.
  • No Support for Multifactor Authentication – As the device tunnel is authenticated by the RRAS VPN server directly and authentication requests are not sent to the NPS server, it is not possible to integrate MFA with the device tunnel.
  • Limited Connection Visibility – Since the device tunnel is designed for the device and not the user it does not appear in the list of active network connections in the Windows UI. There is no user-friendly connection status indicator, although the connection can be viewed using the classic network control panel applet (ncpa.cpl).


The choice to deploy Windows 10 Always On VPN using the device tunnel alone, or in conjunction with the user tunnel, is a design choice that administrators must make based on their individual requirements. Using the device tunnel alone is supported and works but has some serious drawbacks and limitations. The best experience will be found using the device tunnel as it was intended, as an optional component to provide pre-logon connectivity for an existing Always On VPN user tunnel.

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

Windows 10 Always On VPN IKEv2 Features and Limitations

Leave a comment


  1. victor bassey

     /  April 6, 2020

    Great summary of the advantages/disadvantages of deploying device tunnel only. What is the general observation recently, is deploying both tunnels together now stable (i.e deploying both user and device tunnels)

    • Always On VPN device tunnel/user tunnel coexistence has been pretty solid since the release of Windows 10 1809. However, my experience with 1909 has been rock solid all the way around. Definitely quite reliable these days. 🙂

  2. Some Guy

     /  April 6, 2020

    Not so sure about “No Mutual Authentication”. Can you expand on that one? My experience has been that IKEv2 connection attempt will most definitely fail if the server certificate doesn’t check out. That would mean the client is indeed verifying the server certificate. Are you talking about something else?

    • To some extent, yes, but it’s pretty weak compared to using EAP. Indeed the client checks the server’s certificate, but it doesn’t necessarily know that it is the correct server. It only knows that the certificate name matched and it was issued by A CA that it trusted. By contrast, the user tunnel configured with EAP allows the administrator to define the specific CA that issued the certificate.

  3. victor bassey

     /  April 13, 2020

    A client of mine is insisting on using forced tunnel for both device and user tunnel. A quick test shows the user tunnel was not connecting as client couldn’t reach the external vpn gateway hostname when device tunnel is connected. I was thinking of adding the vpn gateway hostname into internal dns, but then adds more complexity for load-balancing and clients trying to connect when on local lan…. any tips on getting both tunnel deployed as forced?

    • Yes, don’t use force tunneling on the device tunnel. 🙂 Seriously though, there’s no real point in using force tunneling on the device tunnel. If you absolutely must do this, then you’ll have to configure the user tunnel FQDN in internal DNS. Optionally you could use a different namespace for both tunnels. Regardless, you’ll also have to configure an exclusion route for the user tunnel IP address on the device tunnel.

  4. LanDI

     /  April 29, 2020

    Richard I can get device tunnel up and runing but have bever got user tunnel to work.
    been over the certs and teh settign/policies a thousand times.
    in the NPS log i always get arejection error code 7

    any thoughts/ideas?

    • Not sure, but look closely at the user certificate template. Make sure the subject is the Fully Distinguished Name and that the UPN is in the Subject Alternative Name list. I’d suggest not using email anywhere on the template as well.

  5. David

     /  May 4, 2020

    Richard – your blogs are great and have been a huge help to me. We’re moving from DA to AOVPN and we have one sticking point and thought maybe you’d be able to shed some light on it or at least confirm my suspicions. Our devices are hybrid joined, we have user and device tunnel setup and working properly. When we use the intune issued VPN certificate the device can authenticate to file shares and internal resources but not to local SQL and we receive an error on the domain controller that it cannot validate the CRL and the certificate is rejected. My suspicion is that Azure AD (AAD) is passing the login credential for the local file share, but local SQL isn’t supported by AAD for pass through authentication. Any thoughts or advice? Is there a way to ignore CRL for that particular root CA, as those certs are issued for such as short time anyway or would that not be recommended?

    • Are you using Azure conditional access? Or is the Intune issued certificate from SCEP or PFX connector?

      • David

         /  May 10, 2020

        Azure conditional access, the certificate is issued by Azure VPN.

      • David

         /  May 10, 2020

        I should have been more clear, this is the certificate I’m referring to.

      • Guidance for disabling CRL checking for Azure AD conditional certificates can be found here:

      • David Boos

         /  May 20, 2020

        I disabled CRL checking on the NPS and Alwayson servers, this is the error on the domain controller.

        The client certificate for the user AD\USERNAME is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they’re attempting to use for smartcard logon. The chain status was : The revocation function was unable to check revocation for the certificate.

      • That’s unusual. The Azure certificate should not be presented for authentication to on-premises resources, only VPN access. Did you not configure SSO using an on-premises issued user certificate then?

      • David Boos

         /  May 21, 2020

        I might be missing something there so here’s what the client has –

        1. Certificate issued to the user by internal CA as a client authentication certificate.
        2. Certificate issued by Microsoft VPN root for IKE/client authentication.
        3. Certificate issued to the machine by internal CA for client authentication certificate.

        How would I specify authentication should take place via the internal CA client auth certificate instead of the Microsoft VPN certificate?

      • With Azure CA configured, the certificate issued by Azure is used to authenticate to the VPN server. However, to authenticate against internal resources you need to configure SSO in ProfileXML. It is in the DeviceCompliance element. There you’ll define the user certificate to be used when authenticating to internal resources, which will be the user certificate issued by your internal PKI. Let me know if you need a code sample and I can provide one.

      • David Boos

         /  May 23, 2020

        If you have a code sample that would be awesome.
        Thank you, I really appreciate your help on this. I had tested it using an internal CA certificate and everything worked, switched to Azure CA and then it quit. I knew I was missing something, thank you again for pointing it out.

      • You can enable device compliance using Intune UI natively, or if you are using custom ProfileXML you can add the following to your code (angle brackets replaced because WordPress strips them out!).


        The IssuerHash is the certificate thumbprint of your root CA certificate. The EKU is the OID for Client Authentication. There’s still more to configure though. You must also publish the Azure AD certificate in Active Directory and you also have to disable CRL checking on the NPS server. Here are two good articles for reference.

      • David Boos

         /  May 26, 2020

        Thank you – that is extremely helpful. I’ll post back when I have this working properly.

      • David Boos

         /  June 8, 2020

        That fixed it for me, thanks for pointing me in the right direction.

  6. Phil

     /  May 6, 2020

    Hi Richard,

    I have this exact setup (device based AOVPN tunnel using IKEv2 machine certs, to an Azure AOVPN GW) in place for a customer at present – and the VPN connection is visible in the notification area network connection pop up.

    Client config is being deployed using the inbuilt Intune VPN client profile. I’m going to be experimenting with pushing a custom XML to try and resolve a weird windows client side routing issue (class based nonsense I suspect) – will report in if its different in that context.

    • If you are pushing out the profile using the native Intune UI and not custom XML, then it isn’t a device tunnel. The only option for deploying the device tunnel using Intune at the moment is custom XML. Also, by default, you would not see the device tunnel connection in the Windows UI via the notification area. 🙂

  7. Hi Richard,
    Can you think of any reasons why a Device Tunnel VPN wouldn’t work from a Workgroup PC?

    We are testing Device Tunnel from Domain-joined 1909 (Education) Laptops’s and thankfully the VPN appears to be very stable however we are having trouble with being able to logon to the domain.

    In troubleshooting we have dropped the Laptop off the domain with the plan to re-join the domain but now it is in a workgroup the VPN never connects. We are only using Device Tunnel – there are no NPS servers in the mix. The client still has all the required certs but it just never connects. As said, when it was domained it connected fine.


  8. Ah I found your other article

    Why didn’t I read that before dropping off the domain damn it!!

  9. Damian Murray

     /  June 9, 2020

    Hi Richard,
    we were in the process of testing AOVPN before we went into lockdown. We noticed that login time was greatly increased with a Device Tunnel – assuming this is due to the device being able to communicate with the on-premise domain controllers. We started to test with just a User Tunnel configured so users were logging in with cached credentials and so login time was improved.
    I am aware of some of the downsides to this (user will have to logon at least once while joined to the network, no unattended management) – what would your opinion be of deploying just a User Tunnel? I hadn’t thought about it (until asked) but I guess that machine based Group Policy would also not be processed?


    • The user tunnel only option is quite common. In fact, we only recommend deploying the device tunnel when it is actually required. If users must log on without cached credentials, then the device tunnel is required. If not, user tunnel only is perfectly acceptable. 🙂

      • Damian Murray

         /  June 9, 2020

        Thanks for the reply 😁
        What about machine group policy etc?

      • I believe that machine-based group policies are still processed. I’m not certain about that though. Might have to do some testing to confirm.

  10. Fernando Leiva

     /  June 17, 2020

    Hi Richard, thanks so much for your amazing blog.
    We use device tunnel and user SSTP for when IKEv2 is blocked. SSTP is a manual connection. We’ve noticed that once in a while devices are successfully connected to the device tunnel, however they cannot access any internal resources, other than DNS servers. The device tunnel status shows only connection to the internal DNS servers, and of course, event logs aren’t helpful at all. A reboot of the client usually fixes this. Do you have any insight as to what could be causing this?

    • No idea to be honest. I’ve encountered this myself on occasion. Like you’ve I’ve just rebooted and things work after that.

  11. Mahesh

     /  July 3, 2020

    Very interesting about Device tunnel.
    It will be great if you can share some details about
    1. How does the firewall port requirement looks like? What all ports to be opened for device and user tunnel.
    2.How about client IP address planning? if user is connected through user tunnel and device is already connected over device tunnel, does this scenario will have two IP address consumed …one for user and other for device?
    3.While device is getting authenticated at VPN server using certificate, why it needs to be domain joined? Where does the domain join verification is done?
    Appreciate if you can help with details for these points and really helps

    • Inbound UDP ports 500 and 4500 are required for IKEv2. The device tunnel is a separate connection and will consume an additional IP address. Plan accordingly. Domain-join requirement is a licensing requirement, not a technical one. You can only configure the device tunnel when the client is joined to the domain. It will still work if not domain-joined, but it won’t start automatically.

  12. Hi Richard,
    Thanks for such a nice article, these are really helpful.
    Couple of points disturbing me a lot, it will be great if you can help
    1. If Domain membership is mandatory for Device tunnel, what is the check point to ensure domain join? I mean how does the validity of domain join is checked?
    2.Is it possible to configure both user tunnel and device tunnel using same VPN/RRAS Servers?
    3.For VPN Clients IP allocation, its difficult to get single subnet with thousands of IPs. Can we have multiple subnet/different range if IP subnet for VPN client while internal NIC of RRAS Server is in different Subnet than the VPN client IP scope? If yes please suggest some insight.


    • There is no validation of the device’s computer account at all. The requirement for domain-join is a licensing one. The device tunnel will only automatically connect on domain-joined devices. If you deploy the device tunnel to a non-domain joined device it won’t connect automatically, but will manually. It is recommended that each VPN server assign clients with a unique subnet. You can use multiple subnets per server as long as you configure internal routing accordingly.

  13. Mike

     /  August 12, 2020

    Hi Richard, little confusion and I was wondering if you can shed some light on this type of scenario.

    What would be the best approach for shared devices.. i.e tablets for outside workers.

    So for example:
    – 200 workers who share 50-100 tablets
    – many of the users may have never signed into some of these devices
    – on any given day they can just grab a tablet that been sitting there and
    head out to the worksite.

    My worry is how will some of these users have a VPN profile if they have never logged into the device and now are out in the field.

    My approach on this was just to use device tunnels and not have to worry about user tunnels. Thoughts? better approach?

    I understand some of the security concerns in your article that’s why these RAS servers are on an isolated VLAN by themselves between firewalls.

    • Given your requirements I’d say that implementing a device tunnel only would be acceptable. The goal of this post was to consider some of the limitations of using the device tunnel only. However, there are some uses cases where it makes sense, and it sounds like that’s the case here. As long as you can accept the risks/limitations of using the device tunnel only I think it should work just fine for you. 🙂

  14. Hello,
    I’m testing with a Device and User tunnel.

    I would like the device tunnel on boot and then the user once I’m logged in.

    I’ve been having various issues with 1809 and 2004 but my real question is should both tunnels stay up at the same time or should the device drop once the user is up?

    MS stated they should both stay up (while on a call with them on something else) but I’m just wondering what other peoples experiences are?

    • Correct. The device tunnel and user tunnel are two separate and distinct connections and they should both stay up at the same time. Others have tried custom solutions to programmatically trigger the device tunnel and disable it after user logon, but that’s not something I’d recommend.

  15. Ron

     /  August 20, 2020

    reg add HKLM\SOFTWARE\Microsoft\Flyout\VPN /f /v ShowDeviceTunnelInUI /t REG_DWORD /d “1”

    Adds the device tunnel status to the top of the available network connections, simple, easy to deploy via SCCM or GPO and best of all it works. Sadly this key does not work for visibility in the pre-logon screen

  1. Always On VPN Bug in Windows 10 2004 | 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: