Always On VPN not always reconnecting after standby

2019-02-21

Question

_{Thursday, February 21, 2019 12:03 PM | 1 vote}

Hello,

Hopefully someone can help me with an Always On VPN issue.
At our company and some customers we have implemented Always On VPN for the Windows 10 devices.
The connection works as expected but in many cases the VPN connection will not auto reconnect after going to standby. The status will be "Connecting".

Log off/log on or restart fixes the issue and many times what also works is going to Settings - Network and Internet - VPN, there you go to the VPN connection and connect from there. Connecting will be setup in an instance again.

Does someone has a solution for this so that the connection will be established automatically again?

Some extra info:

This problem doesn't always seems to be, but many times it will.
Windows 10 builds we use are 1803 and 1809.
VPN environment is bases on RAS server following Microsoft documentation with exception that the RAS server has both netwerk adapters in the DMZ.
We have the issue on all clients from different brands and models.
When the problem exist on one or more clients after standby, other clients can still connect without issues.

All replies (45)

_{Wednesday, February 5, 2020 11:08 PM ✅Answered}

I can now finally confirm that for Windows 10 1809, 1903 and 1909 a fix has been made and being distributed with the latest or comming cumulative update. To be clear the update is a part of 1909 with cumulative update from January, and for the older builds (which I didn't test) it should be in January or February.

After many times troubleshooting with Microsoft and waiting for a long time, I tested this and did not had any issues.

As mentioned by SmK5 and maybe also for JLTBravo, issues with VPN could still occur based on hardware/driver settings like power management but is not the cause of the issue I posted here, but good to know and thanks for sharing.

Thank you all for your patients and I hope that you will find the issue resolved.

_{Monday, February 25, 2019 1:38 AM}

Hi,

I would suggest you configure VPN auto-triggered profile option.

Please refer to the link below:

/en-us/windows/security/identity-protection/vpn/vpn-auto-trigger-profile

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]

_{Monday, February 25, 2019 2:19 PM}

Hello Travis,

Thank you for the reply. The configuration contains Always On VPN auto trigger.
But it seems that the issue is resolved after a complete update scan en installation of the RAS server. After rebooting we didn't see issues yet with connection losses and reconnecting issues after standby.

We did this last Thursday and no complains yet and this seems to be the solution.

Best regards

Ronald

_{Tuesday, February 26, 2019 7:34 AM}

Hi,

Good to hear that you have solved this issue by yourself. In addition, thanks for sharing your solution in the forum as it would be helpful to anyone who encounters similar issues.
If there is anything else we can do for you, please feel free to post in the forum.

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]

_{Sunday, March 17, 2019 4:53 PM}

Hello,

Unfortunately I was to quick with the thinking I found the solution. The issue still exist.

Many times when the computer comes back from standby, Always On VPN is nog connected. Sometimes it says connecting for a while but without success, other times it doesn't say anything. When I click the connect button, sometimes the connection comes back and other times I says connecting for a while and then stops.

I also notice that I still have users with multiple connections from the same computer. It seems that the RAS server doesn't notice that the connection was disconnected and the connection time keep going up. I have seen connection times for multiple days while a new connection for a couple of hours is also visible. The last connection is the active one and all others are old and not valid.

Anyone has an idea?

Best regards,

Ronald

_{Tuesday, March 19, 2019 8:21 AM}

Hi,

I understand your frustrations. I believe that troubleshoot the issue requires some hands on access.

My suggestion is to contact Microsoft Support to get them involved in checking your configuration.

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]

_{Thursday, April 18, 2019 9:13 AM}

Thank you Travis.

Ik just created a premier support ticket and will update this thread when I have some results.

_{Friday, April 19, 2019 6:05 AM}

Hi,

Thank you in advance for sharing the solution.

Looking forward to your reply.

Best regards,

Travis

Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]

_{Saturday, April 27, 2019 12:13 PM}

any news here ? we have the same behavior.

I find out, if i manually click on connect - it doesnt work. It hangs at connecting to...

After doing an ipconfig /flushdns it works. We use also a device vpn tunnel.

Has someone else those problems ?

_{Friday, June 7, 2019 7:14 AM}

We have them all for like 15%/20% of the users:

- VPN not reconnecting.

- Connection breaking every few minutes/seconds for SSTP & IKEv2

- VPN stuck in connecting state.

The documentation & error logging is very light on internal working of the VPN. Not much troubleshooting you can do. I think we tried about 10 configs by now. Direct Access was much better. I think the flaw is really in windows 10/windows server because it both for ikev2 & sstp.

_{Monday, June 24, 2019 8:50 AM}

I'm still busy with Microsoft trying to fix the issue.

I do have a workarround, and that is to set the protocol to IKEv2 with fallback to SSTP. This can be done by setting this in the %appdata%\Microsoft\Network\Connections\Pbk\rasphone.pbk file the VPNStrategy to 8.

This way VPN first tries to connect with IKEv2, which will fail (still not found out why) and after this it will try SSTP, which will connect. It doesn't matter which order you choose for the VPNStrategy, the first one will fail and the second one will work.

Like I said, this is a workarround, and you still have to wait for the first protocol to fail which takes some time, before the second one gets connected.

When I get a better result for this issue, I will let you all know.

_{Monday, June 24, 2019 6:36 PM}

Normaly you don't need to set the rasphone.pbk. If the clïent is set to vpn type automatic, it first tries IKEv2 then STTP. The fallback is working without any rasphone.pbk. The behaviour is also in the documentation.

Some other stuff. In server 2019, turning off firewall seems to break the VPN connectivity. Also make sure you review the firewall inboud & outbound because not all ports are enabled that are required in the documentation.

_{Tuesday, August 13, 2019 12:01 PM | 1 vote}

So after a while here an update.

The issue with not being able to reconnect after standby still exist. The development team from Microsoft knows about the issue and are busy with the solution.

In the mean time you could use the workaround by adding the ip-adres and name of the vpn connection to the host file. This makes sure the vpn connection name is always resolvable and will not have the issue again.

Next to that I can confirm that Microsoft fixed the issue about automatically changing the VPN strategy to a different value, when the connection failed. This is fixed in the insider preview build available at this moment. I expect that this will be implemented soon in one of the next updates or new build.

As soon as I here something more about the reconnecting issue I will post it here.

_{Tuesday, August 20, 2019 6:17 AM}

Thanks for the info.

The workaround: **In the mean time you could use the workaround by adding the ip-adres and name of the vpn connection to the host file. This makes sure the vpn connection name is always resolvable and will not have the issue again. **

Does this workaround help for the reconnect after sleep issues?

I'll give it a try, I am having the same issues on 1803, 1809 and 1903.

//John

_{Friday, October 4, 2019 12:15 PM}

Thanks for the updates, I am following this also, mostly with the issue of no auto connection after sleep/hibernation etc.

Hopefully some updates make auto triggers a bit more reliable.

Thanks

_{Monday, October 21, 2019 8:02 AM}

Hi John,

Yes, adding the values to the host files is a tested workarround to get reconnected after sleep.

_{Monday, October 21, 2019 8:06 AM | 2 votes}

Another update. Microsoft had issued a test patch to see how it goes. We are not 100% sure yet but it seems this solves the issue. I will get this tested a little futher with Microsoft but they let me know that this patch will probably only be available in January or Februari of next year because of the priority for the new Windows 10 build release. As soon as the new Windows 10 build has been successfully enrolled and no major issues do exist, they will continue adding the patch for Always On VPN.

I soon as the patch will be released I will update this post again. Probably it's going to be released in a cumulative update.

_{Friday, November 15, 2019 8:36 AM}

Any news on this? We are experiencing the same issue.

If there is an hotfix, we would like to test this too. Could you please share?

_{Monday, November 18, 2019 10:10 AM}

We experience similar issues - please let me know if you have any updates on the patch.

_{Wednesday, November 27, 2019 2:07 AM}

I'm having exactly the same issue as you. Sometimes the VPN connection status won't even be connecting, it will be in a fully disconnected state and you have to manually connect for it to work again - even a reboot wont make it connect again automatically.

It's so frustrating and unreliable. I will try the host file fix and report back if that works for me as it has for others.

Does anyone have any more information about this? I wonder if it's fixed in 1909..

_{Tuesday, December 10, 2019 7:21 PM}

Having these same issues and it's preventing us from deploying AOVPN at my firm. (We are stuck on Direct Access!) One fix is disabling all sleep, hibernate, and fast startup. Our technology committee finds that unacceptable, since updates are installing on full shutdown now. We have an open ticket with Microsoft, working on it for weeks, and they claim they do not know anything about an unpublished hotfix when we shared this thread.

We might go with the ugly host file fix. Has this worked for everyone here waiting for the issue and hotfix to become publically acknowledged?

_{Wednesday, December 18, 2019 10:47 PM | 1 vote}

Host file fix doesn't work for me.

_{Friday, January 17, 2020 4:22 PM}

Host file fix doesn't work for me.

That makes 2 of us, host file "fix" doesn't work either. I had MS support read this thread, and they say there is no unpublished hotfix as one of the commenters previously claimed and did not share further details. They want us to upgrade the clients to ver 1909 and see if that fixes the issue. Being an SCCM shop with the least privilege model in place, this is going to take my team a few weeks. I will report back if there is any progress.

_{Friday, January 17, 2020 9:26 PM}

Host file did not make any difference for me.

I am running 1909 and the issue is still present.

I have turned off power management of the wireless adapter and it appears to occur less often. I suppose you could always tell the end user to disconnect from wireless before putting it to sleep.

The only way I have been able to reproduce the bug somewhat consistently is to adjust the wireless adapter power settings so that it can go into low power, connect to wifi hotspot, put the device to sleep, turn off hotspot, wake it back up, and then connect to different wifi.

On our Dells I disabled power management via compliance settings for all devices that start with PCI\VEN_8086&DEV_24

Namespace: root\wmi

Class: MSPower_DeviceEnable

Property: Enable

Query: InstanceName Like 'PCI\VEN_8086&DEV_24%'

Compliance rule condition: Equals False

_{Tuesday, February 18, 2020 8:56 PM}

Still not working on 1909 with February 11, 2020—KB4532693

_{Monday, February 24, 2020 4:05 PM}

RonaldBe - Appreciate the follow up post. Do you know the specific KB so we can test and confirm? Thank you.

_{Tuesday, February 25, 2020 12:38 AM}

I am also interested to know the specific KB.

_{Tuesday, March 3, 2020 8:13 PM}

Still not working on 1909 with February 27, 2020—KB4535996

The issue is now worse after installing update KB4535996.

After updating, the issue is no longer specific to standby and even occurs after restarts

_{Monday, March 9, 2020 2:56 PM}

Still not working on 1909 with February 27, 2020—KB4535996

The issue is now worse after installing update KB4535996.

After updating, the issue is no longer specific to standby and even occurs after restarts

Thank you for the update. I have a ticket open with MS for over 2 months now, and all they do is ask for logs, and the logs show nothing when AOVPN fails to connect.

I have found the least problems occur when disabling fast startup and hybrid power saving modes. Not ideal solution at all.

_{Friday, March 13, 2020 8:12 AM}

hi people

having the same issue here. the response from the microsoft engineer was that this is by design. without giving a link to a public documentation because he found this information on internal sites only.

they should rename this feature and call it "sometimes on vpn" instead of "always on vpn".

this is really bad... what kind of workarounds did you implement?

kind regards

_{Wednesday, March 25, 2020 8:07 AM}

We struggled with this issue as well a year ago when we initially set up Always On VPN (which we now internally call Always Gone VPN).

Our workaround was to create a scheduled task on our laptops (through GPO) that executes rasdial.exe "connection name". This scheduled task triggers on certain event log entries:

Log file: System
Source: Microsoft-Windows-Power-Troubleshooter
Event ID: 1

and

Log file: Microsoft-Windows-NetworkProfile/Operational
Source: Microsoft-Windows-NetworkProfile
Event ID: 4004

Each trigger should be configured with a small delay before executing (we use 30 sec which is the minimum possible graphically but by editing the GPO XML you can customize it to e.g. 5 sec).

As a bonus this also solved our issues where the VPN wouldn't connect when connecting through a wireless captive portal (VPN tries to connect before user gets a chance to connect and then doesn't try again).

/Rasmus

_{Wednesday, March 25, 2020 1:11 PM}

Looks like MS may have finally released a fix.

March 24, 2020—KB4541335 (OS Builds 18362.752 and 18363.752)

Addresses an issue that causes attempts to complete the connection to a virtual private network (VPN) to fail; instead, the status remains at “Connecting.”

_{Wednesday, March 25, 2020 10:14 PM}

Anybody knows if that was also fixed for 1809?

Today on one machine IKEv2 would not connect (VPNStrategy=7, even changing to 5 would not connected via GUI - staying on Connecting..., cmd rasdial kicked in instantly)

While I understand that some home connections using some misconfigured **** routers will present problem with IKEv2, SSTP "should" work always

_{Thursday, March 26, 2020 2:49 PM}

Looks like for 1809 you need: March 17, 2020—KB4541331 (OS Build 17763.1131)

This update has to be imported to WSUS.

_{Thursday, March 26, 2020 5:38 PM}

Thanks

_{Thursday, April 2, 2020 10:04 PM}

Microsoft Windows [Version 10.0.18363.752]

Installed KB45411338 and KB4541335

Still having issue with AOVPN not connecting after sleep.

_{Monday, April 6, 2020 2:09 AM | 1 vote}

I agree.

I have 1909 with March 24, 2020 - KB4541335

The auto reconnect issue is still random and mostly does not work of resume from standby.

A reboot usually gets it working again.

ZonkIT

_{Tuesday, April 7, 2020 2:49 PM}

MS released the following patch on 30th March - https://support.microsoft.com/en-us/help/4554354/windows-10-update-kb4554354

They also advised that there is an update to be pushed out next tuesday that has some buug fixes for AoVPN conection issues.

_{Tuesday, April 21, 2020 7:29 AM | 1 vote}

Even with April patch Tuesday Win 10 1909, my users still reporting that after sleep a FULL RESTART is required to gain VPN back, shambolic!

_{Tuesday, April 21, 2020 7:38 AM}

amazing i I am also want to know the special KB.

_{Tuesday, May 26, 2020 1:56 PM | 1 vote}

There is no special KB. My company has had a MS support ticket open for over 5 months, trading logs back and forth. 2 months ago, had to reach out to my TAM to get the case escalated to the highest level - suppossedly AOVPN engineers on the case now.

Here is their "workaround" that they claim is resolving this issue for their customers. This is an excerpt from our support engineer. (Names, ticket number, domain names removed.) We have not validated yet, because of other reasons I state below.

<DomainNameInformation>
<DomainName>.contoso.com</DomainName>
<DnsServers>192.168.x.y</DnsServers>
</DomainNameInformation>
<DomainNameInformation>
<DomainName>vpn.contoso.com</DomainName>
</DomainNameInformation>

Note: You need to replace ‘vpn.contoso.com’ with the public name of your VPN.

I have not received confirmation about a permanent fix for this scenario. We are still using the workaround.
Please try to make the changes in your VPN profile on one of the affected machines and share the outcome."

1. There is only this "workaround", no KB patch, 1909 or post 1909.

2. When the the issue occurs after standby/fast startup - the vpn logs do not generate any useful information.

3. The only fix is a RESTART - as mentioned many times here.

4. Specific to our environment - Latest is that MS is suspecting our workstations have Cisco Umbrella Roaming client on them to block malicious websites. It uses a loopback address on the IP adapter (127.0.0.1) to intercept all DNS queries. For those of you familiar with Umbrella, we have our domain completely exempted from proxying/filtering. We do not have this issue with DirectAccess VPN, and we are still using it on 99% of our workstations, because we cannot deploy AOVPN.

5. MS wants us to disable Umbrella Roaming client, stating the loopback proxy is causing an issue of DNS lookup. Not an option to reduce security in this day& age.

6. The issue goes away if you disable Fast Startup feature and disable low power state on the NIC adapters. We are sure the issue is related to power states and resume, as mentioned several times in this thread.

We are preparing to "archive" the Microsoft case, and just deploy AOVPN with the caveat to our users to restart if they have any connectivity issues. We will also begin looking at a commercial alternative to MS' VPN. It doesn't appear there will be much development or competent support with this technology.

_{Friday, May 29, 2020 4:41 PM}

Never heard of Cisco Umbrella Roaming, certainly not using it, my users have same problem, hence this is not an issue.

My management got so few up with not being resolved the issue, that AOVPN is just about history here & Onedrive/Teams/reverse RDP via firewall (for the s**t apps that must run on local network, because developers never bothered to move them to web apps) are the replacement being deployed.

The bit:

<DomainNameInformation>
<DomainName>vpn.contoso.com</DomainName>
</DomainNameInformation>

is interesting, I might give it a go to test

_{Monday, June 29, 2020 12:08 PM}

Wow this is disappointing to hear, does anyone actually have AOVPN deployed and stable? If so, What setup, how many users?

_{Sunday, July 5, 2020 6:40 AM}

Ofcourse it is stable. It is brilliant solution. Just the re-connect issue.

At peak on single VM server I had 160 (user/devices) connections, working perfectly

_{Monday, July 6, 2020 7:06 PM}

If anyone still has reconnect issues, the following can also help when the domain name of the always on vpn connection is the same as one of the domain names which will be setup to ask the internal DNS servers for the IP. This in case you are using split tunneling.

For example. Your internal and external domain name is mydomain.nl and your vpn connection is set to aov.mydomain.nl. So you would set that all traffic to *.mydomain.nl will be send through the VPN connection to request the IP-address from the internal DNS server.
So if you would go to fileserver1.mydomain.nl, the request for the IP-address is done at your internal DNS server.
Now when you start connecting VPN,( it will not have a connection yet) the request will be done for aov.mydomain.nl to a public DNS server. the client gets the IP-address and eventually will get connected. Then the NRPT list is created on the device which will tell which domain names have to request there ip-addresses to which DNS server. In this example .mydomain.nl is added to request IP-address to the local DNS server which is through the VPN connection. So at that point when you would try to resolve the IP-address again for aov.mydomain.nl, it will ask this to the internal DNS server and not to an external DNS server.

This is where it gets tricky. Because if now the connection drops incorrectly and with that the NRPT list is not removed (which should but not always happens), the request for the IP-address for aov.mydomain.nl will still be done to the internal DNS server and will fail because the internal DNS server is not reachable. This because we don't have a active VPN connection.

In this case you could add the DNS name aov.mydomain.nl to the VPN configuration and add a public DNS server as the DNS where to request the IP-address. For example 8.8.8.8 and 8.8.4.4.

This way when the NRPT list is still in place but without the VPN connection active, VPN will try to reconnected and reads from the NRPT list that it has to request the ip-address for aov.mydomain.nl at an external DNS server. This server is available, gives the client the IP-address and connects to VPN.

Hopefully this is clear and will help you all out when applicable.

Share via

Always On VPN not always reconnecting after standby

Question

All replies (45)

Additional resources