Always On VPN Device Tunnel Status Indicator

Always On VPN Device Tunnel Status IndicatorI’ve written many articles about the Windows 10 Always On VPN device tunnel over the years. If you are not familiar with the device tunnel, it is an optional configuration that provides pre-logon connectivity for domain-joined, Enterprise edition Windows 10 clients. Although the device tunnel was designed to supplement the user tunnel connection, some administrators have deployed the device tunnel exclusively and use it for general on-premises network access. While I do not typically recommend this configuration for a variety of reasons, there are some use cases for which using the device tunnel might be acceptable.

Device Tunnel Status

For those administrators who have decided to deploy the device tunnel exclusively, a common complaint is that the device tunnel connection status does not appear in the Windows 10 notification area like other network or user tunnel connections.

Always On VPN Device Tunnel Status Indicator

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

Always On VPN Device Tunnel Status Indicator

Enable Device Tunnel Status Indicator

Fortunately, there is a simple workaround that allows for the device tunnel connection status to appear in the Windows 10 notification area. This can be done by setting the following registry value.

HKLM\SOFTWARE\Microsoft\Flyout\VPN\ShowDeviceTunnelInUI DWORD = 1

You can set this registry value using Active Directory group policy preferences or locally by running the following PowerShell command.

New-Item -Path ‘HKLM:\SOFTWARE\Microsoft\Flyout\VPN’ -Force
New-ItemProperty -Path ‘HKLM:\Software\Microsoft\Flyout\VPN\’ -Name ‘ShowDeviceTunnelInUI’ -PropertyType DWORD -Value 1 -Force

Once this registry value is set, the Always On VPN device tunnel will appear in the notification area long with other network connections.

Caveat

Although the UI will now display the connectivity status of the Always On VPN device tunnel, clicking Disconnect has no effect. This is expected and by design, as the device tunnel is deployed in the context of the system, not the user. Disconnecting the device tunnel must be performed by an administrator using the GUI tool rasphone.exe or the command line tool rasdial.exe.

Always On VPN Device Tunnel Status Indicator

Blog Post Comments

For the record, several readers of this blog had posted this workaround in the comments of this post. In the past. I declined to approve those comments because initially I did not want to encourage people to deploy the device tunnel standalone. However, recently I have had a change of heart, and decided to publish this information for those administrators who want to use the device tunnel exclusively, and would also benefit from a visual connectivity status indicator for the Windows 10 Always On VPN device tunnel. Although I still do not recommend using the device tunnel alone, I understand that it may be acceptable for others, so I have decided to release that information here.

Additional Information

Windows 10 Always On VPN Device Tunnel Only Deployment Considerations

Windows 10 Always On VPN Device Tunnel Operation and Best Practices

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 using 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

Leave a comment

11 Comments

  1. victor bassey

     /  August 27, 2020

    Great tips as always. Thank Richard!

    Reply
  2. James

     /  August 27, 2020

    Awesome this will help the helpdesk when users call in and they haven’t got to go through lots of menus to tell us if they’re connected or not.

    Reply
  3. James

     /  August 27, 2020

    I don’t actually see the HKLM\SOFTWARE\Microsoft\Flyout\ section on my laptop is that the correct location or do you have to create the full path?

    Reply
  4. Jeremy Noone

     /  August 27, 2020

    That’s awesome, great tip!

    Reply
  5. Sir thank you so much for this POST and FYI it really finishes the job, well done. God Bless you, more knowledge, wisdom, and blessing to you and your loved ones. Always continue giving additional information to I.T. Networks.

    Thank you and keep safe.

    Reply
  6. Beau

     /  August 28, 2020

    You mention you don’t recommend using the device tunnel alone, which I personally agree with. But curious to know what your opinion (read opinion, not advice) is on Device Tunnel for pre-login requirements, e.g. limited IP access for AD authentication, CRL checking, etc.

    I usually configure the Device Tunnel to allow limit access to authenticate, and then the User Tunnel allows the full range of subnets. Although I have found I need to allow the File Servers where the our user profiles are located on the Device Tunnel, or home drive and desktop mapping fails as it seems the User Tunnel isn’t connected in time.

    Reply
    • The choice to deploy the device tunnel really depends on deployment requirements. If you have domain-joined devices and you need support for logging on without cached credentials, the the device tunnel makes sense. It also helps with self-service password resets too. Best practice is to restrict access over the device tunnel to only those hosts required to support logon, and occasionally I will add infrastructure services such as systems management (SCCM, WSUS, etc.) and PKI (issuing CAs, online responders, OCSP, etc.). Full access is then granted via the user tunnel where it is more strongly authenticated.

      Reply
  7. Matthew Collins

     /  September 16, 2020

    Hi Richard, thanks for all the valuable work you have done to support everyone with this, we would be lost without you!

    I noticed that it does allow me to disconnect and reconnect the device tunnel using the GUI?

    Also whilst our device tunnel connects if it drops it takes several attempts to reconnect through many 809 errors, could this be a fragmentation issue?

    Thanks

    Matt

    Reply
    • 809 errors during a reconnect is not uncommon. This can happen because IKEv2 is trying to resume the connection that terminated previously, but the server doesn’t remember it. The client will eventually figure out that it needs to start over from the beginning, but that can take some time unfortunately. You can try lowering the default timeout to see if that helps. The setting is NetworkOutageTimeout in rasphone.pbk. You can do this manually or use my Update-Rasphone.ps1 PowerShell script here: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.

      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: