Always On VPN Updates to Improve Connection Reliability

Always On VPN Updates to Improve Connection ReliabilityA longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.

Recent Updates

The good news is that most of these issues have been resolved with recent updates to Windows 10 1803 and 1809. Specifically, the February 19, 2019 update for Windows 10 1803 (KB4487029) and the March 1, 2019 update for Windows 10 1809 (KB4482887) include fixes to address these known issues. Administrators are encouraged to deploy Windows 10 1803 with the latest updates applied when implementing Always On VPN. Windows 10 1809 with the latest updates applied is preferred though.

Persistent Issues

Although initial reports are favorable for these updates and based on my experience the effectiveness and reliability of Windows 10 Always On VPN is greatly improved, there have still been some reports of intermittent VPN tunnel establishment failures.

Possible Causes

During my testing, after applying the updates referenced earlier both device tunnel and user tunnel connections are established much more consistently than before the updates were applied. I did encounter some issues, however. Specifically, when coming out of sleep or hibernate, VPN connections would fail to establish. Occasionally VPN connections would fail after a complete restart.


After further investigation it was determined that the connectivity failure was caused by the Network Connectivity Status Indicator (NCSI) probe failing, causing Windows to report “No Internet access”.

Always On VPN Updates to Improve Connection Reliability

Cisco Umbrella Roaming Client

In this instance the NCSI probe failure was caused by the Cisco Umbrella Roaming Client installed and running on the device. The Umbrella Roaming Client is security software that provides client protection by monitoring and filtering DNS queries. It operates by configuring a DNS listener on the loopback address. NCSI probes are known to fail when the DNS server is running on a different interface than is being tested.


Microsoft released a fix for this issue in Windows 10 1709. The fix involves changing a group policy setting to disable interface binding when perform DNS lookups by the NCSI. You can enable this setting via Active Directory group policy by navigating to Computer Configuration > Administrative Templates > Network > Network Connectivity Status Indicator > Specify global DNS. Select Enabled and check the option to Use global DNS, as shown here.

Always On VPN Updates to Improve Connection Reliability

For testing purposes this setting can be enabled individual using the following PowerShell command.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force

Third-Party Software

As Always On VPN connectivity can be affected by NCSI, any third-party firewall or antivirus/antimalware solution could potentially introduce VPN connection instability. Observe NCSI operation closely when troubleshooting unreliable connections with Always On VPN.

Additional Information

Windows 10 1803 Update KB4487029

Windows 10 1809 Update KB4482887

Cisco Umbrella Roaming Client Limited Network Connectivity Warning

Network Connectivity Status Indicator (NCSI) Operation Explained

Leave a comment


  1. Nate

     /  May 15, 2019

    Hi. I’m having a sleep/hibernate issue. Resuming from sleep it tries to connect for about 25 seconds, seems to time out, then connects within two seconds in the second attempt. I tried the NCSI workaround with no luck. For me it seems like the NRPT is in a bad state. Our VPN server is in a DNS domain where we do split-DNS, so there is an NRPT rule for the domain. When I resume from sleep, JUST as it finally connects I get a “Name resolution policy table has been corrupted.” event 1023.
    If I disconnect the VPN before I put the machine to sleep, it auto-connects within 2 seconds after resuming and I don’t get event 1023.
    So might it not be properly disconnecting and clearing the NRPT when going to sleep?
    This is my LAST real annoyance to work out with this thing.


  2. Nate

     /  May 15, 2019

    Follow-up to my previous post. I created a test profile without the DNS domain containing the VPN server in the NRPT list. It fixed the connection delay, but I can’t do this in production. Unless someone has a better idea, I’ll have to rework this to use a different domain for the VPN server, which also means re-issuing VPN server certificates :/

  3. Nate

     /  May 15, 2019

    Follow up to my follow up, because of course I worked around it right after I bothered to write a post. An NRPT exclusion for the VPN server appears to work. I’m surprised this works if NRPT itself is the problem, but I’m now connecting within 2 seconds when resuming as soon as the Internet becomes available. Hope this helps someone else

    • Glad you were able to get it sorted! 🙂

    • rance

       /  May 22, 2019

      Nate, could you please explain what you did in more detail?
      I am also having sleep/hibernate connection issue. laptop wakes up, VPN says connected, but it isn’t and have to reboot to sort. Thank you for your time.

      • Nate

         /  May 23, 2019

        Hi rance,

        Sure, but off the bat your symptom is different than mine, which was a status of Connecting for about 25 seconds, timing out, then connecting immediately on the 2nd attempt.

        In my XML, I had a rule that looked like this:,

        Let’s say my VPN server name is I realized that when resuming from sleep, the NRPT was still active even though the connection was not, and it was trying to look up on the internal DNS servers specified in the XML. So, I created this exception:,

        This tells it to always look up on public DNS.
        I should NOT have needed to specify the DnsServers element, but I noticed it would sometimes want to grab the DNS servers from the parent domain’s NRPT rule which persisted the issue.

        While I was researching this I ran across a lot of posts that sound more like your issue where it takes a full reboot to resolve. This one, for example:

        The suggestions there might help, specifically the adapter power setting.

        Running fully patched 1809 is also pretty key. I deployed this to a few 17xx and they were pretty unpredictable until I upgraded them.

        Good luck!

  4. Nate

     /  May 23, 2019

    Sorry, WordPress stripped the tags from my rules. Hopefully you know what I meant.

  1. Always On VPN DNS Registration Update Available | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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: