Always On VPN Device Tunnel Does Not Connect Automatically

When configuring a Windows 10 Always On VPN device tunnel, the administrator may encounter a scenario in which the device tunnel does not connect automatically. This can occur even when ProfileXML is configured with the AlwaysOn element set to “true”.

Always On VPN Device Tunnel Does Not Connect Automatically

Manual Connection

An administrator can establish a device tunnel connection manually using rasdial.exe however, indicating no issues with connectivity or authentication that would prevent a successful automatic connection.

Always On VPN Device Tunnel Does Not Connect Automatically

Root Cause

This scenario will occur when the device tunnel configuration is applied to a Windows 10 Professional edition client.

Always On VPN Device Tunnel Does Not Connect Automatically

Device Tunnel Support

The Windows 10 Always On VPN device tunnel is supported only on Windows 10 1709 or later Enterprise edition clients that are domain-joined. To ensure the device tunnel connects automatically, upgrade to Windows 10 Enterprise 1709 or later and join it to a domain.

Always On VPN Device Tunnel Does Not Connect Automatically

Source: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#device-tunnel-requirements-and-features

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Device Tunnel Missing in the Windows UI

Deleting a Windows 10 Always On VPN Device Tunnel

Leave a comment

36 Comments

  1. Thanks Richard. I would also like to know why either a User or Device tunnel randomly fails to even *attempt* to connect (using Enterprise, of course). It would be useful to understand the mechanism whereby Windows detects that it should try to initiate a connection.

    I see this mainly after waking a laptop from sleep. Even toggling the WiFi Airplane mode doesn’t trigger it. Plugging an ethernet LAN cable in and pulling it out after about 10 seconds sometimes triggers a connection. Perhaps that’s the state change that Windows needs to see? Seems a bit over-the-top. There has to be a more reliable way.

    Reply
    • This is a known issue, and one that was recently fixed by Microsoft. I’ve got a post coming out soon on this, but make sure you have at least the February 19 update (https://support.microsoft.com/en-us/help/4487029/windows-10-update-kb4487029) installed for Windows 10 1803 and the March 1 update (https://support.microsoft.com/en-us/help/4482887) installed for Windows 10 1809. Both of those updates includes fixes for known Always On VPN issues including the ones you describe.

      Reply
      • Nóri

         /  March 16, 2019

        My experience has been that IKEv2 connections sometimes drop when you move between wireless APs. I’ve found it incredibly unreliable. Tested on many different physical and virtual machines with various versions of Windows 10. Perhaps there’s a reason for the VPNStrategy setting defaulting to SSTP. 🙂

      • Interesting observation. In theory, IKEv2 is supposed to be better at handling mobility. In practice it would seem that’s not the case. I have found that the situation is much improved with the latest updates for Windows 10 1803 and 1809 though. If you haven’t done so already, try installing the latest updates and see if that helps. But you’re right, perhaps the default setting was chosen for this reason. 😉

      • Thanks Richard. KB4487029 has helped significantly with my 1803 test rig, although when reconnecting after waking the laptop seems to randomly pick the User or Device tunnel. Additionally, if it has picked a Device tunnel it very often establishes two simultaneous connections.
        Despite this it’s a step forward as two connections are better than none.
        It’s worth noting that the more recent update (KB4489868) incorporates this fix too.

      • Great to hear. You’re right, the updates are cumulative so you just need to have KB4489868 at a minimum installed to get the update. Anything after that would also include the fixes.

      • Heath Mannering

         /  March 22, 2019

        I too am experiencing this issue of failure to connect after a sleep resume. This is when running 1803 KB4489868 as suggested above. Like Andy the issue is resolvable by completely disconnecting all network interfaces and then connecting them. I don’t seem to have issues after clean restart/boot.
        The setup I have only has the Device tunnel and no User tunnel.

        This currently is causing user frustration due to the unpredictable nature. When it works, it’s fantastic but when it doesn’t it’s buried away in the UI and non-admins can get stuck.

      • The KB4489868 was supposed to include fixes for this scenario, but I too am still experiencing this. Looks like perhaps Microsoft still has some work to do here. :/

  2. Jason Jones

     /  March 15, 2019

    The client doesn’t meet the documented requirement and hence it doesn’t work – go figure! 🙂

    Reply
  3. Brecht V

     /  March 27, 2019

    Hi Richard,
    thanks for this post, however I seem to still face this issue, after installing the updates kb4487029 and KB4489868 on my 1803, Enterprise client.
    Our rras server is a Windows Server 2019.
    Any ideas?
    Thanks,

    Reply
    • I’m still hearing reports (and experiencing this myself) that there are still tunnel establishment issues. I’m specifically facing the challenge that neither the user or device tunnel connect again after coming out of sleep/hibernate. Terribly frustrating. :/

      Reply
      • Following up on this. My report of connectivity failures might have been the result of another issue I was having with the Cisco Umbrella agent. Specifically, the NCSI would report “no Internet” intermittently. After resolving that issue I’m happy to report more stable and reliable device tunnel/user tunnel operation with the latest updates installed. 🙂

  4. Windows 10 v1903 Enterprise, and still unable to automatically connect the device tunnel.
    Have to manually create it each time
    Can’t believe this still hasn’t been resolved!

    Reply
    • Hearing a few scattered reports of similar behavior. Do you have TrustedNetworkDetection enabled? If so, can you try testing without it and see if it works?

      Reply
      • Finally got Device tunnel to auto enable – Found that the rasphone.pbk had been combined into the user Appdata locatoin for both the user tunnel and the device tunnel..
        Seperated them out and placed the Device tunnel pbk into the ProgramData location (C:\ProgramData\Microsoft\network\Connections\Pbk\rasphone.pbk)

        Next, in the registry (HKLM\System\CurrentControlSet\Services\Rasman\DeviceTunnel key I changed the “AutoTriggerProfilePhonebookPath” to the new Programdata location and the UserSID to “S-1-5-80”

        Once I did that and rebooted, the device tunnel auto connected

        User Tunnel is still a manual though

  5. Mick

     /  July 3, 2019

    Windows 10 v1903 Enterprise here as well – it just isn’t auto connecting, no errors in the event viewer or anything, seems like it just doesn’t get triggered. When I connect manually there is no problem.. ideas?

    Reply
    • Did you configure trusted network detection in your ProfileXML? If so, I’d suggest removing it and testing again to see if that’s somehow interfering with automatic connection.

      Reply
      • Mick

         /  July 3, 2019

        Thanks for the reply 🙂
        I did configure trusted network detection, just tried removing it, but still no auto connect, i had it working when i started my pilot project, but it suddenly stopped working a few months back.

      • Ok, good to know. I would also make sure the profile is not listed in the following registry key: HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Config\AutoTriggerDisabledProfilesList. If it is, remove it and test again.

      • Mick

         /  July 3, 2019

        Its not there either – its rather strange, it just stopped working suddenly, i didnt really make any connection to any update, but it happend to pretty much all my test uders

      • Unusual for sure. Any third-party security software installed on your clients? If so I’d suggest removing it and testing.

      • Mick

         /  July 3, 2019

        We use Symantec Endpoint Protection – I’ll try to take a look at that – thanks for the pointers 🙂

      • Let me know what you find!

  6. I am also seeing problems with autoconnect on 1803 and 1903. Usually disconnect/connect from wifi triggers the vpn connection again. All the clients are up to date and trustedNetworkDetection is configured. Issue seems to be wake from sleep. If i reboot the computers: user tunnel reconnects automagically after login.

    So …. sometimes always on and sometimes on demand… a bit frustrating

    Reply
  7. Hi Richard, we have an odd one, we have configured the device and this connects fine, we have defined all of our domain controllers in the routes and traffic filters.

    From the logon screen the device is unable to login a non cached user as it says domain unreachable. When logged in as a user we are able to ping the domain controllers by IP but not by name, however when doing a lookup or resolve ping -a the DNS correctly resolves the IP address.

    I have turned off the firewall and removed the antivirus and the issue still persists. Also we have noticed that if we connect the device to the domain and do an ldap query then connect to an external network and reconnect the device tunnel, the device is then able to login with non cached credentials and the domain is reachable.

    Any ideas?

    Reply
    • Unusual. Have to assume that the tunnel isn’t fully established before the user logs in? Would also have a close look at DC configuration and make sure your client VPN subnet is configured as a subnet in AD sites/services.

      Reply
      • Thank you for the response. The device tunnel is definitely up, we can see this from the vpn server as connected. Also when logged in as a user with device tunnel connected (without user tunnel) we are able to ping servers by IP but not by name. It’s odd though it works sometimes and then stops working, seems very temperamental

      • Sounds like a DNS issue then. Your clients will use the VPN server that is configured on the network interface of the RRAS server. If this server isn’t capable of resolving internal names you’ll have to use the DomainNameInformation element in ProfileXML. Also, test to see if you can resolve names via FQDN. It could simply be a missing or incorrect DNS suffix.

      • That is the strange thing, and I assumed the same, but if we look at the VPN connection (Get-NetIPConfiguration | Where-Object InterfaceAlias -eq “Device Tunnel”) we can see the two DNS/DCs listed by IP.

        If we ping the DNS/DC by IP it answers and if we open NSlookup it shows the correct NameServers and resolves all of lookups fine both host and FQDN. Pathping and tracert to IP also resolves all hop names correctly, it is literally only a normal ping that returns ping request could not find host for both hostname and FQDN.

        It’s the only issue I can see as to why the logon would be failing to contact the DC’s from the logon screen for non cached users.

        We’ve turned off all firewalls, AV and checked the interface metrics are all correct. We’ve defined single hosts /32 in the xml config as per the microsoft documentation to include all domain controllers.

        We’ve also run the portqry tool against the predefined Domains and Trusts query when connected over the device tunnel which returns all results as successful. However the device will still not logon with non cached credentials.

        Truly stumped at the moment.

      • Very strange for sure! Have you opened a support case with Microsoft on this? I’m wondering if it is a bug.

  8. * that last bit about the ldap may have been a false positive.

    Reply
  9. SHRI MUTHULINGAM

     /  September 21, 2019

    Hi
    This is to confirm that Windows 10 PRO 1809 version works well with AlwaysOnPN. Auto Connect and works as expected.
    No issues at all. It is now in out production environment.

    Reply
  1. Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell | Richard M. Hicks Consulting, Inc.

Leave a Reply to John Andre Schreuder Cancel 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: