Technical Tip: Understanding Captive Portal Auto-Detection Mechanisms

Description

This article describes how captive portal auto-detection works from client devices.

Scope

FortiGate.

Solution

Automatic detection of a captive portal is handled by the operating system of the client device, such as a smartphone, laptop, or tablet, through a straightforward verification process.

The system attempts to access a predefined URL known to return a specific, expected response when internet connectivity is unrestricted. If the expected content is received, the system assumes full internet access is available. However, if the response is altered or redirected, it indicates the presence of a captive portal.

In such cases, the device automatically triggers the browser to open the captive portal login (or splash) page, prompting the user for authentication before granting unrestricted network access.

While the core mechanism for captive portal detection remains consistent across client devices, attempting to access a predefined URL and evaluating the response, the specific domains used can vary based on the device type, manufacturer, and operating system version.

Captive portal detection mechanism from different devices/browsers.

Microsoft Edge browser:

Edge browser attempts an HTTP probe http://www.msftconnecttest.com/connecttest.txt during network detection. These get intercepted and redirected to the captive portal login page.

Firefox browser:

Firefox browser attempts an HTTP probe to detectportal.firefox.com during network detection. These get intercepted and redirected to the captive portal login page.

Chrome browser:

Chrome browser attempts an HTTP probe http://www.gstatic.com/generate_204 during network detection. These get intercepted and redirected to the captive portal login page.

Android Captive Portal Detection:

Android phone attempts an HTTP probe to clients2.google.com and connectivitycheck.android.com during network detection. These get intercepted and redirected to the captive portal login page.

For example, iPhones and iPads running iOS 6 may reach out to gsp1.apple.com, apple.com, and *.akamaitechnologies.com, whereas newer iOS versions (7 and above) and macOS systems may attempt to connect to a broader set of domains, including www.appleiphonecell.com, www.itools.info , and various *.apple.com and Akamai-related domains.

These domain checks are essential for each iOS to determine internet connectivity status and decide whether to automatically launch a captive portal login page.