Troubleshooting Captive Portal Redirects: Resolving Guest WiFi Connection Failures

When guest WiFi shows connected but no internet, the device has joined the network but the captive portal redirect has broken. The usual causes are a blocked operating system probe, missing walled garden entries or failed DNS. Others are an exhausted DHCP pool or a RADIUS Access-Accept that never reaches the gateway. Each is fixable in configuration.

What does "guest WiFi connected but no internet" look like?

The device joins the network name (SSID) and shows a full signal, yet nothing loads. Each platform reports it differently:

• iOS lists "No Internet Connection" under the network name.
• Android shows "Connected, no internet" or a "Sign in to network" prompt that leads nowhere.
• Windows marks the network "No internet".

The visitor sees a working WiFi icon and a dead browser, so they blame the venue.

One symptom can hide several different failures. You will usually see one of these patterns:

• The login page never appears on any device.
• The login page appears on iPhones but not on Android phones, or the reverse.
• The browser shows a certificate or privacy warning instead of the login page.
• The visitor completes the form, sees a success message, and still has no internet.
• Everything works at quiet times and fails at peak.

Each pattern points to a different layer of the network. Start by reading the pattern, not by rebooting access points.

How captive portal detection works

A captive portal is the web page a gateway shows before it grants internet access. The gateway is your controller, firewall or access point, depending on your design.

Every major operating system checks for a captive portal as soon as it joins a network. It sends a plain HTTP request to a known address and compares the reply with what it expects. Each outcome means something different:

• The reply matches. The device assumes it has open internet.
• The gateway returns an HTTP 302 redirect. The device knows it is behind a portal. It opens a lightweight browser window, often called the captive network assistant, and loads your login page.
• The request gets no reply. The device reports no internet and opens nothing.

Microsoft documents that its Network Connectivity Status Indicator (NCSI) also resolves dns.msftncsi.com as a DNS check. A Windows laptop can therefore report no internet when pre-authentication DNS is broken, even if HTTP works.

What usually causes a captive portal redirect to fail?

Seven causes account for most cases. They sit at different layers, from addressing up to authentication.

The operating system probe is blocked

The gateway's pre-authentication access control list (ACL) drops the probe instead of redirecting it. The device hears nothing back and decides there is no internet. It never opens the portal.

A DNS filtering service that blocks the probe hostnames has the same effect. This is the most common reason a portal never appears.

HTTPS and HSTS break the interception

HTTP Strict Transport Security (HSTS), defined in RFC 6797, tells browsers to reach a domain over HTTPS only. Browsers ship with a preload list of HSTS domains, including Google's and most banks'. When a visitor types google.com, the browser upgrades to HTTPS before the request leaves the device.

The gateway cannot redirect that request without presenting a certificate for google.com, which it does not hold. The browser shows a hard security warning with no way through.

The fix is to redirect only the plain HTTP probes in the table above, which exist for exactly this purpose. Never intercept HTTPS for portal redirection.

The walled garden is too narrow

The walled garden is the list of domains and IP addresses a device can reach before it authenticates. If an entry is missing, the login page loads partially or the sign-in step fails. The usual gaps are:

• Identity provider endpoints for social or single sign-on login, such as Microsoft Entra ID, Okta or Google Workspace.
• Content delivery network domains that serve your login page's fonts, scripts and stylesheets.
• Payment processor domains, if you charge for access.
• Purple's captive portal and RADIUS endpoints, listed in Purple's integration guide for your hardware.

DNS fails before authentication

The device must resolve the portal hostname before it can load the page. The redirect points nowhere in two cases:

• The gateway blocks DNS in the pre-authentication state.
• DHCP hands out a DNS server the device cannot reach.

Android adds a twist. If a visitor has set a specific Private DNS hostname, Android expects DNS over TLS on port 853. In automatic mode it falls back to ordinary DNS.

The DHCP pool is exhausted

When the address pool runs out, a new device associates with the access point but gets no IP address. Windows then assigns itself a 169.254.x.x link-local address, and other systems show a similar self-assigned state.

With no valid address, the device cannot send a probe. It looks connected but has no internet. This is the classic peak-time failure in stadiums, conference centres and transport hubs.

RADIUS never delivers the Access-Accept

RADIUS (Remote Authentication Dial-In User Service) carries the login decision from the authentication server to your gateway. The server replies Access-Accept or Access-Reject, as defined in RFC 2865. The gateway then opens access or keeps it closed.

A visitor who completes the form but stays offline almost always means the gateway missed the Access-Accept. The three usual causes are:

• A mismatched shared secret.
• A firewall blocking UDP 1812 (authentication) or UDP 1813 (accounting). RFC 2865 and RFC 2866 define these ports.
• The wrong server address on the controller.

The portal's own certificate has expired

Your login page is served over HTTPS. If its TLS certificate expires, every modern browser blocks the page with a security warning. The redirect works perfectly, yet the visitor still cannot sign in.

How do you work out which cause you have?

Work up the stack in order. Each check rules out one layer, so stop at the first failure.

1. Does the device have a valid IP address? Run ipconfig /all on Windows, or check the network details on a phone. A 169.254.x.x address, or no address at all, points to DHCP. Check pool utilisation on the DHCP server. Above 90%, you are close to exhaustion.
2. Does DNS resolve? From a device on the guest virtual LAN (VLAN), a logically separate network segment, look up the portal hostname. If the lookup fails, pre-authentication DNS is blocked or the DHCP-assigned DNS server is wrong.
3. Does the probe get a 302? Take a packet capture on the guest VLAN, or browse to one of the HTTP probe URLs. You should see the probe, then an HTTP 302 pointing to the portal. A probe with no reply means the ACL drops it. No probe at all means the device thinks it is already online, often from a cached state. Forget the network and rejoin.
4. Does the login page load completely? Open browser developer tools (F12) and watch the network tab. Blocked requests to third-party domains point to walled garden gaps.
5. Does the gateway receive an Access-Accept? Check the controller's RADIUS logs. A successful login is followed by an Accounting-Request with status Start. If no accounting record appears after login, the RADIUS path is broken.

Then match what you see against this table.

Worked scenario: a 1,500-seat conference centre at peak

Situation. A conference centre ran its attendee network on a single /24 subnet with an eight-hour DHCP lease. Morning keynotes ran smoothly. After lunch, attendees arriving for afternoon sessions saw "connected, no internet". The help desk treated it as a portal fault and restarted the controller twice.

What was done. Step 1 of the diagnosis found new devices holding 169.254.x.x addresses. A /24 offers 254 usable addresses, and the eight-hour lease kept every morning address reserved. The team moved the attendee VLAN to a /21 and cut the lease to 30 minutes.

Outcome. Usable addresses rose from 254 to 2,046, roughly eight times the previous capacity. An address left behind by a departing attendee now returns to the pool within 30 minutes, not eight hours. The fix took one change window and no new hardware.

Worked scenario: a 200-room hotel where Android guests could not sign in

Situation. After a login page redesign, a 200-room hotel received front desk complaints from Android guests. Most of them chose the Google sign-in option. The portal appeared, but the button did nothing.

What was done. The IT manager tested the flow on one iPhone, one Android phone and one Windows laptop. Developer tools on the laptop showed blocked requests to a font delivery network and to Google's sign-in domains. The redesign had added both. The team added them to the walled garden.

Outcome. Google sign-in completed on all three test devices at the first retest. The fix needed two walled garden entries and no hardware change.

Worked scenario: a 40-store retail estate after a firewall refresh

Situation. A retailer replaced the firewalls in 40 stores over a weekend. On Monday, shoppers in every refreshed store could complete the login form but stayed offline. Stores not yet refreshed worked normally.

What was done. Step 5 found no accounting records from the refreshed stores. The new firewall template denied outbound UDP by default, blocking 1812 and 1813. The team added explicit outbound rules to the template and pushed it to all 40 stores.

Outcome. Accounting records reappeared from every store after the push. Because only refreshed stores failed, the pattern pointed straight at the template and away from the WiFi.

How do you fix it on each operating system and controller?

The controller fix follows the same pattern on every platform. The operating system fixes are mostly about knowing how each one behaves.

On your controller

Purple runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. The fix pattern is the same on all eight:

1. Point the guest SSID at the external captive portal URL from your Purple integration guide, and disable any local splash page.
2. Redirect unauthenticated HTTP traffic, including the probes, to that URL. Leave HTTPS alone.
3. Allow DNS and DHCP before authentication.
4. Add the walled garden entries: Purple endpoints, identity provider endpoints and login page asset domains.
5. Enter the RADIUS server addresses and shared secret from your Purple dashboard. Then confirm the firewall allows outbound UDP 1812 and 1813.

Menu names differ by vendor and firmware version, so follow Purple's integration guide for your platform. Fortinet's community documentation on the FortiGate captive portal flow is a useful vendor-side reference for the redirect sequence.

On iOS and macOS

If the captive network assistant does not open, forget the network in Settings and rejoin. This forces a fresh probe.

Recent iOS and macOS releases also support the Captive Portal API. It lets the network advertise its portal through DHCP option 114, defined in RFC 8910, which reduces reliance on interception. If the assistant opens but stays blank, check the walled garden for asset domains.

On Android

Android shows a "Sign in to network" notification when it detects a portal. If the notification never appears, confirm the gateway redirects connectivitycheck.gstatic.com rather than dropping it.

If a visitor sees "Private DNS server cannot be accessed", their phone has a strict Private DNS hostname set. You have two options:

• Allow DNS over TLS on port 853 before authentication.
• Ask the visitor to switch Private DNS to automatic.

On Windows

Windows relies on the NCSI HTTP probe and its DNS check. If the portal does not open automatically, browse to any plain HTTP site to trigger the redirect manually. A persistent "No internet" after login usually means the gateway is still redirecting the probe. In that case, the gateway has not applied the Access-Accept.

In the browser

Brief front-line staff to send visitors to an HTTP address, never an HSTS domain such as google.com. Firefox runs its own probe against detectportal.firefox.com, so include that host in your redirect tests.

How do you stop guest WiFi redirect failures happening again?

Most repeat incidents come from change, not from the original build. A firmware update, a new firewall template, a login page redesign or an expiring certificate slips past testing. Build these controls into your change process:

• Test on three platforms after every change. Use one iPhone, one Android phone and one Windows laptop. If one platform fails while the others pass, look for a walled garden gap first.
• Size for peak, not average. Calculate the maximum number of concurrent devices and add headroom. Transient visitor networks commonly run leases of 15 to 30 minutes.
• Set sessions to match the visit. Hospitality and retail venues commonly set 24-hour sessions, so a guest signs in once per stay or visit.
• Watch login volumes daily. Purple's WiFi Analytics reports logins by venue. A sudden drop at one site warns you of a RADIUS or walled garden fault, often before visitors complain.
• Put certificates and shared secrets under change control. Diarise the portal certificate's expiry date. Store the RADIUS shared secret where firewall and controller teams can both check it.
• Segment guest traffic. Put guests on their own VLAN. PCI DSS treats segmentation as the way to keep a guest network out of scope of your cardholder data environment.
• Plan for MAC randomisation. Recent iOS and Android releases use a random MAC address for each network, and some modes rotate it over time. Session caching keyed on MAC address will then ask returning visitors to sign in again.
• Collect consent properly. GDPR requires informed, affirmative consent for marketing data. Purple's conscious-choice opt-ins present a separate choice for each purpose.

Take returning visitors off the captive portal

The most durable fix removes the redirect for repeat visits altogether.

• Passpoint is the industry certification built on the Hotspot 2.0 specification. It lets a device join a network automatically using a stored profile.
• OpenRoaming, run by the Wireless Broadband Alliance, federates identity providers. A visitor's existing credentials then work across participating venues.

Both use IEEE 802.1X, the standard for port-based network access control, so there is no portal to break.

Where Purple fits

Purple Guest WiFi runs as a hardware-agnostic cloud overlay, so you fix redirect faults in configuration, not with new hardware. Purple serves 80,000+ live venues in more than 90 countries and supports 500 million users and logins a year. The platform runs at 99.999% uptime and is ISO 27001, Cyber Essentials and B Corp certified. It is also GDPR and CCPA compliant.

When a portal fails, the cause is almost always local: a probe rule, a walled garden entry, a DHCP pool or a firewall rule.

The patterns repeat across verticals:

• Hotels feel redirect faults at check-in peaks.
• Retail estates feel them after estate-wide firewall changes.
• Trains and stations face DHCP pressure as passengers board in waves.
• Healthcare sites need patient and visitor WiFi that works without pulling clinical staff into support calls.

Frequently asked questions

Does Purple work with the access points we already own?

Yes. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep your existing access points and controllers. You point your guest SSID at Purple's captive portal, add the walled garden entries and RADIUS details from Purple's integration guide, and then test. There is no rip and replace.

Do we need new hardware to fix guest WiFi connected but no internet?

No. In almost every case the fault is configuration: a blocked probe, a walled garden gap, pre-authentication DNS, an exhausted DHCP pool or a RADIUS firewall rule. You fix each one on the controller, firewall or DHCP server you already run. Hardware only becomes the issue when access point density cannot serve your peak device count, which a site survey will show.

What does it take to move our guest WiFi to Purple?

Moving to Purple is a configuration project, not an installation project. On each controller, you set the guest SSID to Purple's external portal and add the walled garden and RADIUS settings. You then confirm firewall rules for UDP 1812 and 1813. Next, you build your login page and consent options in Purple and test on iOS, Android and Windows. Multi-site estates can template the controller settings.

Is a captive portal compliant with GDPR?

Yes, provided consent is informed, specific and freely given. GDPR requires a separate affirmative choice for each purpose, such as marketing email, and rules out pre-ticked boxes. Purple's conscious-choice opt-ins present each choice separately. Purple is ISO 27001 certified, holds Cyber Essentials and is GDPR and CCPA compliant. That gives your data protection officer the standards they will ask about.

Can returning visitors skip the login page?

Yes. Passpoint and OpenRoaming let a device join automatically using a stored profile or a federated identity. Both use IEEE 802.1X authentication with WPA2 or WPA3-Enterprise encryption, so there is no captive portal redirect to fail on repeat visits. Many venues run both: a captive portal for first-time visitors and data capture, and OpenRoaming for returning guests, passengers and students.

How will we know when logins start failing?

Watch login volumes by venue. Purple's WiFi Analytics reports logins for each site, so a sudden drop at one location stands out against its normal pattern and your other venues. That drop usually signals a RADIUS, walled garden or DHCP fault introduced by a recent change. Spotting it in the dashboard is faster than waiting for front desk complaints to reach IT.

Should we use a captive portal or a shared WiFi password?

Use a captive portal if you want first-party data and consent, and a shared password only if you need neither. A shared pre-shared key encrypts traffic with WPA2 or WPA3-Personal. However, it tells you nothing about who connected, and the password spreads. A captive portal captures consented first-party data, and Passpoint or OpenRoaming adds automatic, encrypted access for repeat visits.