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?
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. :/