Skip to main content
English (US)

Why your captive portal is not loading on iPhone: Fix Apple CNA errors

Troubleshoot and fix captive portal popup failures on iPhone and iOS. Learn how Apple CNA, iCloud Private Relay, and MAC randomization break WiFi logins, and how to fix them.

By Tom HackettPublished
📖 10 min read2,205 words2 worked examples3 practice questions6 key definitions

Video overview

Listen to this guide

View podcast transcript
[Intro Music: Upbeat, modern electronic synth-pop with clean piano highlights, establishing a professional, tech-forward tone] **Host (Senior Consultant)**: Hello and welcome to the Purple Technical Briefing. I'm your host, and today we are diving deep into one of the most common - and frankly, most frustrating - issues facing network administrators, IT managers, and venue operations directors today. We've all been there. You've spent weeks planning, configuring, and deploying a state-of-the-art guest WiFi network for your hotel, shopping mall, or stadium. You've got the latest access points, a robust controller, and a beautiful splash page ready to capture guest data and drive engagement. But then, the helpdesk tickets start rolling in. And they all say the exact same thing: "I've connected to the guest WiFi on my iPhone, but the login page won't load." To the guest, your WiFi is simply broken. But to us, as network engineers and architects, we know there is a complex technical battle happening under the hood of iOS. Today, we're going to unpack exactly why your captive portal isn't loading on iPhones, how Apple's background detection logic works, and the step-by-step mitigation paths you can implement on your network this quarter. [Brief transitional musical swell] **Host**: Let's start with the technical deep-dive. Why does an iPhone connect to guest WiFi but fail to show the login screen? To understand this, we have to look at Apple's **Captive Network Assistant**, or **CNA**. When an iPhone associates with an open SSID and receives an IP address via DHCP, it doesn't just wait for the user to open a browser. Instead, a background system daemon immediately fires off a plain HTTP GET request to a very specific URL: `http://captive.apple.com/hotspot-detect.html`. This background probe uses a unique system User-Agent called `CaptiveNetworkSupport`. The CNA daemon is looking for a very specific response. If Apple's servers return an HTTP status code **200 OK** with a body that says exactly the word "Success", iOS concludes that the network has unrestricted internet access. It quietly establishes WiFi as the primary routing interface, and the user goes about their day. However, if your network gateway intercepts that HTTP request and returns anything else - like an HTTP 302 or 307 redirect, or a customized HTML page - iOS immediately recognizes that it is behind a captive portal. It instantly launches the native **Websheet app**. This is that familiar slide-up modal sheet that displays your guest login page. Now, here is the first major engineering pitfall: **The Walled Garden**. Many network engineers make the mistake of whitelisting Apple's success domains, like `captive.apple.com`, in their pre-authentication Access Control Lists. They think, "Well, it's an Apple domain, I should let it through." But if you whitelist it, the background probe successfully reaches Apple's servers, receives the "Success" response, and iOS assumes there is no captive portal. The Websheet never triggers! Meanwhile, the user is blocked from accessing any other websites. So, rule number one: **Never whitelist captive.apple.com in your walled garden.** [Brief transitional sound effect] **Host**: But what about modern iOS privacy features? Even with a perfect walled garden, features like **iCloud Private Relay** and **Private MAC Addresses** are changing the game. Let's talk about iCloud Private Relay, introduced in iOS 15. This feature encrypts and routes Safari's DNS and HTTP traffic through a dual-hop proxy architecture. When a user with Private Relay active connects to your guest WiFi, the background HTTP probe is encapsulated inside an encrypted tunnel. Because your network gateway cannot inspect or intercept this encrypted packet, it cannot inject the redirect. The probe fails silently, and the iPhone simply displays a "No Internet Connection" warning. No portal, no login, just friction. Fortunately, there is a programmatic network-level mitigation for this. Apple has designed Private Relay to respect network-level blocks. If your local DNS server returns an **NXDOMAIN** response for Apple's Private Relay domains - specifically `mask.icloud.com` and `mask-h2.icloud.com` - iOS recognizes that the network is incompatible with Private Relay. It will immediately display a system prompt asking the user if they want to "Use Without Private Relay" for this network. The moment they tap that, the encrypted tunnel is bypassed, the HTTP probe is intercepted, and your captive portal loads perfectly. Next up is **Private MAC Addresses** and the new **Rotating MAC Addresses** in iOS 18. By default, iPhones randomize their MAC address for each SSID. In iOS 18, this address rotates periodically even while connected to the same network. If your wireless controller tracks authenticated guest sessions solely by MAC address, a sudden rotation will cause the gateway to treat the iPhone as a brand-new, unauthenticated device. The guest is abruptly disconnected and forced to log in again. To mitigate this, enterprise venues must move away from simple MAC-based tracking. Platforms like **Purple** solve this by dropping a secure, persistent cookie in the browser session, or better yet, by transitioning venues to **Passpoint**, also known as Hotspot 2.0. Passpoint uses secure 802.1X profiles to automatically and securely authenticate returning guests without ever showing a captive portal sheet. It's secure, it's seamless, and it completely bypasses the limitations of the CNA. [Brief transitional musical swell] **Host**: Now, let's address custom DNS profiles and local VPNs. Many technical users install custom DNS profiles like NextDNS or AdGuard that enforce encrypted DNS-over-HTTPS. Because these profiles bypass your local DHCP-assigned DNS servers, your gateway cannot spoof the DNS lookup for `captive.apple.com`. Similarly, "Always-On" VPN profiles will attempt to establish an encrypted tunnel the second an IP is assigned. If the VPN succeeds, it bypasses your redirect; if it is blocked, it deadlocks the connection. For these users, the ultimate manual fallback is the **neverssl.com** trick. If a guest is connected to your WiFi but the portal won't load, tell them to open Safari and type `neverssl.com` into the address bar. Because this domain is strictly unencrypted HTTP, the gateway is guaranteed to intercept the port 80 traffic and force the redirect to load, bypassing any custom DNS or VPN interference. [Sound effect: Quick transition chime] **Host**: Let's run through a rapid-fire Q&A of the most common questions we get from venue support teams. *Question one: Why does my iPhone show 'No Internet Connection' in orange under the WiFi name?* **Answer**: This means the iPhone completed the WiFi association and got an IP address, but the background CNA probe failed to get a response from Apple's success servers and was not successfully redirected, often due to iCloud Private Relay or an active VPN. *Question two: Can we just disable the CNA mini-browser entirely on our network?* **Answer**: Yes, most enterprise Wireless LAN Controllers have a setting called 'CNA Bypass' or 'Captive Portal Bypass'. When enabled, the controller spoofs the Apple success probe, telling the iPhone it has full internet. This prevents the Websheet from popping up, but it relies on the user manually opening Safari to trigger the redirect, which can sometimes create even more user confusion. *Question three: What is the post-authentication probe issue?* **Answer**: After the guest logs in, the CNA Websheet runs a secondary probe to verify internet access. If your gateway redirects them to a landing page but continues to block Apple's success domains, the top-right button remains stuck on 'Cancel'. Clicking 'Cancel' disconnects them from the WiFi. You must ensure Apple's success domains are fully accessible post-authentication. [Brief transitional musical swell] **Host**: To wrap up, let's look at the real-world business impact. Optimizing your captive portal isn't just about technical elegance; it's about the bottom line. We recently worked with a luxury 5-star resort group that was experiencing a 35% failure rate in guest WiFi connections, leading to over 450 front-desk complaints every single week. By restructuring their walled garden, blocking Private Relay domains at the DNS level to force local routing, and deploying **Purple's Guest WiFi** solution, they saw front-desk WiFi tickets drop by **92%** in just 30 days. Their guest satisfaction scores soared, and they captured thousands of verified guest profiles. If you want to ensure your guest WiFi network interacts flawlessly with Apple's Captive Network Assistant while maximizing data capture and minimizing support costs, head over to **purple.ai**. Our platform is engineered to handle all of these iOS-specific nuances out of the box. Thank you for listening to this Purple Technical Briefing. Implement these walled garden and DNS strategies this week, and watch your support tickets disappear. Until next time, keep your connections secure and your guest onboarding seamless. [Outro Music: Upbeat electronic synth-pop fades out slowly]

Part of our core series: Captive Portal Guide →

Interactive Network Tool

Apple iOS Captive Portal and CNA Diagnostic Advisor

Diagnose captive portal popup failures, white screens, SSL warnings, and iCloud Private Relay issues across iOS 14 to iOS 18 with controller-specific remediation scripts.

Critical

Apple CNA Probe Request Intercepted or Dropped Before HTTP 302

The Apple Captive Network Assistant (CNA) daemon failed to detect network captivity because probe HTTP GET requests to captive.apple.com/hotspot-detect.html were silently dropped or returned an unhandled status.

Detailed Protocol Breakdown (IOS_18)

Upon associating with an unauthenticated SSID, iOS issues an HTTP GET request to http://captive.apple.com/hotspot-detect.html expecting the string "<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>". If the network drops TCP port 80 or hijacks DNS without returning an immediate HTTP 302 redirect, iOS assumes internet connectivity is offline and suppresses the slide-over CNA sheet.

Required Apple CNA Probe Walled Garden Whitelist:

captive.apple.comwww.airport.usappleiphonecell.com*.apple.com*.purple.ai*.purplewifi.net

Eliminate Captive Portal Login Failures with Passpoint & Purple Cloud

Provide instant, seamless onboarding for iOS and Android guest WiFi without CNA popup errors or manual browser logins.

Why your captive portal is not loading on iPhone: Fix Apple CNA errors

Executive Summary

For modern enterprise venues - spanning luxury hotels, large retail malls, municipal transit hubs and multi-purpose stadiums - guest wireless connectivity is no longer a luxury; it is a critical touchpoint for customer engagement, digital operations and revenue generation. Yet network administrators around the world face one persistent, high-friction support ticket: "Why won't my iPhone load the guest WiFi login screen?"

When an Apple iOS device associates with an open SSID but fails to display the captive portal, the user is left "stranded" - connected to the local wireless network with a valid DHCP IP address, yet completely blocked from internet access. To a non-technical user, this means the network is "broken". For the business, that failure translates directly into elevated customer support costs, damaged brand trust, and missed opportunities to collect valuable first-party data.

This technical reference guide provides network architects, CTOs and venue operations directors with an exhaustive, vendor-agnostic analysis of the iOS Captive Network Assistant (CNA) background process. We will take a deep dive into the precise background HTTP probing mechanism Apple devices use to detect captive networks, dissect the modern iOS privacy features that inadvertently block those probes (such as iCloud Private Relay, Private MAC addresses, on-device VPN profiles and custom DNS-over-HTTPS (DoH) configurations), and provide actionable, production-tested mitigation strategies. Finally, we will explain how Purple's Guest WiFi solution interacts flawlessly with Apple's CNA, ensuring a seamless login experience while maintaining robust network security.

Technical Deep-Dive

To solve captive portal loading issues on iOS, you must first understand that the iPhone does not "listen" for a redirect - it actively "hunts" for one. The entire mechanism is governed by a background system daemon called the Captive Network Assistant (CNA), which operates independently of the standard Safari browser [1].

Apple's Detection Logic and Probing Mechanism

The moment an iOS device completes the 802.11 association phase and obtains a local IP address via DHCP, the CNA helper daemon fires in the background. Before switching the device's primary internet routing interface from cellular data to WiFi, the operating system must verify that the wireless network offers unrestricted internet access [2].To perform this check, the CNA daemon sends a simple HTTP GET request to a series of dedicated Apple success domains. The primary target URL is:

http://captive.apple.com/hotspot-detect.html

Additional secondary fallback domains include:

  • http://www.apple.com/library/test/success.html
  • http://www.appleiphonescell.com/hotspot-detect.html
  • http://www.itools.info/hotspot-detect.html
  • http://www.ibook.info/hotspot-detect.html

The background HTTP probe is initiated with a highly specific system User-Agent string, typically structured as:

CaptiveNetworkSupport-355.200.27 wispr

The CNA daemon evaluates the HTTP response against two possible outcomes:

  1. Unrestricted internet (Success): If the DNS query resolves normally and the target web server returns an HTTP status code of 200 OK with a body containing exactly the word Success, the operating system concludes the network is fully open. The device sets WiFi as the default routing interface, and no captive portal is displayed.
  2. Captive network detected (Interception): If the network infrastructure intercepts the HTTP request and returns anything other than the expected 200 OK "Success" payload - for example an HTTP status code of 302 Found, 307 Temporary Redirect, or an HTTP 200 OK carrying a customized HTML login page - the operating system recognizes that it is sitting behind a captive portal.

Once the captive state is identified, iOS immediately launches the native Websheet app (the CNA mini-browser). This is a stripped-down, heavily restricted WebKit instance that presents the redirected login page as an interactive slide-up window, preventing the user from accessing other system apps or downloading external files until authentication is complete [1].

Why your captive portal is not loading on iPhone: Fix Apple CNA errors - cna detection flow

Post-Authentication Probing (The "Done" Button Challenge)

A critical architectural nuance of the CNA mini-browser is its reliance on post-authentication probing. As the user interacts with the login page - whether entering credentials, accepting terms or authenticating via social media - the CNA mini-browser does not close automatically.

Instead, the WebKit page monitors all navigation activity. To determine whether the user has successfully completed the login flow, the CNA daemon performs a second HTTP probe to http://captive.apple.com/hotspot-detect.html, this time using a standard browser User-Agent:

Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/16A366

Only when this secondary probe returns a clean 200 OK "Success" payload does the CNA mini-browser change the button in the top-right corner from "Cancel" to "Done". If a network engineer redirects the user to a post-authentication landing page without allowing the background probe to reach Apple's success servers, that button remains stuck on "Cancel". Tapping "Cancel" immediately disassociates the iPhone from the WiFi network, frustrating the user and dropping the connection [2].

iOS-Specific Interference Factors

While Apple's CNA mechanism is elegant in theory, modern iOS privacy and security enhancements frequently interfere with the background HTTP probe, preventing the Websheet from ever triggering.

Why your captive portal is not loading on iPhone: Fix Apple CNA errors - ios interference factors

1. iCloud Private Relay

Introduced in iOS 15, iCloud Private Relay is a dual-hop proxy architecture designed to encrypt and mask a user's web browsing traffic in Safari [3].

  • The conflict: When Private Relay is enabled, DNS queries and HTTP traffic are encapsulated and tunneled through secure egress proxies. Because the local network controller cannot intercept these encrypted packets, it cannot inject an HTTP 302/307 redirect. The iPhone's background probe fails silently, and the device displays a "No Internet Connection" warning beneath the SSID without ever popping the captive portal page.

2. Private MAC Addresses and Rotating Identifiers

By default, iOS randomizes the device's Media Access Control (MAC) address on a per-SSID basis to prevent cross-venue tracking [4].

  • The conflict: With iOS 18, Apple introduced rotating private WiFi addresses, which periodically rotate the MAC address even while connected to the same SSID. If the captive portal's session state table tracks authenticated guests solely by MAC address, a sudden MAC rotation causes the network controller to treat that iPhone as a brand-new, unauthenticated device. The user is silently disconnected and asked to log in again, severely disrupting session continuity.

3. Encrypted DNS Profiles (DoH/DoT)

Many technically minded professionals install custom profiles (such as NextDNS, AdGuard or Cloudflare 1.1.1.1) that enforce DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) at the operating-system level.

  • The conflict: These profiles force the iPhone to bypass the local DNS servers supplied in the DHCP lease, routing all DNS queries to public resolvers over encrypted HTTPS connections. Because the local network gateway cannot intercept or spoof these encrypted DNS queries, it cannot return a redirect IP for captive.apple.com. The query fails or times out, blocking the CNA from triggering.

4. On-Device VPN Profiles

Enterprise MDM profiles and personal VPNs (Virtual Private Networks) commonly employ "On Demand" or "Always On" configurations.

  • The conflict: The instant the WiFi interface obtains an IP address, the VPN client attempts to establish an encrypted tunnel. If the VPN tunnel comes up before the CNA daemon completes its HTTP probe, all traffic is routed securely to the VPN gateway, bypassing local interception entirely. If the VPN client cannot connect because the captive portal's firewall blocks it, it holds back all other network traffic, leaving the device deadlocked - neither the VPN nor the captive portal can load.

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.

Implementation and Mitigation Guide

To guarantee a 100% reliable captive portal trigger rate for iOS devices, network engineers must design their wireless LAN controllers (WLCs) and firewalls to accommodate Apple's specific detection logic.

Walled Garden (Pre-Authentication ACL) Design

The most common engineering mistake is a misconfigured Walled Garden (the access control list of domains reachable before authentication).

  • The rule: Apple's success domains (such as captive.apple.com) must never be whitelisted in the walled garden. If you whitelist captive.apple.com, the iPhone's pre-authentication HTTP probe will successfully reach Apple's servers and receive a 200 OK "Success" response. The device will conclude it has full internet access, bypass the CNA Websheet entirely, and then fail to load any real website when the user opens Safari.
  • The exceptions: You must, however, whitelist the specific domains required to render the portal page - such as your hosted portal domain, CDN-hosted CSS/JS assets, and external identity providers (for example Google, Facebook, or Apple ID login endpoints).

Step-by-Step WLC Configuration (Cisco Catalyst / Meraki Example)

When deploying guest wireless on Cisco Catalyst or Meraki APs [5], follow this architectural framework:

Step Action Technical Purpose
1 Configure an Open SSID with MAC filtering disabled Allows immediate association and DHCP IP assignment without initial 802.1X blocking.
2 Configure a redirect ACL to intercept Port 80 Intercepts plain HTTP traffic and redirects it to the Purple portal URL (https://portal.purple.ai/...).
3 Set DNS servers to the local gateway Ensures DNS queries for captive.apple.com are resolved by the local controller, enabling the redirect.
4 Exclude Apple success domains from the walled garden Guarantees the background HTTP probe is intercepted, triggering the iOS CNA Websheet.
5 Enable "CNA Bypass" or "Captive Portal Bypass" For advanced deployments, the WLC can be configured to spoof a 200 OK response to the initial probe, forcing users to open Safari manually rather than using the restricted Websheet.

Best Practices and Industry Standards

Managing guest wireless at scale requires adherence to modern networking standards and regulatory compliance frameworks.

  • Transition to WPA3-Personal (OWE): Legacy guest portals run on fully open, unencrypted SSIDs, exposing users to eavesdropping. Enterprise networks should transition to Opportunistic Wireless Encryption (OWE) (the IEEE 802.11aq standard) to deliver individualized data encryption without requiring a password [6].
  • PCI DSS and CCPA/CPRA compliance: Guest portals must segregate guest traffic from corporate and cardholder data environments (CDE) to maintain PCI DSS compliance. Furthermore, when capturing first-party data, the portal must present clear, CCPA/CPRA-compliant consent checkboxes - all of which can be managed seamlessly through a WiFi Analytics platform.
  • Integrate Passpoint (Hotspot 2.0): To eliminate captive portal friction altogether, venues should deploy Passpoint (Hotspot 2.0). Passpoint uses cellular-style roaming technology to authenticate iOS devices securely and automatically via a pre-installed profile, bypassing the CNA entirely while encrypting all over-the-air traffic.

-

Troubleshooting and Risk Mitigation

When end users hit a failure, venue support staff and network administrators can work through the following structured troubleshooting paths:

End-User Self-Remediation Path

  1. Disable iCloud Private Relay: Go to Settings > WiFi, tap the blue (i) icon next to the guest SSID, and switch off Limit IP Address Tracking [3].
  2. Disable Private MAC Address: In the same WiFi settings menu, switch off Private WiFi Address to prevent MAC rotation issues [4].
  3. Force the trigger via Safari: Open Safari and enter a non-secure HTTP URL in the address bar. The industry standard is: neverssl.com Because this domain never uses HTTPS, the network controller is guaranteed to intercept the port 80 request and successfully redirect the user to the portal.
  4. Temporarily reset DNS: If a custom DNS profile is installed, go to Settings > WiFi > [SSID] > Configure DNS, switch from Manual to Automatic, and reconnect.

Network Engineer Diagnostic Path

                  [ iPhone connects to guest SSID ]
                                  |
                                  v
                    [ DHCP IP obtained? ]
                     /                                        (No)                      (Yes)
                   /                                 [ Check DHCP pool range ]               v
                                   [ Does DNS resolve? ]
                                    /                                                    (No)                   (Yes)
                                  /                                            [ Check DNS server ACL ]              v
                                             [ Is captive.apple.com whitelisted? ]
                                              /                                                                          (Yes)                              (No)
                                            /                                                                [ REMOVE from Walled Garden ]                       v
                                                                 [ Intercept Port 80 Redirects? ]
                                                                  /                                                                                            (No)                             (Yes)
                                                                /                                                                                    [ Check WLC Redirect Rules ]         [ CNA Websheet Triggers ]

ROI and Business Impact

Optimizing the iOS guest WiFi onboarding experience has a direct, measurable impact on venue operations and business performance.

Hospitality Case Study: Five-Star Resort Group

  • Challenge: A luxury hotel group with 12 properties suffered a guest WiFi connection failure rate of 35%, driving more than 450 front-desk complaints per week.
  • Implementation: The IT team restructured its walled garden, disabled MAC-based session tracking, and deployed Purple's Guest WiFi solution with optimized CNA handling.
  • Results: Front-desk WiFi-related complaints fell by 92% within 30 days. Customer satisfaction (CSAT) scores rose by 18 points, and the venue captured 40,000 newly verified email addresses in the first quarter.

Retail Case Study: National Shopping Center Operator

  • Challenge: A retail operator with 45 shopping centers struggled to drive visitor engagement because iCloud Private Relay prevented the captive portal from loading on 40% of iOS devices.
  • Implementation: Implemented network-level Private Relay blocking (returning NXDOMAIN for Apple's relay domains to force local routing) and deployed WiFi Analytics .
  • Results: Portal completion rates jumped from 58% to 94%. The marketing team monetized the recovered portal inventory with localized retail media campaigns, generating an additional $120,000 in advertising revenue per quarter.

References

For teams deploying enterprise-grade guest wireless, these related resources provide deeper technical context:

Purple's Guest WiFi platform serves hospitality , retail , healthcare and transportation venues worldwide, delivering CNA-optimized guest login experiences at scale.

Key Definitions

Apple Captive Network Assistant (CNA)

An iOS and macOS operating system daemon that probes for internet connectivity and automatically launches a restricted WebKit modal (WebSheet) when a captive portal is detected.

Controls whether the login splash page appears automatically on iPhones when connecting to guest WiFi.

Canary probe URL

A lightweight HTTP endpoint (such as http://captive.apple.com/hotspot-detect.html) requested by client operating systems to verify unrestricted internet reachability.

If the probe response is modified or redirected, the operating system triggers its captive portal handler.

RFC 8908 Captive Portal API

An IETF standard protocol that provides an API endpoint where devices can query network captivity status, venue terms, and remaining session time via JSON.

Replaces legacy HTTP hijacking with structured, cryptographically secure captive network detection.

DHCP Option 114 (Captive-Portal)

A DHCP option (RFC 8910) that passes the URI of the RFC 8908 Captive Portal API to the client device during initial Layer 3 address assignment.

Signals captivity to iOS 14+ immediately during IP acquisition, bypassing DNS tampering.

iCloud Private Relay

An Apple privacy service that routes Safari traffic and unencrypted DNS through a dual-hop encrypted proxy architecture.

Can mask pre-auth DNS queries unless the local network issues an explicit network impairment signal (NXDOMAIN).

Private WiFi address (MAC randomization)

A privacy feature in iOS 14+ that generates a unique randomized MAC address per SSID to prevent cross-venue physical tracking.

Can desynchronize RADIUS accounting sessions if MAC addresses rotate mid-session or during re-authentication.

Worked Examples

A luxury hotel deploying Cisco Catalyst 9800 WLCs finds that guest iPhone users never receive the captive portal splash screen when connecting to the open Guest WiFi SSID. Android and Windows laptops load the portal immediately. How should the network team diagnose and fix the Apple CNA detection issue?

  1. Inspect Pre-Auth Redirect ACL: Verify that the Cisco 9800 redirect ACL denies (bypasses) UDP 53 DNS and permits TCP 80 HTTP to trigger redirection. 2. Check Apple Probe Whitelist: Ensure captive.apple.com is NOT whitelisted in the pre-auth walled garden before redirection; whitelisting it causes iOS to think internet is open and suppress the portal. 3. Verify HTTP 302 vs 307: Configure the WLC webauth parameter map to return an HTTP 302 Found redirect with the portal FQDN. 4. Disable HTTPS Interception: Ensure port 443 HTTPS traffic is dropped or rejected rather than hijacked with an untrusted certificate. 5. Deploy DHCP Option 114: Add option 114 ascii https://app.purplewifi.net/api/v1/capport to the guest DHCP pool for native iOS 14-18 detection.
Examiner's Commentary: Apple devices rely on a strict match for the Success token from captive.apple.com. If the probe domain is prematurely permitted through the walled garden, iOS falsely assumes open internet and will never trigger the WebSheet.

A stadium network administrator observes that iOS 17 and iOS 18 users experience an infinite login loop: the CNA sheet appears, the user accepts terms and clicks Connect, the modal closes, but 30 seconds later the modal re-opens asking for login again. What is the root cause and remediation?

  1. RADIUS Session Tracking: On iOS 17/18, Private Wi-Fi Addresses use rotating MAC addresses if configured, or the device may renegotiate DHCP upon modal exit. 2. RADIUS CoA Configuration: Verify that the controller processes RFC 3576 RADIUS Change of Authorization (CoA) Disconnect on UDP port 3799 so the pre-auth ACL is removed immediately upon authentication. 3. Session Timeout & Grace Period: Increase the MAC authentication bypass (MAB) cache timeout to 1440 minutes (24 hours) with a 15-minute lease grace window. 4. Walled Garden OAuth Assets: Verify all OAuth endpoints (Google, Apple, Microsoft) and fonts/stylesheets are in the walled garden so the session finishes loading completely before closing the WebSheet.
Examiner's Commentary: Infinite redirect loops typically stem from RADIUS CoA delays where the controller has not yet updated the client state from pre-auth to post-auth when iOS sends its post-login verification probe.

Practice Questions

Q1. Why does attempting to redirect HTTPS (port 443) traffic cause captive portal errors on iOS devices rather than opening the splash page?

Hint: Consider how TLS encryption, certificate verification, and HSTS protect web traffic.

View model answer

HTTPS establishes an end-to-end encrypted TLS tunnel between the client browser and the destination web server. When a wireless gateway attempts to intercept port 443 and serve a redirect, the SSL/TLS certificate provided by the gateway does not match the requested hostname (e.g. google.com or apple.com). iOS enforces HTTP Strict Transport Security (HSTS), causing Safari and WebKit to abort the connection with a severe security warning rather than following the redirect.

Q2. How should an enterprise guest network handle iCloud Private Relay to ensure smooth captive portal redirection on iOS devices?

Hint: Review Apple official network guidance regarding mask.icloud.com DNS responses.

View model answer

Network administrators should configure their local recursive DNS servers to return an NXDOMAIN response (or a DNS resolution failure) for the domain names mask.icloud.com and mask-h2.icloud.com. When iOS receives an NXDOMAIN response for these canary domains, it displays a system alert informing the user that the network does not support Private Relay and cleanly falls back to standard DNS and HTTP probe handling.

Q3. What is the advantage of deploying RFC 8908 Captive Portal API over traditional DNS and HTTP hijacking techniques?

Hint: Think about protocol clarity, Layer 3 signaling, and user experience.

View model answer

RFC 8908 provides a standardized JSON REST API communicated via DHCP Option 114 or IPv6 Router Advertisements. Instead of intercepting user web traffic, the client OS queries the API directly over HTTPS to learn if the network is captive, obtain the portal login URL, inspect remaining quota, and receive a venue-branded notification. This eliminates SSL certificate warnings, supports password managers, and preserves browser security integrity.

Frequently asked questions

Why is my captive portal not popping up on iPhone?

Captive portals fail to pop up on iPhones when the Apple Captive Network Assistant (CNA) cannot complete its probe to http://captive.apple.com/hotspot-detect.html. Common causes include: 1) Pre-authentication firewalls blocking UDP port 53 DNS; 2) The network prematurely whitelisting captive.apple.com in the walled garden; 3) Gateways attempting HTTPS interception instead of HTTP 302 redirection; or 4) iCloud Private Relay interfering with DNS resolution.

How do I force the WiFi login screen to appear on iOS?

To manually trigger the captive portal on iPhone: 1) Open Safari and navigate to a plaintext HTTP URL such as http://captive.apple.com, http://neverssl.com, or http://1.1.1.1; 2) Go to Settings > Wi-Fi, tap the info (i) icon next to the network, and ensure Auto-Join and Auto-Login are toggled ON; 3) Turn Wi-Fi off and back on to trigger the CNA probe daemon.

What domains must be in the walled garden for Apple devices?

To support Apple iOS and macOS captive portal detection and assets, whitelist: captive.apple.com, www.airport.us, appleiphonecell.com, *.apple.com, *.purple.ai, *.purplewifi.net, and any third-party OAuth provider domains (e.g. accounts.google.com) or CDN assets used on the splash page.

How does RFC 8908 solve iOS captive portal issues?

RFC 8908 (Captive Portal API) and RFC 8910 (DHCP Option 114) pass the captive portal URL directly to iOS during the DHCP IP lease negotiation. This allows iOS 14+ to recognize network captivity instantly at Layer 3 without relying on fragile HTTP redirection or DNS hijacking.

How does MAC address randomization affect captive portal authentication?

iOS Private Wi-Fi Addresses use unique MAC addresses per SSID. If the device rotates its MAC address or if session caching is tied strictly to physical MAC addresses without RADIUS accounting grace periods, the user may be forced to re-authenticate repeatedly. Configuring a 24-hour lease grace period and deploying Passpoint (Hotspot 2.0) resolves this issue.

Sources

  1. Apple Developer Documentation - Captive Network Architecture and CNA
  2. Apple Support - Prepare Your Network for iCloud Private Relay
  3. IETF RFC 8908 - Captive Portal API Specification
  4. IETF RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements
  5. Wireless Broadband Alliance (WBA) - Captive Portal Standards and Best Practices
  6. Purple - Captive Portal Architecture & Troubleshooting Guide
  7. Purple - MAC Address Randomization Impact Guide

Continue reading in this series

Ubiquiti UniFi guest portal not redirecting: causes and fixes

This guide isolates a UniFi guest portal redirect failure by following the guest state, redirect, pre-authorization route and controller authorization in sequence. It gives venue IT teams a sourced method to address guest-network versus Hotspot confusion, external portal hand-offs, current UniFi OS account requirements and DNS isolation testing.

Read the guide →

Cisco Meraki splash page not working: a troubleshooting flowchart

This practical day-two guide isolates where a Cisco Meraki splash flow has failed: client authorization, HTTP redirect initiation, walled-garden reachability or RADIUS sign-on. It gives venue IT teams a controlled evidence path, so they can restore Guest WiFi without making broad changes to a live estate.

Read the guide →

Enterprise Guest WiFi Setup Guide: VLAN Segmentation, Security, and Captive Portals

This technical guide shows IT teams how to set up Guest WiFi as a controlled internet-access service, using VLAN segmentation, firewall policy, and a captive portal. It also explains how Purple's registration forms and onboarding controls support a proportionate visitor experience without weakening the boundary around staff, payment, and operational systems.

Read the guide →

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.