Skip to main content
“The guest is on the SSID but nothing happens” is the most common Sign In support call. Usually the network is fine — it’s the device’s captive-portal detection that’s stuck. This page covers the device-side quirks that cause it.

​
How OS captive-portal detection works (roughly)

Every major operating system pokes at a known URL after joining a new network to decide whether the internet is reachable. Recent OSes also read DHCP Option 114 — when present it’s the preferred signal, and the OS surfaces a “Sign in to network” prompt directly.
OSDetection endpointOption 114 support
iOS / iPadOScaptive.apple.com, www.apple.com/library/test/success.htmlYes, recent versions
macOScaptive.apple.comYes, recent versions
Androidconnectivitycheck.gstatic.com, clients3.google.com/generate_204Yes, recent versions
Windowswww.msftconnecttest.com/connecttest.txtYes, recent versions
If these endpoints are unreachable (firewalled) or return unexpected responses, the OS doesn’t recognise the captive portal, and no prompt appears.

​
MAC randomization (the big one)

Every modern client OS randomizes its MAC address per SSID, and some also rotate it periodically on the same SSID. This affects Sign In in a few ways:
  • Whitelist entries by MAC stop matching. A device whitelisted yesterday may appear as a different MAC today. For personal devices, prefer an identity-based module (Self-Provisioning by Email, SAML SSO) over Whitelist.
  • DHCP leases don’t persist. Each MAC gets a fresh lease; expect some churn on the DHCP tab.
  • Site matching still works. Site-based redirects match by AP MAC (Meraki) or IP Scope (Service Gateway), not the client’s MAC — so randomization doesn’t affect site matching.

​
iOS / iPadOS / macOS Private Wi-Fi Address

Apple expanded MAC randomization in iOS / iPadOS 18 and macOS 15. Devices now have three modes per SSID, under Settings → Wi-Fi → the network → Private Wi-Fi Address:
  • Off — the hardware MAC is used.
  • Fixed — a randomized MAC that stays the same for the SSID (the pre-18 behaviour). Default for encrypted networks.
  • Rotating — a randomized MAC that changes approximately every two weeks. Default for open (guest) networks.
What this means for guest networks. On a typical open guest SSID, an iPhone or iPad running iOS 18+ will rotate its MAC every ~2 weeks. If a guest’s Access Policy grants longer access (BYOD with a multi-week session, for example), the guest has to re-register after each rotation — or switch the Private Wi-Fi Address to Fixed for the SSID. MacBooks upgrading to macOS 15. Upgrade rewrites the device to use a fresh Fixed or Rotating MAC per SSID depending on whether the network is encrypted. Existing registrations referencing the old hardware MAC stop matching. Guide users to pick Off or Fixed if you need stable device identity.

​
Android and Windows

Android 10+ and Windows 10/11 randomize similarly, with per-SSID stability by default. Both expose a per-SSID toggle.

​
Enforce DHCP on Cisco WLC guest SSIDs

iOS devices aggressively cache the IP address they used last time they joined a network. If a guest reconnects to a guest SSID with a stale cached address, the captive-portal prompt may not fire until the device eventually re-requests DHCP — usually a 30-60 second delay, sometimes longer. The fix on Cisco WLC deployments is to enable DHCP Addr. Required on the guest SSID. With it on, the controller blocks traffic until a full DHCP handshake completes, so iOS devices are forced to request a fresh lease immediately. The captive-portal prompt then appears reliably. Enable it on every guest SSID served by a Cisco WLC.

​
802.11r fast transitions

802.11r speeds up roaming between APs by letting a device pre-authenticate ahead of an actual handover. In a controlled client population (office laptops, corporate mobiles) it works well. On guest networks it often causes connectivity failures: some Android devices fail to associate, some iOS devices drop off immediately after connecting, some clients loop on authentication. Best practice on guest SSIDs: disable 802.11r. Enable it only on WPA2-Enterprise / WPA3-Enterprise SSIDs where you control the client mix. Beyond association problems, two Sign In-specific quirks to be aware of if you do leave 802.11r on:
  • Lingering sessions after the client leaves. When a client roams out and disconnects, the WLAN controller may not report the disconnect until the session timeout. Expect drift between “actually gone” and “session closed” on the Dashboard.
  • Session moves between APs. Site-based redirects evaluate at sign-in time, not continuously. If a guest signs in at AP-A (Site 1) and roams to AP-B (Site 2), the redirect they received is still from Site 1. Site changes take effect on the next sign-in.

​
iOS Private Relay

iOS Private Relay tunnels traffic through Apple’s proxy, which can defeat captive-portal detection on the first connection. Apple’s own logic typically disables Private Relay until the captive portal is cleared, but some versions have bugs. If a guest’s iPhone seems stuck, the guest may need to temporarily turn off Private Relay in Settings.

​
Connectivity-probe quirks

  • Walled-garden gaps. If the OS’s probe endpoint is blocked pre-auth, the OS concludes “no internet” and may never escalate to the captive portal. Add the probe endpoints to the Walled Garden if you see this pattern.
  • Aggressive probe caching. Some Android versions cache the “no internet” verdict; the guest has to explicitly forget and rejoin the SSID.

​
When nothing else helps

Ask the guest to:
  1. Open a fresh browser tab and visit any HTTP (not HTTPS) site — e.g. neverssl.com. HTTP requests usually trigger the captive-portal redirect unambiguously.
  2. If that doesn’t work, forget the SSID and rejoin.
  3. If still stuck, toggle airplane mode or cycle Wi-Fi.

DHCP Option 114

Modern discovery that sidesteps most probe-endpoint issues.

Walled garden

Where probe endpoints and IdP hostnames live.