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

35 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
  8. Robert Naylor

     /  October 13, 2020

    Thanks – This has been helpful and we now know that some of the VPN connections are just stalling for some users. The VPN (machine tunnel) will connect as normal but then a while later (can be hours) it will appear to drop.

    It will still report as been connected but unable to ping anything that is routed via the VPN. Anything that is routed direct still works.

    We see similar things on the server end too – “dead session” where the session appears to be still up but can’t ping the machine and its reports no active IP connections in active details

    Any ideas?

    Reply
  9. Arovbukay

     /  October 16, 2020

    Hi Richard, we are seeing both user and device tunnel connecting successfully but in the flyout they both have the “Connect” button implying it’s not connected, we also see the status “No Internet” even though we have full connectivity. Any ideas? Thanks

    Reply
  10. Hi Richard, we use win1909 with device and user tunnel. it turns out that the device tunnel is often not disconnected. so we use in worst case twice of ip adress space, has anyone else made this experience?

    Reply
  11. Olly

     /  December 4, 2020

    Hi Richard, many thanks for this. I can see the status when in Windows but it doesn’t show at the login screen in the network popup menu. Do you know a way to get the status to appear here as well? My users have a habit of trying to log in before the AOVPN connection is fully up so end up with no connection to internal systems.
    Many thanks

    Reply
  12. Matt

     /  January 16, 2021

    Hi Richard, Thank you I have used your suggestion of the flyout reg key to have the Device tunnel to also appear with the user tunnel pre-logon. This worked great with Win 10 1909 devices. Now that we have moved to 20H2 devices neither Tunnel is available on the flyout pre-login and the above reg key is still present but to no avail. Anyone else noticed that?

    Reply
    • Both working well for me on Windows 10 20H2. Not sure why it isn’t for you to be honest. :/

      Reply
    • Simon Quist Erichstrup

       /  February 3, 2021

      OK. So now I am a bit confused. 😀

      One post and answer (Olly) indicates that the flyout reg will NOT present the Device and/or User Tunnel at the pre-logon screen,

      And the next (Matt) indicates that the flyout reg WILL present these two tunnels (or only one of them?)

      I mean, if you could see AND establish the User Tunnel manually at pre-logon I really do not see any need for the Device Tunnel at all.

      I take it that the Device Tunnels ability to auto-connect just after bootup and prior to login (so that users can logon as if they were “on-site”) is its sole purpose.

      It would be awfully nice if users were able to determine at prelogon IF their Device Tunnel was up.

      Reply
      • This registry key only enables the display of the device tunnel connection on the “modern” UI. It does not configure the profile to be displayed on the logon screen. The device tunnel will never be shown on the logon screen.

  13. Erik

     /  May 10, 2021

    Hi all,
    Simon (or anyone who knows):, have you managed to get a user tunnel connection to appear at the logon screen? “if you could see AND establish the User Tunnel manually at pre-logon”. I’ve been trying to achive this but no luck.

    Reply
    • I’m not aware of any way to do this for an Always On VPN user tunnel. I’ve only ever done this with manually configured VPN connections. I’d be curious if someone else has done this though.

      Reply
  14. Nitin

     /  June 8, 2021

    Hi All,

    I have deployed device tunnel and user tunnel.

    My understanding is that both tunnels can co-exist without any issues.
    I have an issue where the device tunnel connects fine but user tunnel keeps reconnecting and eventually gives up.

    User Tunnel works perfectly fine on it’s own.

    I am following the same idea that:

    Device Tunnel will provide access to limited resources so the user can login with domain credentials, push group policies etc.

    Once the user has logged in User Tunnel gets pushed out via Intune and it should connect giving access to full resources on the Corporate Network.

    Setup:

    All infrastructure is on-prem, certificates and vpn profile deployed using Intune, windows 10 enterprise Version 21H1.

    Has anyone come across this before ?

    Thanks.

    Reply
    • I have many times. The most common problem I see with device tunnel/user tunnel coexistence is when the VPN server’s public hostname is resolved over the device tunnel, and either it doesn’t resolve correctly or not at all. When the device tunnel is connected, ensure that Resolve-DnsName [your FQDN] is resolving to the correct IP address.

      Hope that helps!

      Reply
    • Arovbukay

       /  June 8, 2021

      also worth noting, if both Tunnels are trying to connect using IKEv2 I have seen some instances where devices only allow 1 IKEv2 connection.

      Reply
      • I’ve seen that too. The most common cause is how IKEv2 is handled by consumer home networking equipment, in my experience.

  15. Jeremy Noone

     /  August 25, 2021

    Hey Richard,

    Do you know if the tunnel status can be visible in the GUI pre login? I have it showing up for the user session. I seem to recall this used to show up pre-login, but now it’s missing.

    Reply

Leave a Reply

%d bloggers like this: