Likely the single most common complaint about Windows 10 Always On VPN is that device tunnel or user tunnel VPN connections fail to reconnect automatically after a laptop computer wakes from sleep or hibernate. You will find many complaining about this issue and discussing various attempts at resolution on the Microsoft forums. And while Microsoft has released many fixes the last few years to improve connection reliability for Always On VPN, this one seems to continue to plague them. This issue is also prevalent with DirectAccess deployments.
Fix or Workaround?
Unfortunately, I do not have a specific fix or workaround to share that will magically resolve this ongoing issue. However, there are a few group policy settings that may prove effective in some cases.
Connected Standby Settings
To help address issues with Always On VPN connections failing after sleep or hibernate, open the group policy management console and navigate to Computer Configuration > Administrative Templates > System > Power Management > Sleep Settings and enable the following settings.
- Allow network connectivity during connected-standby (plugged in)
- Allow network connectivity during connected-standby (on battery)
Additional Information
Are you experiencing issues with Always On VPN reconnecting automatically after sleep or hibernate? Have you found an effective workaround? Share your experience in the comments below!
James Hawksworth
/ August 17, 2020We’ve had reports of certificate errors when the user then tries to manually reconnect, only a reboot helping. Doesn’t happen all the time though.
“A certificate could not be found that can be used with this Extensible Authentication Protocol.”
The certificate associated with the connection has still been present on the system, so it’s a bit of a weird one.
Richard M. Hicks
/ August 17, 2020I’ve heard the same reports, and I have a customer who is experiencing this issue now. Terribly frustrating. VPN connection works for a while, then suddenly complains that a certificate can’t be found. No changes at all. Later the connection will work, sometimes re-enrolling for the certificate helps. Regardless, it sounds like a bug to me.
victor bassey
/ August 27, 2020I have seen this issue when you have enforced CRL check and the RRAS server cannot perform crl check.
on the RRAS server run the below: Replace “mycertificatefile.cer” with a certificate issued by your CA and validate that the RRAS server can verify certificate revocation.
certutil -f –urlfetch -verify mycertificatefile.cer
victor bassey
/ August 27, 2020I use a scheduled task with a script to trigger VPN connection:
On an Event
Log – System
Source – Power Troubleshooter
Event – ID 1
The script will initiate vpn connection when the device wakes from sleep/hibernation
Richard M. Hicks
/ August 27, 2020A number of folks have said they had to resort to using scripts and scheduled tasks to kick start things. I’m curious though…how do you handle trusted network detection? I’m assuming you don’t want this script running when the client is on-premises, right? Of course if your clients are never on-premises you don’t have to worry about it I guess. 🙂
Erik
/ September 1, 2020It can be solved in a PS-script by checking the status of Get-NetConnectionProfile and checking if .NetworkCategory is “DomainAuthenticated”. If not, you are not connected on-premise then go ahead and reconnect. 🙂
Richard M. Hicks
/ September 1, 2020Thanks for the tip!
Shaun Danz
/ September 15, 2020Does your script to reconnect require login credentials to be entered into the script?
Aaron Smith
/ September 7, 2021Assuming this means the VPN profile isnt setup to use the inbuilt autoconnect feature, your relying solely on the script you have written ?
any chance you can share the script, imagine its a variation on rasdial/rasman, but would be interested to see what you have created.
luchoargu
/ November 23, 2021do you have the auto connect script to give me?
Patric K.
/ November 4, 2020Hi Richard. Have you ever experienced the same issues with DirectAccess in the past? We are fighting the exact same problem with our DA clients running on Build 1909 (MS Surface devices in all variations, DA Server is WS2016). The only workaround for us right now is to disable Standby completely. However it is annoying for our users and we are looking for a more permanent solution to this. We ended up stopping our AOVPN PoC last year because of these issues and switched back to DA which seemed a bit more reliable at the time.
Thanks & congrats on your great posts about DA/AOVPN
Richard M. Hicks
/ November 6, 2020This has historically been an issue with DirectAccess as well. No solid fix available to my knowledge either. The changes I suggest in this article can help with DirectAccess as well, but not always.
Shaun Danz
/ November 9, 2020You may want to test Windows 10 20H2. I’ve only rolled it out to 25 computers so far and it has eliminated the problems of reconnecting on all of them.
Richard M. Hicks
/ November 9, 2020Good to know! 🙂
Patric K.
/ November 9, 2020Thanks. I will test that for sure anytime soon. Hope it helps 😉 Will report back here.
Carsten
/ April 8, 2021Hi, we have upgraded to Windows 10 20H2 Build 19042.906 and the issue is still present. The client tries to connect after sleep and fails with error code 809. A reboot solves it.
Richard M. Hicks
/ April 13, 2021Sounds like this issue still persists then. :/
Richard Lewis
/ October 13, 2021I have a similar issue when using an Azure VPN gateway with IKEv2 authentication for P2S connections.
My profile XML sets the connection to always-on and when i wake from hibernation, the connection is shown as connected and ipconfig shows that i have an IP yet i have no connectivity and the gateway does not report that an IP has been assigned… of course the portal states that this list is only updated every 5 minutes but even after this time, there is no connection reported.
in order to test connectivity i have some PS that pings a remote server every few seconds and reports when the destination is unreachable with a timestamp.
I have found that after leaving this to see if it sorts itself out, it does eventually restore connectivity after between 14 and 16 minutes. after connectivity is restored it then takes a further 5 minutes before a connection becomes visible in the portal.
im really not sure what mechanism is triggered to kick this back into life so hoping someone else might have some ideas!? is it azure side or is the connection not truely reconnected after waking and just assumes it has the same connection as before without re-initiating?
ill try some more tests with wireshark running and see if it catches any initiation requests but please, any ideas, let me know 🙂
Richard M. Hicks
/ October 13, 2021This could be related to IKE Mobility and/or the network outage time values in rapshone.pbk. I’d suggest shortening those (try 5 minutes) and see if that helps. You might also want to try disabling IKE Mobility altogether to see if that works.
Sal
/ October 15, 2021Hello,
I also have this issue on VMware Per-App vpn – not auto connect after wake up or even power on, and certificate missing. Already open a case on auto connect to support team but they haven’t found any solution. I also think to apply workaround also by restarting service. For missing certificate, I cannot find any topic about this so far. Any suggestion?
regard,
Richard M. Hicks
/ October 16, 2021I’ve not used the VMWare per-app VPN.
Miguel
/ November 23, 2021Hello, Anyone have the Always On auto connect script to configure in windows task scheduler?
Marcus N
/ August 14, 2022I’ve carefully implemented all of your advice, but my AOVPN device tunnel shows up in the network adapters as “Private” (see attachment). Should it be “Domain” (i.e. DomainAuthenticated)? Also, I can’t connect to this machine from the Head Office using mstsc and either the Device Tunnel IP or the endpoint name. Is that expected behaviour?
Richard M. Hicks
/ August 26, 2022Hi Marcus,
This is a common issue. When the device tunnel is connected it should load the Domain profile, assuming it can reach domain controllers of the connection. If that’s the case, it’s common that DNS issues are causing the private or public profiles to load instead. This would obviously block outbound management.
I’d suggest setting the following registry keys on your client to see if this resolves the issue.
Key: HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Name: NegativeCachePeriod
Type: REG_DWORD
Value: 0
Key: HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
Name: AlwaysExpectDomainController
Type: REG_DWORD
Value: 1
Let me know if that helps at all!
MarcusN
/ August 28, 2022Hello, and thank you for the registry change suggestions. Before I attempt these, there is some information I forgot to provide to you when I posted the original query. On Windows 10 endpoints my Device Tunnel .xml works fine. It has specific routes and some traffic filters. These machines show the Device Tunnel correctly as DomainAuthenticated. The machines I have the problem with are Windows 11 endpoints. To get my .xml to work I had to comment out the traffic filters. Could this be the reason why the Device Tunnel on those machines does not show as DomainAuthenticated? Is there some deployment difference that I need to be aware of that requires changes to the .xml and/or .ps1 codes so that the Device Tunnel is correctly set up on both Windows 10 and Windows 11 machines?
Richard M. Hicks
/ August 29, 2022It’s possible, not I’m not sure. I haven’t done any testing with traffic filters on Windows 11 yet. If it works on Windows 10 I would expect it to work on Windows 11, however.