topic Re: captive.apple.com Portal appearing in Wireless

captive.apple.com Portal appearing

perrymcgrew — Tue, 24 Feb 2026 12:15:37 GMT

All of a sudden, Apple devices are displaying the captive.apple.com "Success" page when attempting to join ANY wi-fi network. It is not a DNS resolution issue. Our internal DNS forwards to Cloudflare. We tried changing them to Google's 8.8.8.8 and it did not help.

There is no internal Firewall between the clients and the 9800L (17.12.05)

If I click on the "X" on the upper right corner of the Captive page and choose to continue with No Internet, the device will continue to connect to the SSID and have Internet access.

TAC claims it is a DNS resolution issue -- takes too long and that makes the Apple device "believe" there is a Captive Portal. Androids, which have there own captive portal probe and Windows devices are NOT seeing any issues.

I did a Curl -v http://captive.apple.com on our Firewall to test and got 200 return code - which is good. Trying to figure out next steps.

TIA

Re: captive.apple.com Portal appearing

Flavio Miranda — Tue, 24 Feb 2026 15:39:12 GMT

@perrymcgrew

What is the authentication method you are using? It is Guest network? Usually, apple and android devices when connected to a network, they try to reach some URL in order to check internet connectivity and this is used by the WLC to perform the redirect.

If you are using portal, it seems the redirect is not working.

Re: captive.apple.com Portal appearing

perrymcgrew — Tue, 24 Feb 2026 19:01:51 GMT

The SSIDs are using PSK. No captive portal is used. I discovered the root cause later this morning. I needed to run the curl *inside* my network to get complete picture. I ran it from my W11 laptop -- got the same 200 return code, but noticed that the site passes through our Anti-Phishing protection offered by the firewall. I created an exception rule for the url captive.apple.com that bypassed the Phishing protection. It worked - no captive portal - and the MDM controlled Apple devices could join immediately. The Phishing process must introduce just enough latency to make the Apple devices think they are behind a captive portal. We just applied vendor patch to our Firewall last week. Just to verify, i ran the curl against the published Android portal probe URL and the Phishing process lets it through. Placed a ticket in with our Firewall vendor for a formal fix / explanation.