Cisco Meraki captive portal troubleshooting: splash page, walled garden and RADIUS checklist

A Meraki captive portal that fails usually has one of four faults. The splash page type is wrong, or the walled garden is missing the portal's domains and assets. The grant URL hand-off may be broken, or the access points cannot reach RADIUS with a matching shared secret. The Meraki event log shows which fault you have.

What does a Meraki captive portal that is not working look like?

Three symptoms cover most support tickets. Each one points to a different link in the login chain.

• The splash page never appears. The device joins the SSID and gets an IP address, but no login prompt opens.
• The portal loops. The guest completes the form, taps connect and lands back on the login page.
• The portal accepts details but never grants access. The page reports success, yet the device stays captive.

A fourth symptom is quieter. Returning guests are asked to log in far more often than expected. That is rarely a portal fault. It is usually the splash frequency setting.

Before you change anything, confirm how the chain should work. On a Purple deployment, the Meraki access point redirects the device to Purple's splash page servers. The splash page collects the guest's details and issues a one-time login. The access point then passes that login to Purple's RADIUS server to complete authentication. The Purple captive portal support article describes this flow. Each symptom maps to one of those three hand-offs failing.

This guide assumes the SSID is already built. It complements the Meraki captive portal setup guide and does not repeat the setup steps.

What usually causes a Meraki splash page not to show or to loop?

The splash page type does not match the portal

Meraki offers click-through, sign-on with a RADIUS server, and external captive portal options. The portal and the SSID must expect the same method.

A click-through external portal releases the device by calling a grant URL. A sign-on external portal posts credentials, which the access point checks against RADIUS. If the SSID and the portal disagree, the hand-off fails and the guest loops.

The walled garden is incomplete

The walled garden lists the destinations a device can reach before it authenticates. Meraki accepts entries as domains or IP ranges. If the portal's own domain is missing, the splash page cannot load at all.

Missing assets cause subtler faults. Stylesheets, images, fonts, content delivery networks and social login providers all load from their own hosts. If any are blocked, the page renders broken or the login button does nothing.

The walled garden can also be too generous. Devices run a Captive Network Assistant (CNA), which checks a predefined domain to test for internet access. If that probe domain is reachable before login, the device concludes it is online. It then never shows the login prompt.

The grant URL or continue URL is lost

With an external captive portal, Meraki appends parameters to the redirect. These include a base grant URL and the continue URL the guest originally requested. The portal must send the device back to the grant URL to release it.

If the portal drops, rewrites or caches those parameters, the access point never receives the grant. The guest sees a success message, then the next page load redirects them to the login page again.

RADIUS is unreachable or the shared secret is wrong

Sign-on with RADIUS depends on the access points reaching the RADIUS server. RADIUS is the Remote Authentication Dial-In User Service protocol, defined in RFC 2865. The server treats each sender as a RADIUS client and checks a shared secret on every request.

Two faults dominate. A firewall blocks RADIUS traffic from the access points, or the shared secret differs between dashboard and server. Either way, the portal collects details but authentication never completes.

NAT mode and bridge mode change what to check

In NAT mode, the access point assigns client addresses itself. Upstream devices see traffic from the access point, not from the client. In bridge mode, clients take addresses from your DHCP server on your LAN or VLAN.

Bridge mode adds failure points you own. These include an exhausted DHCP scope, a VLAN not trunked to the access point, and upstream DNS or firewall rules blocking portal hosts.

How do you work out which cause you have?

Work from the client outwards. Test with one device, and forget the network between attempts so each test starts clean.

Symptom	What the event log shows	Most likely cause	First check
No splash page appears	Association, but no splash redirect	CNA probe domain reachable, or DHCP or DNS failure	Confirm the device has an IP and DNS, then open neverssl.com
Splash page blank or unstyled	Splash redirect, page incomplete	Walled garden missing asset hosts	Browser developer tools, list every blocked host
Loops after submit	Repeated splash redirects, no grant	Grant URL parameters lost, or splash type mismatch	Compare the redirect query string with what the portal returns
Success message, no internet	Authentication attempts that fail or time out	RADIUS blocked or shared secret mismatch	RADIUS server logs for requests from the access points
Returning guests re-prompted	New splash events for known devices	Splash frequency too short	Splash frequency setting on the SSID
Desktop certificate warning	Redirect completes	Login page served over HTTP	Certificate on the portal host

Reading the Meraki event log

Open the network event log in the Meraki dashboard and filter by the test device's MAC address. Then filter to splash and authentication event types.

Read the events in time order: association, address assignment, splash redirect, authentication. The point where the sequence stops is where the fault sits. No splash event means the redirect never fired. A splash event with no authentication event points at the portal or the grant URL. A failed authentication event points at RADIUS.

How do you fix it on Meraki MR networks and client devices?

Follow the vendor steps in the Purple captive portal support article. The fixes below tell you what to change and why.

Fix the walled garden

Load the splash page on a device outside the guest network, with developer tools open. Record every host the page calls, including social login providers. Add each one to the walled garden as a domain or IP range. Remove anything that matches a CNA probe domain.

Fix the grant URL hand-off

Capture the full redirect URL from a failing device. Confirm the portal returns the device to the base grant URL with the parameters intact. Check that no proxy, link shortener or cache sits between the portal and the device.

Fix RADIUS

Confirm the access points can reach the RADIUS server on the configured ports. Re-enter the shared secret on both sides, from one copy, at the same time. Then check the server log for requests arriving from the access point addresses.

Fix client behaviour

Android shows a "you may need to log in" notification that opens the CNA. Some handset makers alter this behaviour, so test on the models your guests carry. If a guest misses the prompt, Purple recommends opening a browser and visiting neverssl.com. That site avoids SSL redirect problems because it never uses HTTPS.

Desktop browsers warn when a login page is served over plain HTTP. Purple's Cisco WLC certificate article covers the equivalent fault on Cisco WLCs. The fix there is a publicly trusted certificate whose Common Name matches the portal hostname. The same principle applies to any portal host.

Other vendors

Purple is hardware-agnostic. The same checks apply on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Only the menu names differ.

Two worked scenarios

A 200-room hotel after a portal redesign

Situation. A city-centre hospitality venue refreshed its splash page with new fonts and a social login button. Afterwards, guests saw a blank page with no login button.

What was done. The IT team loaded the new page with developer tools open and found two blocked hosts. One was a font delivery network. The other was the social login provider. Both went into the walled garden.

Outcome. The page rendered fully on the next test. Front-desk complaints about guest access stopped the same day.

A 40-store retail chain after a firewall change

Situation. A retail chain tightened its head-office firewall. The next morning, shoppers in every store saw the success page but could not browse.

What was done. The event log showed authentication timeouts at every site. The new rule had blocked RADIUS traffic from the store access points. The team restored the rule for the RADIUS ports only.

Outcome. Authentication events returned to normal across all 40 stores within an hour of the change.

How do you stop Meraki captive portal faults happening again?

• Tie the walled garden to portal changes. Every design change triggers a walled garden review before go-live.
• Keep the SSID open. Purple recommends an open network for guest access, because the convention is familiar and reduces friction.
• Rotate shared secrets in pairs. Change the dashboard and the RADIUS server in one maintenance window.
• Test on four platforms. Android, iOS, Windows and macOS each handle the CNA differently.
• Use a trusted certificate. Serve the login page over HTTPS with a publicly trusted certificate.
• Separate staff from guests. Staff should authenticate by identity, not through a guest splash page. See How to Enable Single Sign On.

Purple runs Guest WiFi across 80,000+ live venues and processed 440 million logins in 2024 (Purple's own data). The same checklist applies in transport hubs serving passengers and in healthcare sites serving patients and visitors.

Frequently asked questions

Does Purple work with my existing Cisco Meraki access points?

Yes, Purple runs on your existing Cisco Meraki MR access points as a cloud overlay. You point the SSID's splash page at Purple and configure Purple's RADIUS details in the Meraki dashboard. No new hardware is needed. The Purple captive portal support article covers the configuration steps. The same approach works across the rest of a mixed estate.

Can Purple run Guest WiFi across a mixed-vendor estate?

Yes, Purple is hardware-agnostic and supports Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You manage one splash page and one login flow across every vendor, from one platform. This suits groups that have acquired sites with different hardware. It also suits estates that plan to replace access points gradually rather than in one project.

Should guest access run on an open SSID or a secured one?

Purple recommends an open SSID for guest access, because it is now the standard convention and guests recognise it. The captive portal handles the login step, so guests do not need a password before they connect. An open network reduces friction at the point of connection. Keep staff devices on a separate, identity-based network rather than sharing the guest SSID.

Is guest data captured through the splash page GDPR compliant?

Yes, Purple is certified to ISO 27001 and Cyber Essentials, and operates in line with GDPR and CCPA. Guests give conscious-choice opt-ins on the splash page, so marketing consent is explicit. The data you collect is first-party data, owned by your organisation. Purple is also a certified B Corp. Check your own privacy notice matches the fields your splash page collects.

Why do desktop browsers show a certificate warning before the login page?

Desktop browsers show a warning when the portal redirects to a login page over plain HTTP. Modern browsers expect login pages to use HTTPS, so they flag the connection as not private. The fix is a publicly trusted SSL/TLS certificate on the portal host. The certificate's Common Name must match the hostname the redirect uses. The warning does not block access, but it erodes guest trust.

Who handles RADIUS authentication when Purple runs the portal?

Purple's RADIUS server completes the login. The splash page issues a one-time login, and the Meraki access point passes it to Purple's RADIUS server. You enter Purple's RADIUS details and shared secret in the Meraki dashboard. Your firewall must allow RADIUS traffic from the access points to reach Purple. If the shared secret differs on either side, authentication fails.

How much effort is it to move from the Meraki splash page to Purple?

The move is a configuration change on each SSID, not a hardware project. You change the splash page type, add the walled garden entries and enter Purple's RADIUS details. Most effort goes into testing on Android, iOS, Windows and macOS before go-live. Plan a pilot site first, then roll the tested settings out to the rest of the estate.