Always On VPN Device Tunnel Configuration Guidance Now Available

Always On VPN Device Tunnel Configuration Guidance Now AvailableWindows 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.


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.


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

Leave a comment


  1. Stefaan Pouseele

     /  November 23, 2017

    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.

    Is that correct?


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

  2. Daniel Rapp

     /  February 7, 2018

    Hi, have you happen to find any guide for deploying device tunnels with sccm, seems a bit messy with the psexec and all that..

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

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

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

%d bloggers like this: