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.

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

Leave a comment

33 Comments

  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?

    Regards,
    Stefaan

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

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

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

      Reply
  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

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

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

        thanks.

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

  4. I’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?

    Reply
    • You’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. 🙂

      Reply
      • Thanks Richard. I’m always amazed at your rapid response times.
        RegisterDNS seems to be working just fine with 1709.
        Much appreciated.
        Andy.

      • Great to hear! 🙂

      • Richard, 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?

      • There’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. 🙂

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

      • My pleasure. 🙂

  5. RealWheel

     /  May 28, 2018

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

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

      Reply
    • Jason Jones

       /  September 14, 2018

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

      Reply
  6. Okay, thanks.
    I was testing on v1709, so I’ll check 1803 soon to see if that will fix it.

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

    Reply
    • ProfileXML “Servers” element (original text disappeared when posting?).

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

      Reply
  8. Richard, 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.

    Reply
  9. Ian Burnell

     /  September 4, 2018

    Interested 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

    Reply
    • It’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. 🙂

      Reply
  10. Jason Jones

     /  September 14, 2018

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

    Reply
  11. Colin

     /  October 19, 2018

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

    Reply

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: