So, our Guest wireless network has been facing some issues for a while now. Basically, iOS and Android devices connect to the Guest network and are almost instantly redirected to the authentication portal. However, Windows devices take a long time to automatically open a browser, and when they do, they remain stuck for a while on the site "www.msftconnecttest.com".
This site is a probe site used by Windows to detect internet connectivity and captive portals. It sends an HTTP GET request to this URL and waits for a response code to determine whether there is a network connection, no network, or if a captive portal is required. We know that Android and iOS devices do similar things, but in our case, they do not experience certain specific issues. Some other issues are difficult to confirm on Android/iOS.
The main point is that, in a previous TAC case, we were told this could be a bug where some devices connected to access points in local mode could not ping their own gateway. However, this was refuted since our access points are in Flex mode, and besides that, we have a Redirect ACL that specifically prevents the gateway from being pinged, as it only allows packets destined for port 80. https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwn17412
I will send a screenshot of the current ACL below.
the red scribbled IP is the guest portal's IP address
Regarding DNS, yes, we do have multiple timeouts, but I believe that in the case of this guest portal, it should not even be necessary. Our DNS server is external, and we cannot even access our own gateway, meaning we cannot use external DNS to resolve this portal. It should be the role of the WLC 9800 to intercept and forward the captive portal request.
We attempted a test by adding both the Microsoft probe address and our captive portal to the Windows hosts file, and we encountered the following error in the NCSI logs on Windows 11:
ActiveHttpProbeFailedButDnsSucceeded
This error can be checked at:
https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-frequently-asked-questions#how-does-ncsi-know-whether-to-use-an-http-or-dns-probe.
Some useful information:
-
Our ISE version is 3.1, with the latest patch installed.
-
This problem occurs exclusively with Windows 10 and 11 devices.
-
The main issue is that Windows devices take more than 5 minutes to complete the redirect to the guest portal.
-
The FQDN of the portal can be resolved via external DNS.
- External primary DNS is 208.67.222.222 and secundary 208.67.220.220
Another interesting factor is that, when checking our Fortigate, we see that only mDNS packets arrive, and they are exclusively from devices experiencing this guest portal issue.
nslookup to our Guest Portal FQDN (tryed when connected to the Guest SSID, but before authenticate in the portal)
