I’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.
However, the device tunnel does appear in the classic Network Connections control panel applet (ncpa.cpl).
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.
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
victor bassey
/ August 27, 2020Great tips as always. Thank Richard!
Richard M. Hicks
/ August 27, 2020My pleasure. Enjoy! 🙂
James
/ August 27, 2020Awesome 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.
James
/ August 27, 2020I 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?
Richard M. Hicks
/ August 27, 2020It’s not there by default. You’ll have to create it. The PowerShell script does this also.
Jeremy Noone
/ August 27, 2020That’s awesome, great tip!
michael
/ August 27, 2020Sir 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.
Beau
/ August 28, 2020You 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.
Richard M. Hicks
/ August 28, 2020The 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.
Matthew Collins
/ September 16, 2020Hi 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
Richard M. Hicks
/ September 18, 2020809 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.
Robert Naylor
/ October 13, 2020Thanks – 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?
Richard M. Hicks
/ October 16, 2020This is a known issue with RRAS and is quite common. Not sure why, but there are a lot of reports of similar behavior and orphaned/zombie connections left in the console. No workaround available other than restarting the RemoteAccess service or rebooting the server. I do have a PowerShell script that can be used to remove stale connections though: https://github.com/richardhicks/aovpn/blob/master/Remove-VpnConnections.ps1.
Arovbukay
/ October 16, 2020Hi 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
Richard M. Hicks
/ October 16, 2020Not sure what’s up with that, but it sounds like it could be related to Network Connectivity Status Indicator (NCSI). You’ll find some details about how it works here: https://support.microsoft.com/en-us/help/4494446/an-internet-explorer-or-edge-window-opens-when-your-computer-connects.
Matthew Green
/ November 4, 2020Some of Microsoft’s new Preview patches for this month are breaking Device tunnel auto-connect, have tested on a few machines and uninstalling the patch fixes it.
Richard M. Hicks
/ November 6, 2020Yep. This is the offending update: https://support.microsoft.com/en-us/help/4580364. Microsoft has acknowledge, no word on a fix though. To be clear this is a preview update, but preview updates typically go mainstream in a week or two.
ava (@_ITava)
/ November 17, 2020Hi 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?
Richard M. Hicks
/ November 17, 2020There are many things that can cause the device tunnel to fail. Most commonly the IKEv2 protocol is blocked by a firewall. You might also be suffering from IKEv2 fragmentation issues. See the following posts for more details.
https://directaccess.richardhicks.com/2019/02/11/always-on-vpn-and-ikev2-fragmentation/
https://directaccess.richardhicks.com/2019/04/15/always-on-vpn-ikev2-features-and-limitations/
ava (@_ITava)
/ November 18, 2020It seems I have expressed it wrong. We have the situation that both tunnels are in operation. It would be fine, if the device tunnel disconnects, when the user tunnel is active.
but it seems not to work correctly or is this by design?
maybe it’s something that keeps the device tunnel going on…
Thanks
Richard M. Hicks
/ November 24, 2020I expect something is wrong because both tunnels should be connected, assuming nothing is blocking the device tunnel (firewall, fragmentation, etc.). The device tunnels should be connected any time the machine is on, and the user tunnel connected any time a user is logged on.
Olly
/ December 4, 2020Hi 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
Richard M. Hicks
/ December 4, 2020I’m not aware of any way to get the device tunnel status to show on the logon screen unfortunately. :/
Matt
/ January 16, 2021Hi 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?
Richard M. Hicks
/ January 18, 2021Both working well for me on Windows 10 20H2. Not sure why it isn’t for you to be honest. :/
Simon Quist Erichstrup
/ February 3, 2021OK. 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.
Richard M. Hicks
/ February 5, 2021This 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.
Erik
/ May 10, 2021Hi 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.
Richard M. Hicks
/ May 14, 2021I’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.
Nitin
/ June 8, 2021Hi 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.
Richard M. Hicks
/ June 8, 2021I 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!
Arovbukay
/ June 8, 2021also worth noting, if both Tunnels are trying to connect using IKEv2 I have seen some instances where devices only allow 1 IKEv2 connection.
Richard M. Hicks
/ June 9, 2021I’ve seen that too. The most common cause is how IKEv2 is handled by consumer home networking equipment, in my experience.
Jeremy Noone
/ August 25, 2021Hey 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.
Richard M. Hicks
/ August 29, 2021Not with Always On VPN. :/
ctnetadmin
/ November 23, 2021How do you enable the indicator on windows 11
Richard M. Hicks
/ November 29, 2021Windows 11 does not show VPN connection status in the notification area as Windows 10 does. However, adding this registry key allows the device tunnel to be displayed in the VPN status page along with the user tunnel conneciton.