Unlike 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.
However, the device tunnel does appear in the Network Connections control panel applet (ncpa.cpl), as shown here.
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.
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
Colin
/ October 31, 2018My 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.
Colin
/ October 31, 2018Also, 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.
Richard M. Hicks
/ October 31, 2018If 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. 🙂
Richard M. Hicks
/ October 31, 2018Agreed, 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. 🙂
John
/ October 31, 2018Other 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.
Richard M. Hicks
/ November 1, 2018Very 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. :/
Tim
/ November 2, 2018Is 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?
Richard M. Hicks
/ November 2, 20183DES 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, 2018Is 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, 2018The 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?
Richard M. Hicks
/ November 9, 2018Agreed. And I have no idea why the defaults are so poor. :/
Colin
/ November 7, 2018Richard, 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.
Richard M. Hicks
/ November 9, 2018I 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! 🙂
Colin
/ November 9, 2018Thanks Richard. I already took your certificate advice when requesting the cert for SSTP. Now I will look at the cipher suite order. I look forward to your post on the IKEv2 hardening. If you have any feedback channels at Microsoft..let them know it should be more secure by default 🙂
timbo01
/ December 7, 2018Any news on the IKEv2 hardening? Microsoft’s website still doesn’t look like they are treating the issue as a priority?
Richard M. Hicks
/ December 8, 2018Post is going live on Monday. 🙂
Tim
/ November 1, 2018Does 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?
Richard M. Hicks
/ November 1, 2018The 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.
timbo01Tim
/ December 7, 2018Have there been any notable updates in 1809? I haven’t had the chance to install it yet and was wondering what progress Microsoft have made with the AOVPN experience.
Richard M. Hicks
/ December 8, 2018There were a number of improvements to address tunnel stability issues and device tunnel/user tunnel coexistence in 1809. It’s not perfect, but 1809 seems to work better than previous releases so far. 🙂
Stefan Wendrich
/ May 4, 2019after my device is comming out of standby, my user vpn connection sometimes hangs at connecting. I figured out, that there seems to be a routing and or dns issue with the device tunnel.
the device tunnel is showing as up, but ping through the tunnel is not working and also dns resolution.
Is this issue known?
Richard M. Hicks
/ May 8, 2019Yes, this is a common complaint. However, Microsoft recently release some updates that should help with this issue. Details here: https://directaccess.richardhicks.com/2019/04/17/always-on-vpn-updates-to-improve-connection-reliability/.
Matt
/ August 17, 2019Hi Richard,
I get the device tunnel is per machine and that it is always on but it would still be great if there was some indication to the user that the VPN is connected. Do you know if this is likely to come in a Windows 10 release?
Only, thing i can think of at the moment is to create my own powershell/service to handle this.
Thanks
Richard M. Hicks
/ August 18, 2019You’re right, the device tunnel is not visible to the user and this is by design. You can still view the device tunnel status by looking in the classic network control panel (ncpa.cpl) or by using PowerShell (Get-VpnConnection -AllUserConnection). I don’t expect Microsoft to add device tunnel visibility in the standard user interface any time in the future.
David
/ September 13, 2019Hi Richard, hope you are well.
Thank you for the great information you provide on your blog.
I have a deployed AOVPN solution running for a customer for several months now with no issues. I have three Windows 2016 RRAS servers and one Windows 2016 NPS server all domain joined. One thing I have noticed is that the Device Tunnel VPN connections across my three RRAS servers don’t ever seem to timeout. Obviously, with the user VPN connections these are conditioned by the settings on the NPS server with timeouts configured, but the Device Tunnel VPN is authorised on the RRAS server and I don’t know if there is a setting to configure a timeout.
The result is that I see many duplicate Device Tunnel connections on each RRAS server that can be connected for 100s of hours.
Have you had a similar experience of this?
Thanks
Dave
Richard M. Hicks
/ September 16, 2019Yes, this is quite common. It is a bug in Windows RRAS and Microsoft is aware of it. No ETA on a fix though. Only workaround available is to restart the RemoteAccess service to clear the old connections.
Ryan Young
/ January 16, 2020Hey Richard! We’re using device tunnels here with MS RRAS & we’re integrating with palo alto firewall user-id for security policy. I’m working on a feature that will leverage the task scheduler (triggered on a connection event) to run powershell that will add a windows notification upon successful aovpn connection. The idea being to notify the user of a successful connection after PAN has picked up their user ID and allowing them access to internal resources (there’s a short delay where the device is connected but is treated as manage-out only).
I want my script to be able to leverage the “Connection Status” field of Get-VpnConnection -AllUserConnection PowerShell command. As you’ve said, it will always appear as disconnected. It’s 2020, do you have any inside word as to Microsoft’s fix for this? Do you have an idea for a reliable workaround that I could use to determine if the connection is up? I tried Get-NetIPInterface, but the interface is always “connected” even when the laptop is in airplane mode.
Thanks!
Ryan
Richard M. Hicks
/ January 16, 2020Yes, that’s been resolved since Windows 10 1903. If you have older clients you might try using Test-NetConnection to an internal resource reachable over the VPN to determine connectivity. Clunky for sure, and perhaps slow, but it might work. Otherwise wait until everyone is at 1903 and you can safely rely on the Connection Status field then.