Some Windows devices are not redirected to the Captive Portal when the user gets connected to WiFi network with Windows device.
The Captive Portal is not triggered automatically when is the testing domain accessible. Network Connectivity Status Indicator (NCSI) service testing internet connectivity has been introduced in Windows Vista at first.
How Windows determine if it has an Internet Connection
Windows does indeed check a Microsoft site for connectivity, using the Network Connectivity Status Indicator site (NCSI). There are a few variations of the connection checking process:
- NCSI performs a DNS lookup on
www.msftncsi.com, then requests http://www.msftncsi.com/ncsi.txt. This file is a plain-text file and contains only the text
- NCSI sends a DNS lookup request for
dns.msftncsi.com. This DNS address should resolve to 18.104.22.168. If the address does not match, then it is assumed that the internet connection is not functioning correctly.
The exact sequence of when which test is run is not documented; however, a little bit of digging around with a packet sniffing tool like Wireshark reveals some info. It appears that on any connection, the first thing NCSI does is requests the text file (step 1 above). NCSI expects a 200 OK response header with the proper text returned. If the response is never received, or if there is a redirect, then a DNS request for dns.msftncsi.com is made. If DNS resolves properly but the page is inaccessible, then it is assumed that there is a working internet connection, but an in-browser authentication page is blocking access to the file. This results in the pop-up balloon above. If DNS resolution fails or returns the wrong address, then it is assumed that the internet connection is completely unsuccessful, and the “no internet access” error is shown.
The order of events appears to be slightly different depending on whether the wireless network is saved, has been connected to before even if it is not in the saved connections list, and possibly depending on the encryption type. The DNS and HTTP requests and responses showing up in Wireshark were not always consistent, even connecting to the same network, so it’s not entirely clear what causes different methods of detection under different scenarios.
How to test it on iOS
Make sure you have no active internet session. If yes, wait until your active session expires.
- Connect to your WiFi network (hotspot registered at SOCIFI Dashboard)
- Do not connect through SOCIFI Captive Portal
- Open regular browser (Ie, Chrome, Firefox) and enter the “
www.msftncsi.com"or “http://www.msftncsi.com/ncsi.txt” to the URL
- If the page above is accessible you are no redirected to the SOCIFI Captive Portal.
- Check your Walled Garden settings or your Firewall Policy.The www.msftncsi.com domains and corresponding IP (22.214.171.124) address have to be inaccessible to unauthenticated users
- Check the NCSI service is enabled in the registry settings
- search for HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNlaSvcParametersInternet
- Under the Internet key, double-click EnableActiveProbing, and then in Value data, type: 0.The default for this value is 1. Setting the value to 0 prevents NCSI from connecting to a site on the Internet during checks for connectivity.
We are looking forward to your inputs and thoughts. Thank you for letting us know about your improvements.