Bypass authentication for Microsoft’s Network Tests to avoid Wi-Fi issues

An area where Windows 10 attempts to help users, but ultimately may cause problems in some environments, is with the network connectivity test the Operating System runs when establishing a new connection. Essentially, to work out whether your network connection is behind a captive portal or not, or has Internet access at all, Windows attempts to read the response from a Microsoft test domain. This is all pretty straight-forward, and a reasonable solution to the problem… with one significant caveat.

If everything is working normally, or when the device is connected to an unfiltered network connection, the common results are:

  • If the page returns the correct value, Windows uses the connection and lists “Internet access” as the connection state. 
  • If the outbound connection doesn’t give a response at all, you’re put in the “Limited or no connectivity” state.
  • If the outbound connection is successful, but a different response is received, Windows assumes you are hitting a captive portal logon page and will open this for you.

The issue appears to be, that if these states aren’t aren’t a match for the connection attempt, and perhaps you’re getting an internal proxy authentication as the response instead, then Windows appears to abort the connection attempt entirely and leave you with no network connection. Microsoft has seemingly made the timeout for this connectivity test so short, that even in environments with transparent proxies in place, the solutions simply can’t (consistently) authenticate the traffic before the timeout occurs and the connection is dropped.

In our case, we use a Cyberhound appliance as our web filter, and this transparently handles authentication to the Internet. Up until Windows 10 Fall Creators Update (1709), we hadn’t really noticed any issues, but after that we started dropping connections on resume and reboot fairly often. Unfortunately, the Cyberhound support team has confirmed that the service does indeed appear to hold up the authentication longer than Windows is willing to wait, and that means that the Wi-Fi connection attempt is aborted. Even more frustrating, the issue persists even if you reboot, or wait a while and attempt a manual connection.

How to get around this issue
The solution, is to bypass authentication for the test sites, so that the response is returned as soon as possible. To perform the connectivity test, Microsoft uses their custom test domains. These have recently changed, so please ensure that both are used in any configuration changes you make:

How to make this work with Cyberhound
This trick for Cyberhound in particular, but likely a fix for other web filters as well, is to bypass authentication to the connectivity test domains. To do this:

  1. Log in to the Cyberhound admin page.
  2. Expand “Internet Auth”, then click on “Config”.
  3. Locate the “Remote Whitelist” option, and click “Edit”.
  4. Ensure that is added to the list.

The IP Address, is what the domain currently resolves to consistently. That being said, this may change in the future, so we recommend that you add instead, which is Microsoft’s range for these types of services and should be safe to connect to without authentication… but that is up to you. Additionally, while not required at the time, consider adding “” and “” to an SSL-bypass rule to ensure that future changes to the connectivity test don’t result in broken Wi-Fi again.

Like the Secure Time Seeding issue I covered in an earlier post, the versions in which Microsoft states that something is changed doesn’t always seem to be the version affected by the change. For us, and for a few other schools that have reached out to us for help, this change only really hit people as of Windows 10 Fall Creators Update (1709). So if you’ve suddenly started having Wi-Fi connectivity issues, make sure that you are allowing access to the test domains and see if that helps.

Comments are closed.

Create a website or blog at

Up ↑

%d bloggers like this: