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”.
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.
Root Cause
This scenario will occur when the device tunnel configuration is applied to a Windows 10 Professional edition client.
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.
Additional Information
Windows 10 Always On VPN Device Tunnel Configuration using PowerShell
Windows 10 Always On VPN Device Tunnel Missing in the Windows UI
Andy Chips
/ March 14, 2019Thanks 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.
Richard M. Hicks
/ March 15, 2019This 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.
Nóri
/ March 16, 2019My 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. 🙂
Richard M. Hicks
/ March 16, 2019Interesting 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. 😉
Andy Chips
/ March 18, 2019Thanks 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.
Richard M. Hicks
/ March 19, 2019Great 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, 2019I 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.
Richard M. Hicks
/ March 24, 2019The 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. :/
Jason Jones
/ March 15, 2019The client doesn’t meet the documented requirement and hence it doesn’t work – go figure! 🙂
Richard M. Hicks
/ March 15, 2019Funny how that works, huh? 😛
Brecht V
/ March 27, 2019Hi 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,
Richard M. Hicks
/ March 28, 2019I’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. :/
Richard M. Hicks
/ April 8, 2019Following 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. 🙂
Gatt 🇬🇧🇪🇺 (@Gatt_)
/ June 1, 2019Windows 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!
Richard M. Hicks
/ June 7, 2019Hearing 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?
Gatt 🇬🇧🇪🇺 (@Gatt_)
/ June 11, 2019Finally 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
Mick
/ July 3, 2019Windows 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?
Richard M. Hicks
/ July 3, 2019Did 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.
Mick
/ July 3, 2019Thanks 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.
Richard M. Hicks
/ July 3, 2019Ok, 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, 2019Its 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
Richard M. Hicks
/ July 3, 2019Unusual for sure. Any third-party security software installed on your clients? If so I’d suggest removing it and testing.
Mick
/ July 3, 2019We use Symantec Endpoint Protection – I’ll try to take a look at that – thanks for the pointers 🙂
Richard M. Hicks
/ July 3, 2019Let me know what you find!
John Andre Schreuder
/ July 9, 2019I 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
Richard M. Hicks
/ July 9, 2019Do you see the same behavior if you remove TrustedNetworkDetection?
Shay
/ September 9, 2019Hi 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?
Richard M. Hicks
/ September 10, 2019Unusual. 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.
Shay
/ September 13, 2019Thank 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
Richard M. Hicks
/ September 16, 2019Sounds 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.
Shay
/ September 18, 2019That 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.
Richard M. Hicks
/ September 18, 2019Very 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, 2020One thing that worked for me. I deleted all user tunnels, then re-created device tunnel. There might be an issue with those co-existing?
Richard M. Hicks
/ February 28, 2020Should 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.
Shay
/ September 9, 2019* that last bit about the ldap may have been a false positive.
SHRI MUTHULINGAM
/ September 21, 2019Hi
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.
Richard M. Hicks
/ September 21, 2019Great to hear! 🙂
James
/ December 18, 2019Are 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.
Richard M. Hicks
/ December 19, 2019The issue with failing to connect when coming out of sleep/hibernate is well documented and as yet unresolved, unfortunately. :/
Armin Sattler
/ February 6, 2020Are they any news about the sleep/hibernate issues?
Richard M. Hicks
/ February 7, 2020Not that I’ve heard…
Paddy Berger
/ March 4, 2020Hi 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.
Richard M. Hicks
/ March 5, 2020This 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.
Andy Chips
/ March 6, 2020Paddy, 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.
Mike
/ March 12, 2020Hi 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
Richard M. Hicks
/ March 12, 2020That’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
Mike
/ March 13, 2020Thanks 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
https://www.reddit.com/r/sysadmin/comments/862gzz/unknown_certificate_in_windows_10_certificate/
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
Richard M. Hicks
/ March 18, 2020Thanks 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, 2020Legend ! 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.
Mike
/ March 24, 2020Hi 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
Richard M. Hicks
/ March 24, 2020This 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?
Mike
/ March 25, 2020I 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
Richard M. Hicks
/ March 26, 2020It sounds reasonable, but again I have no experience with Mac at all, so I’m not the best judge here. 🙂
Mike
/ March 25, 2020I 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 ?
Richard M. Hicks
/ March 26, 2020I 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, 2020Seems 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
James
/ April 8, 2020Hello,
Anyone experienced on first boot up of a computer with a VPN profile where it fails to connect automatically.This is a force tunnel connection.
The event log says (in order):
20223 – The user SYSTEM has successfully established a link to the Remote Access Server
20224 – The link to the Remote Access Server has been established by user SYSTEM
20291 – AlwaysOnVPNFT requires attention.
20227 – The user SYSTEM dialed a connection named AlwaysOnVPNFT which has failed. The error code returned on failure is 87.
It attempts this 3 times then gives up.
If you then run rasdial to manually dial it, it will connect fine so seems to be at first boot up. Any way to troubleshoot what error 87 is?
Many thanks.
Richard M. Hicks
/ April 8, 2020Not seen that specific issue myself…
Jason Jones
/ April 9, 2020Pretty sure we don’t support Device Tunnel in FT mode
Richard M. Hicks
/ April 10, 2020Using force tunnel for the device tunnel is kind of pointless anyway, but if that’s documented somewhere that would be most helpful. 🙂
James
/ April 11, 2020Well force tunnel works fine when it is connected and the speed is also fine.
Unfortunately when it comes to government there isn’t any clear guidance (no one wants to say otherwise) on whether to use split/force tunnel so force tunnel is a safer option to have everything checked by our own dns/firewall.
I get the advantages of split tunnel for bandwidth reasons, so I’m looking at the exclusion routes into the XML profile for 365.
Ben Taylor
/ April 17, 2020Thanks for the great blog Richard. Unfortunately, like many others, I am having serious problems putting AOVPN into production. We are currently running a pilot but im afraid that we will have to abandon the project due to the unreliability issues.
I have 2 main problems (just testing with user tunnel at the moment):
Intermittent failure to connect on bootup.
ALWAYS fails to connect after resuming from sleep.
In both cases I get error 812. I’ve tried absolutely everything I can think of to resolve it to no avail.
I’m using an NPS server which is sitting in the same subnet as my RRAS servers (using NLB as per Microsoft’s guide).
Client is running Windows 10 Enterprise 1909 build 18363.778
Server is 2016 with all the latest updates installed.
Any help greatly appreciated..
Richard M. Hicks
/ April 17, 2020Hi Ben. Always On VPN no doubt has it’s shortcomings, but it’s gotten much better in the last year. If you have more than one RRAS server I would avoid using NLB. You should also consider using Windows Server 2019. If you are using IKEv2 it’s absolutely vital.
The reconnect from sleep/hibernate is still unresolved, but there are things you can do to help. Disabling power management on the NIC is a good start.
Semjon Lick
/ April 20, 2020Dear Richard,
i have a little problem with the coexistence of my device and user tunnel, i am using the following setup:
– Device Tunnel over ikev2 and computer certificate, it connects without problems before user login
– User Tunnel over SSTP and user certificate requesting access over an NPS
My Problem at this point is, i can connect the device tunnel OR the user tunnel without any problem, BUT as soon one is connected, the other cant connect and the error says “cant connect to the RAS server”, did you ever seen this kind of problem?
I would like to have on of the following solutions:
1. Device tunnel connects before login and stays connected until the user logs in, after that i want the device tunnel to stay disconnected, because the user tunnel needs to be connected
2. Device tunnel connects before login and stays connected even if the user logs in, BUT the user tunnel needs to connect also as soon the user logs in.
additional information.
Windows 10 enterprise 1909
I hope you can help me, thanks in advance and greetings 🙂
Richard M. Hicks
/ April 22, 2020No question that both tunnels should be able to co-exist. If that’s not happening it must be a configuration issue. I’m curious though…what happens when you try to launch the device tunnel connection using rasphone.exe? What is the error message?
Semjon Lick
/ April 22, 2020Hi Richard,
seems like my reply didnt uploaded, ill try again 🙂
Thanks for the reply, it looks like an DNS problem to me, if one of the VPNs is connected and i try to connect the second one using rasdial, i get the following error:
RAS-Error 868 – The Remoteconnection could not be established, because the name of the RAS-Server could not be resolved.
i tried to paste my configurations here, but maybe they are too long for an comment
Thanks in adanve and greetings
Semjon
Richard M. Hicks
/ April 23, 2020No question. Should be easy enough to sort out though. Once you get DNS working again I expect it should work fine. 🙂
Shri S Muthulingam
/ April 24, 2020Hi James
Can you please advise me how you did you deploy both tunnels (device/ users) to users devices? Via Powershell ? If so can you share with me,
Thank you
James Reese
/ April 22, 2020I have found that disabling trusted network detection on both tunnels solved this problem for me. The tunnels were able to detect my corporate network through each other, so I would sometimes see the user tunnel active but not the device, and vice versa. You get more error logs generated on the client since it tries to connect even when you’re connected the corporate network, but I can live with that. I can’t live with tunnels not connecting.
Ryan Berenji
/ July 29, 2020Hello,
I have always on device tunnels working. They hook up prelogin, and non cached users can find a login server and successfully login. From that session I can ping and access internal resources. However from the internal network I cannot ping devices, push patches, etc to VPN connected devices. I suspect this is a routing issue and that internal hosts don’t know how to get to the VPN subnet. If that’s the case would I need to add a route to my internal core switch to send traffic intended for that subnet via the external facing network adapter on my VPN server?
Thanks!
Ryan
Richard M. Hicks
/ July 29, 2020Yes, sounds like a routing issue. As this is a device tunnel, did you configure individual host routes to internal resources? Or are you using the device tunnel as a full access connection and have routed all internal subnets over the connection?
Ryan Berenji
/ August 6, 2020Richard,
Doing some more testing, I realized that when I manually connect with a test profile, using a user certificate, I can ping that VPN connected device from the internal network (only via IP not by DNS name). I cannot ping that same device when using the alwaysON vpn profile. Any idea what could be the issue?
Richard M. Hicks
/ August 6, 2020Did you define any traffic filters for your Always On VPN profile?
Ryan Berenji
/ August 6, 2020I did. Is it possible to post my XML? I’ve tried a few times and It doesn’t seem to get passed moderation.
Richard M. Hicks
/ August 6, 2020That’s likely the issue. When you define a traffic filter (even just one) then ALL inbound traffic to the client is denied. I think this was resolved in 2004, but I’m not certain. If you’re using something other than Windows 10 2004 that’s definitely the issue. You’ll need to remove the traffic filter to restore manage out connectivity from on-premises servers/workstations. Happy to look at your XML though. I’d suggest using something like GitHub or Pastbin. You could also reach out to me directly via email or any of the contact forms on this site and I’ll be happy to have a look. 🙂
Ryan Berenji
/ August 10, 2020Richard,
I wanted to give you a heads up that even though my win10ent is 2004, I had to remove the traffic filters. Once I did it fired right up. For some reason 2 of my internal management hosts try to go out the public interface. Hardcoding them in hosts fixes this, but would like to resolve it in a more “natural way”.
Richard M. Hicks
/ August 10, 2020That’s odd. It was my understanding that manage out with traffic filters was fixed in Windows 10 2004, but I haven’t done any testing to confirm. It might be that additional configuration is required, but I’m not sure. I’m following up with Microsoft on this as we speak. When you say your management hosts try to go out the public interface, are you talking about the IP address used to connect to the remote VPN client? There are some issues that have to do with improper DNS registration that could be the cause.
Ryan Berenji
/ August 10, 2020From the device tunnel, when I ping two of my internal management hosts, it goes out the local network rather than over my device tunnel. I am using a split tunnel, and pinging any other internal device works with no problem. The last issue I am dealing with is DNS not updating when the same device establishes a new connection. I have the registerDNS switch set to true on VPN XML.
Richard M. Hicks
/ August 10, 2020That’s quite strange, and sounds like a routing issue. Have you confirmed that routes exist on the client that would forward this traffic over the tunnel?
Ryan Berenji
/ August 12, 2020Richard,
I can confirm that routes exist on the client that send internal subnet traffic over the IP assigned to the externally connected device. Other internal hosts ping with no issue, just two internal servers attempt to go out the public interface.
The DNS issue is occurring with internal DNS registration. I deleted the entry in DNS to try and force it to register. Since doing this, the client won’t register to DNS. I get the 8019 error when attempting to regster DNS.
Richard M. Hicks
/ August 13, 2020That’s quite unusual. Not sure what’s up there to be honest. It’s possible that you have conflicting routes, or that another route has preference. Not sure why that would be though. As for DNS registration, that’s always been a challenge with Always On VPN. Sometimes it works well, others not so much. Have a close look at the event log on your DNS servers to see if that yields any clue. Also, you may need to take some network traces on your DNS servers to see if the traffic is making it from your VPN clients to the DNS server(s) in the first place.
Ryan Berenji
/ August 10, 2020When running a ipconfig /registerdns from the VPN connected device, I noticed there was event ID 8019 logged. At least I have that thread to pull on as to why it isn’t updating the DNS entry when the IP changes.
Richard M. Hicks
/ August 10, 2020Is this specifically for registering with internal DNS servers? This error is expected when the client attempts to register to public DNS servers.
Wes
/ September 7, 2020Gosh, here I was thinking it was probably finally time to see about replacing DA with device tunnel AOVPN… But it looks like it’s still surprisingly buggy years later… hrm…
David
/ October 11, 2020I have another issue with just 1 user, and which I couldn’t find any info regarding the problem. AlwaysOnVPN gives Access is denied error. Event viewer on client shows event id 20227 – “The user xxxxx\xxxx dialed a connection named PA_AlwaysOnVPN which has failed. The error code returned on failure is 5.” NPS server shows that user was granted access, while on RAS server event viewer shows – “The user xxxx@xxxxx connected on port VPN2-499 on date at time and disconnected on date at time. The user was active for 0 minutes 0 seconds. 0 bytes were sent and 3284 bytes were received. The reason for disconnecting was administrative settings or explicit request. The tunnel used was WAN Miniport (IKEv2). The quarantine state was .” Rasdial on user’s machine shows –
Connecting to PA_AlwaysOnVPN…
Verifying username and password…
Registering your computer on the network…Access is denied.
Do you have any idea pls?
Richard M. Hicks
/ October 16, 2020That’s quite strange. Have you tried deleting the profile and re-creating it? Also, does the user have any issues on another device?
Lasse Meggele
/ February 24, 2021Did you ever find a solotion to this problem? I have a computer with the exact same error, and I can’t find any possible solution. Neither to why the client gets an Access Denied Error – Access to what?
Adam Dickinson
/ January 26, 2021I have a super weird one. Clients are on Win 10 Enterprise but have both DA and AlwaysOn (user tunnels) deployed.
When AlwaysOn tries to connect while DirectAccess is connected, it gives that same ‘Element not found’ error. If I disconnect DirectAccess, AlwaysOn works fine. Any thoughts?
Appreciate all of the fantastic content as always!
Richard M. Hicks
/ January 26, 2021Very strange! Did you define the DomainNameInformation element in your XML? Or did you configure NRPT if you are using Intune?
Adam
/ January 26, 2021Deploying via Intune and didn’t configure NRPT.
I do have split tunneling/trusted network detection/DNS suffix configured
Richard M. Hicks
/ January 29, 2021That’s very odd. Not sure why that’s happening, to be honest. It’s certainly not something I’ve seen myself yet. :/
Christian
/ June 17, 2021Hi! I’ve been spending DAYS to figure this one out. Got the same “Element Not Found” while doing the RASDIAL while DA was active. It turns out that the FQDN i’m dialing (For instance: ipsec.contoso.com was covered by DA NRPT rules, so it translated the address to IPv6, which the VPN could not dial, so I made an exception to the NRPT rules to make sure that the “ipsec.contoso.com” was not translated into IPv6 and now it works flawlessly. As always the error messages from Microsoft are only valuable as Google search terms and not for actual troubleshooting!
Richard M. Hicks
/ June 17, 2021Not a helpful error message for sure. 🙂
Lufaa
/ February 15, 2021Hi Richard, I’ve been working on our Always On VPN no for more then a week and manually al is working fine. The “only” problem I have is not works automatically. When viewing the eventlog there is no initiating of a vpn what so ever at boot or logon to the system.
Any thoughts?
Kind regards
Richard M. Hicks
/ February 15, 2021Could be any number of things. First, make sure the configuration is actually an “always on” connection. XML will have [AlwaysOn]true[/AlwaysOn]. Also, make sure your trusted network detection configuration is correct. Finally, make sure your VPN connection isn’t listed in the following registry key: HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Config\AutoTriggerDisabledProfilesList.
Ronald
/ March 2, 2021Hi Richard. Thank you for your great work about AlwaysOn VPN. We set it up and tested it on two laptops and it worked great. After some time it stopped working and I found out, that the configuration is lost on the laptop. When I reconfigure it (by removing the tunnel and creating it again with the powershell script) it works immediatly. Sometimes even after one single reboot the configuration is lost again. Do you have an idea how this can happen?
Kind regards
Richard M. Hicks
/ March 3, 2021That’s quite unusual, and I’m not sure why that would be happening, especially if you configured it locally using PowerShell. The only thing I can think of is that something is deleting the rasphone.bpk file. Why, I have no idea. I’d suggest starting there though.
DB
/ May 14, 2021Is the autoconnect available on PRO 1809 or greater? I wasn’t able to get autoconnect to work on 20H2.
Anyone able to confirm?
Thanks,
Richard M. Hicks
/ May 14, 2021Not for the device tunnel. You just have Enterprise Edition for the device tunnel to connect automatically. The device must also be joined to a domain.
Martin Bufton
/ November 11, 2021I’m seeing my Win 11 AOVPN not auto dialling on an Enterprise build is anyone else seeing this?
Richard M. Hicks
/ November 16, 2021Windows 11 has been working ok for me, for the most part. Some issues with getting profiles deployed correctly, both with PowerShell and Intune. Microsoft is close to fixing that though.
William
/ January 24, 2024Did you ever find out what the issue was? I’m deploying a AOVPN System VPN through intune (Custom profile). Autoconnects fine with the W10 devices, but with W11, it keeps quiet. As user however I’m able to start the VPN, although the VPN connection is definitely installed in System context.
Muhammed Popoola
/ March 21, 2023Hi Richard.
We deployed Autopilot hybrid ad joined devices over Always on VPN. The OS is Win11 Pro and we are using Device Tunnel for VPN connection.
The issue is that is that the Device tunnel never connects automatically for the User’s first logon. To get around this, we configured local admin account via intune, sign in and then manually make the connection. Then switch user for User to log in. Even then the connect drops intermittently.
Can you please advice on what to do to make sure that the tunnel connects automatically and stays on?
Richard M. Hicks
/ March 21, 2023It’s always best to use Windows Enterprise Edition with autopilot and hybrid Azure AD join. However, if that’s unavoidable, there is a workaround. It’s not an elegant one, but it does work. Specifically, you will have to temporarily install the KMS activation key so the device tunnel will connect automatically. Once the first log-on is successful you will need to revert to the original embedded key. This is required for step-up upgrade later. You can find all the details along with a PowerShell script here.
https://directaccess.richardhicks.com/2021/04/19/always-on-vpn-and-autopilot-hybrid-azure-ad-join/
Have fun! 🙂
Grant
/ July 7, 2023Always On VPN implemented (SSTP) user certificate based with certificates issues from internal Microsoft CA. This is working perfectly for all devices except Surface Laptop 2 devices (Latest version Windows 10 Enterprise 22H2). When a user clicks on “disconnect” the connection is disconnected but the WiFi connection drops then Wifi reestablishes. When attempted reconnect to VPN error message “can’t connect to VPN A connection to the remote computer could not be established”. Only solution thus far: logout/login or reboot. Have you seen this ? I suspect driver issue with Marvell AVASTAR Wireless-AC Network Controller. FYI: by disabling and reenabling WAN mini port drivers has no effect. IF only we could hide the “disconnect:” button for Windows 10, apparently this only works for Windows 11 future releases to hide the button.
Richard M. Hicks
/ July 10, 2023I’ve not heard anyone with this issue, unfortunately. It does sound like a firmware issue, though. I’d make sure both firmware and device drivers are fully updated. Indeed, it would be nice if Microsoft allows us to disable the disconnect button for Windows 10 Always On VPN profiles as they do in Windows 11. We’ll have to wait and see, though. 🙂
Maximilian Mueller
/ January 15, 2024Hi Richard,
thanks for you work. I have one question:
Any ideas how to deploy always on vpn for azure only joined devices? Our device tunnel with hybrid joined devices is working fine but we are looking into aajd only at this point.
Regards Max
Richard M. Hicks
/ January 15, 2024You would have to use Intune for that. You would also need to deliver certificates via Intune in addition to the VPN profile. For that you’ll need the Intune certificate connector.
https://learn.microsoft.com/en-us/mem/intune/protect/certificate-connector-overview
FYI, I recommend using PKCS over SCEP. Much simpler and more secure. 🙂
https://learn.microsoft.com/en-us/mem/intune/protect/certificates-pfx-configure