Always On VPN Device Tunnel Missing in Windows 10 UI

Always On VPN Device Tunnel Missing in Windows 10 UIUnlike DirectAccess, Always On VPN connections are provisioned to the user, not the machine. Beginning with Windows 10 release 1709 Microsoft introduced the device tunnel option to provide feature parity with DirectAccess. The device tunnel provides pre-logon network connectivity to support important deployment scenarios such as logging on without cached credentials and unattended remote systems management.

Device Tunnel Configuration

Guidance for creating and deploying a device tunnel connection can be found here. It’s important to note that the device tunnel is always on by default. Also, there can only be a single device tunnel configured per device. You must remove an existing device tunnel before configuring a new one.

Known Issues

After configuring a Windows 10 Always On VPN device tunnel the administrator may notice two anomalies. First, the device tunnel is missing in the Windows UI after it is created. Second, viewing the status of the device tunnel connection using PowerShell indicates the connection is “disconnected” even though it is connected.

Device Tunnel Missing

As you can see below, event though both a device and user tunnel have been provisioned, the Windows UI reports only a single Always On VPN connection, that being the user connection.

Always On VPN Device Tunnel Missing in Windows 10 UI

However, the device tunnel does appear in the Network Connections control panel applet (ncpa.cpl), as shown here.

Always On VPN Device Tunnel Missing in Windows 10 UI

This is expected and by design. The device tunnel is not displayed to the user in the Windows UI as it is provisioned to the machine, not the user. It appears on the Control Panel because the applet is capable of enumerating both user and system connections.

Device Tunnel Disconnected

The status of the Windows 10 Always On VPN device tunnel connection can be viewed by running the Get-VpnConnection -AllUserConnection PowerShell command. However, at the time of this writing, PowerShell always reports the connection status as “Disconnected”. This appears to be a bug; one which Microsoft is hopefully working to address.

Always On VPN Device Tunnel Missing in Windows 10 UI

Summary

The Windows 10 Always On VPN device tunnel option allows administrators to enable scenarios previously supported with DirectAccess, including logging on without cached credentials and unattended remote support. Not all deployments require a device tunnel, but it is an important option available to administrators to address specific use cases.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN RasMan Device Tunnel Failure

Deleting a Windows 10 Always On VPN Device Tunnel

 

Leave a comment

15 Comments

  1. Colin

     /  October 31, 2018

    My experience so far with the device tunnel on 1803 is this:

    I experience the PowerShell disconnected bug.
    The device tunnel is flakey. It will be fine for a while and sometimes just drop for no reason.
    If the device tunnel drops, it NEVER attempts to re-establish on its own.
    I experience oddities with excluding domain names from using tunnel DNS servers (both device and user actually)

    In summary, the device tunnel seems half baked.

    Reply
    • Colin

       /  October 31, 2018

      Also, I forgot to mention that the device tunnel manage-out has NEVER worked. I am working with Microsoft trying to figure out why.

      DNS registration is flakey as well. It sometimes registers the tunnel adapter IP and sometimes the NAT’d IP from the clients gateway etc.

      Reply
      • If you have configured a traffic filter on the device tunnel then manage out definitely won’t work. Of course if the client is registering the wrong IP address (or ins’t registering one at all) then obviously that breaks things too. Hoping this will be better in 1809. 🙂

    • Agreed, the device tunnel is still very much a work in progress. 😉 The good news is that improvements for the Windows 10 Always On VPN device tunnel are coming in 1809. I believe those fixes will be backported to 1803. 🙂

      Reply
  2. John

     /  October 31, 2018

    Other downside of the device tunnel with Always-On is that it doesn’t support SSTP, so if you’re looking for a solution that works in a variety of places where they may block ports, you’re better off with Direct Access or user tunnel so it can go over TCP 443 which most places allow out.

    Reply
    • Very true. Today, the device tunnel is limited only to IKEv2 which is commonly blocked by firewalls and there is currently not TLS-based alternative or option. :/

      Reply
      • Tim

         /  November 2, 2018

        Is there any clear documentation on how to create Main Mode and Quick Mode proposals to secure the connection better than the default settings which seem to allow the use of 3DES, SHA1 and DH Group 2? I’m sure the powershell command on the client is Set-VPNConnectionIPSecConfiguration and on the server is Set-VPNServerConfiguration or Set-VPNServerIPSecConfiguration with the -CustomPolicy switch? Do you have a beginners guide to hardening the connection as I don’t think the defaults are secure?

      • 3DES not good enough for you? 😉 So yes, the default IKEv2 parameters in Windows are pretty poor, to put it mildly. And yes, there doesn’t appear to be any good documentation to remedy this. However, I’m working to address that as we speak. I’ll be publishing some guidance for IKEv2 security configuration soon. Stay tuned!

      • Colin

         /  November 2, 2018

        Is this it? I think I tried this and it broke the tunnels so I reverted.

        I would love some guidance here as well Richard. I’m glad you are working on it.

        https://docs.microsoft.com/en-us/windows/security/identity-protection/vpn/how-to-configure-diffie-hellman-protocol-over-ikev2-vpn-connections

        Another thing to consider is you need to specify the name, so maybe you add the powershell commands to the bottom of the profile powershell script. Sounds like a bigger headache with MDM and xml profiles.

      • Colin

         /  November 2, 2018

        The website I linked to above seems to be misleading. It makes it sound like just running the two powershell commands will do it. That does not appear to be the case. They should really improve this documentation!

        This all begs the question, why is it not more secure by default? Why even make people go through this? Why not make it secure by default and have the few people that have special needs adjust theirs instead?

      • Agreed. And I have no idea why the defaults are so poor. :/

      • Colin

         /  November 7, 2018

        Richard, in addition to the guidance you are working on for the IKEv2 hardening, I (and I’m sure many others) would be interested in guidance for configuring forward secrecy (hardening) for the SSTP tunnel. Just a thought.

      • I touched upon TLS and forward secrecy for Windows RRAS and SSTP here: https://directaccess.richardhicks.com/2018/07/16/always-on-vpn-ssl-certificate-requirements-for-sstp/. Enjoy! 🙂

  3. Tim

     /  November 1, 2018

    Does anyone know what the rules are for the Device Tunnel to be active? The Device Tunnel (Split) is normally disconnected when the User Tunnel (Forced) is established, however, I have seen some circumstances where the Device Tunnel AND the User Tunnel are connected at the same time? What gives?

    Reply
    • The device tunnel should be established any time the computer is turned on and has an active Internet connection. However, there are numerous known issues (bugs) with the device tunnel today. For the best experience, make sure you are running Windows 10 v1803 with at least the September 26 Cumulative Update (https://support.microsoft.com/en-us/help/4458469/windows-10-update-kb4458469). This update addresses a specific issue with the device tunnel, but not all of them. Look for additional updates for device tunnel in 1809.

      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: