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

57 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.

      • michael O dees

         /  February 27, 2020

        One thing that worked for me. I deleted all user tunnels, then re-created device tunnel. There might be an issue with those co-existing?

      • Should not be any issue with coexistence. I’ve deployed device tunnel and user tunnel countless times without issue. There are some cases where problems could arise, but those are typically caused by using outdated clients.

  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
  10. James

     /  December 18, 2019

    Are there any further developments? I’m on 1903 and it doesn’t auto connect sometimes from sleep and sometimes even from booting cold. A restart or disconnect / reconnect to wifi always solves the issue. Very frustrating. Almost at the point of pulling the plug on this and sticking with DA.

    Reply
  11. Are they any news about the sleep/hibernate issues?

    Reply
  12. Paddy Berger

     /  March 4, 2020

    Hi Richard, further to a comment by Andy above, I have also seen that sometimes the laptop once connected shows two device tunnels on the VPN server, if I disconnect one from VPN server it reconnects as the user correctly but doesn’t seem correct. Any updates on this? I have both device and user tunnels, sometimes working perfectly and sometimes not. A bit of hit and miss at present.

    Reply
    • This is a known issue. Hopefully Microsoft is working on it. 🙂 It’s not that there are two device tunnels, it’s that the user tunnel isn’t using EAP authentication as it is supposed to, but instead simply using the device/machine certificate instead. I’ll be sure to post something when/if Microsoft addresses this.

      Reply
    • Paddy, I’ve seen this when the user connects using an ISP (or router?) which doesn’t handle the device tunnel IKEv2 protocol properly. If the same user and same laptop visit another location with a different ISP and router it’s fine. Could this be the way the particular ISP or router handles packet fragmentation? Only guessing.

      Reply
  13. Mike

     /  March 12, 2020

    Hi Richard,

    Thanks for all the great articles. I thought I had everything working but got one problem that I cant solve, hopefully you have seen it.

    Same laptop 1903, I can login as one user and it auto connects but login as another user it does not.

    Its setup with user tunnel to Azure VNG

    The user that does not I can hit connect and it will manually connect.

    It looks to try but the event logs show 20291 events followed by 20226 event ID with reason code 829, all other message as per the manual connection except for 20225

    Do you have any ideas what the problem may be ?

    Thanks

    Reply
    • That’s quite unusual. No idea why one user would connection automatically and another cannot. I’d suggest having a look in the registry at the following location and making sure the client’s Always On VPN profile isn’t listed here.

      HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Config\AutoTriggerDisabledProfilesList

      Reply
      • Mike

         /  March 13, 2020

        Thanks for the quick reply, I have handed the laptop back now and also had another user with the same thing, so unable to check that key.

        I am not 100% sure as this is two users and I was doing a few things but the resolution I think seemed to be to delete a certificate in the user store which had been issued by MS-Organization-Access for Client Authentication – I hadn’t seen this cert before, once I did that auto connect worked again.

        It feels like it might have been trying to use that for the client auth on auto instead of the one issued by the internal CA.

        These machines in Azure AD Devices are showing twice, once as Hybrid Azure AD joined which will be from our AD sync and once from Azure AD registered.

        Similar to this post below

        I am not sure why it is registering them as these are corporate devices and not BYOD which seems to be the purpose for it, we have office 365 installed on the same machines and I cant seem to get a test machine to register the cert to re-create the problem.

        When I get another instance I will update with my findings, I would like to see it one more time before saying for sure this was the fix., if you have any thoughts though, always appreciated.

        Thanks

      • Thanks for the update. If deleting that certificate solved the problem then you likely need to enable certificate filtering as explained here: https://directaccess.richardhicks.com/2019/05/28/always-on-vpn-users-prompted-for-certificate/.

      • Mike

         /  March 19, 2020

        Legend ! This sounds like it will definitely solve my problem, I didn’t see that article as a result no mater how hard I googled the problem of multiple certs popping up. Really appreciate your help.

  14. Mike

     /  March 24, 2020

    Hi Richard,

    I am getting a radius deny with reason code 23 when trying to connect macOS using certificate.

    My radius rules are the same but I change PEAP to the Other Certificate option.

    Do you have any ideas or articles, I am stuck and can only get windows password to work.

    Thanks

    Reply
    • This would appear to be something certificate related. Are you certain the Mac client trusts the VPN and NPS server certificates? Is the PKI health and there are no issues with certificate revocation?

      Reply
      • Mike

         /  March 25, 2020

        I may be very well be doing something wrong, the same client certificate work fine on a windows machine with the same VNG and radius server so I don’t think PKI health or cert revocation is the problem.

        Its likely something I am missing on the MAC client side or radius side.

        I download the EAPTLS client, in the Radius Root Cert box I paste the base 64 code without the begin cert and end cert parts. The certificate being my internal CA certificate which is what the server certificate on the radius server was issued from and also the client certificates.

        Then I use the common folder and install the VPN and NPS certificates on the MAC in the login store, set them to trusted.

        I then export a user certificate that works fine on a windows machine and import that into the MAC and again set to trusted in the login store.

        I have also tried downloading the client in the EAPMSCHAPv2 version and using the file in the MAC folder to create the connection instead of doing it manually, then exporting my trusted root certificate from a windows machine (which is what I believe the radius root certificate refers to) and using the VPNServerRoot.cer in the common folder

        Does it sound like I am doing anything wrong with the certificates or missing anything ?

        Thanks

      • It sounds reasonable, but again I have no experience with Mac at all, so I’m not the best judge here. 🙂

      • Mike

         /  March 25, 2020

        I think my problem might be that the Local ID should be the name of the certificate which in my case is “Mike Gee” and that is what it is issued to on a windows machine.

        However when I have used that it states the specified user account does not exist on radius.

        If I use my email address in Local ID then it fails with the error 23 instead.

        I am not sure if I need to create a different certificate template for the MAC users as the Windows one will not work ?

      • I know that with Windows if you have an email address specified on the user certificate template and there’s no email address configured on the Active Directory user account it can cause problems. I typically avoid the use of the email address because there’s no guarantee it will be there. Ultimately what you really need is the UPN. Make sure that is in the Subject Alternative Name list and that it matches an Active Directory user and you should be good.

      • Mike

         /  March 25, 2020

        Seems not if I issue a certificate differently which just the common name of email address, and also put this in Local ID. So they match up, I still get the reason code 23

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

Leave a Reply to Richard M. Hicks 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: