Skip to main content

Cisco Meraki and guest WiFi: captive portal setup with Purple

How Cisco Meraki access points and MX and Z-series appliances work with Purple guest WiFi: external web authentication, RADIUS and a walled garden, with a link to Purple's step-by-step setup guide for the exact configuration.

📖 2 min read📝 426 words📚 5 key definitions

Listen to this guide

View podcast transcript
Cisco Meraki Integration with Purple WiFi — A Senior Consultant Briefing Running time: approximately 10 minutes INTRODUCTION AND CONTEXT (approximately 1 minute) Welcome. If you are responsible for a Cisco Meraki deployment and you are trying to decide whether Purple WiFi is the right guest intelligence layer to sit on top of it, this briefing is for you. I am going to take you through exactly how the integration works, what you need to configure, where the common pitfalls are, and what kind of return you should realistically expect. Let me set the scene. Cisco Meraki is, by a significant margin, the most widely deployed cloud-managed wireless infrastructure in the enterprise hospitality, retail, and public-sector space. It is reliable, scalable, and its cloud dashboard is genuinely excellent. But here is the thing — Meraki's native guest WiFi capabilities are functional, not strategic. You can get a guest online, but you cannot capture meaningful first-party data, you cannot build a marketing funnel from it, and you certainly cannot demonstrate ROI to your board. That is precisely the gap that Purple fills. TECHNICAL DEEP-DIVE (approximately 5 minutes) Let us talk architecture. The Purple and Meraki integration operates across two distinct technical layers, and understanding both is essential before you touch a single configuration setting. The first layer is the Meraki Dashboard API — this is the provisioning layer. Purple uses Meraki's REST API to import your entire access point estate into the Purple Portal in a single batch operation. You authenticate with your Meraki API key, which you generate from the Organisation section of the Meraki dashboard under API and Webhooks. Once Purple has that key, it can pull every access point, every network, every SSID configuration directly from your Meraki cloud. For an estate of, say, three hundred access points across a hotel group, this reduces what would be a multi-day manual configuration exercise to something you can complete in under an hour. That is not a trivial operational saving. The second layer is the authentication and captive portal layer — this is where the guest experience actually lives. Purple operates as an external splash page provider, using Meraki's Captive Portal API. When a guest connects to your guest SSID, Meraki intercepts their HTTP traffic and redirects them to Purple's hosted splash page — your branded captive portal. The guest authenticates through whatever method you have configured: social login, email form, SMS verification, or a combination. Purple then communicates back to Meraki via RADIUS — Remote Authentication Dial-In User Service — operating on port 1812 for authentication and port 1813 for accounting. Once RADIUS confirms the authentication, Meraki grants the guest full network access. Now, let me walk you through the specific Meraki dashboard configuration, because the details matter here. In the Meraki dashboard, navigate to Wireless, then Access Control. Select your guest SSID from the dropdown. Set the security to Open — yes, open, because the authentication is handled by the RADIUS and captive portal layer, not at the 802.11 association level. Set the splash page type to Sign-on with my RADIUS server. This is the critical selection — it tells Meraki to use an external RADIUS server for authentication rather than its own built-in options. Under Advanced Splash Settings, set the captive portal strength to Block all access until sign-on is complete. Enable the walled garden — this is the list of domains that guests can reach before they have authenticated, which must include Purple's platform domains so the splash page itself can load. Purple provides a maintained whitelist of these domains in their support documentation. For the RADIUS server configuration, you will need to add two servers — Purple provides primary and secondary endpoints for redundancy. The authentication port is 1812, and you will use the RADIUS secret provided in your Purple Portal. Add corresponding entries for RADIUS accounting on port 1813. Set the accounting interim interval to four minutes — this is important for accurate session tracking and analytics. Set the server timeout to five seconds with a retry count of three. Under Advanced RADIUS Settings, configure the Called-Station-ID and NAS-ID to use the AP MAC address. This is critical for Purple's location analytics — without it, Purple cannot accurately attribute sessions to specific access points and therefore cannot generate meaningful floor-level analytics. Then navigate to Wireless, Splash Page. Enter the custom splash URL provided by your Purple Portal — this is the URL of your branded captive portal. Configure the post-authentication redirect URL — typically your venue's website or a specific landing page. Now, there is a second component worth discussing in detail: PurpleConnex, which is Purple's SecurePass solution. This creates a second SSID — typically named PurpleConnex — configured as a WPA2 Enterprise network using Purple's RadSec RADIUS servers. RadSec is RADIUS over TLS, which provides encrypted transport for authentication traffic. This SSID, combined with Hotspot 2.0 configuration — also known as Passpoint, the IEEE 802.11u standard — allows returning guests to reconnect automatically without seeing the captive portal again. Their device recognises the Passpoint profile and connects seamlessly. This is particularly valuable in environments where you want to eliminate the friction of repeat authentication, such as a hotel where a guest is staying for three nights, or a retail loyalty member who visits weekly. The Hotspot 2.0 configuration in Meraki requires you to set the operator name to PURPLE colon GB, configure the domain list to securewifi.purple.ai, and add the Roaming Consortium OIs that Purple specifies. The NAI Realm is configured with EAP-TTLS and PAP authentication method. This is all documented in Purple's support portal, and it is straightforward once you understand what each field is doing. IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approximately 2 minutes) Let me give you the three most common failure modes I see in Meraki and Purple deployments, and how to avoid them. First: walled garden misconfiguration. If your walled garden list is incomplete, guests will see a broken splash page — the CSS will not load, images will not render, and authentication will fail silently. Purple maintains a current whitelist of required domains. Treat this list as a living document and review it whenever Purple releases a platform update. I recommend testing the captive portal experience from a guest device on a separate network segment before go-live. Second: RADIUS timeout settings. The default Meraki RADIUS timeout is often set too low for cloud-hosted RADIUS servers. Five seconds with three retries is the correct configuration. If you leave it at the default two seconds, you will see intermittent authentication failures during peak load — exactly the worst time for your guest experience to degrade. Third: NAS-ID and Called-Station-ID misconfiguration. This is the one that catches engineers out most often. If you configure these fields incorrectly — or leave them as defaults — Purple's analytics engine cannot map sessions to specific access points. You will get aggregate data but no floor-level intelligence. The value must be set to AP MAC address, not SSID name or any other option. On the compliance side: Purple's data capture is GDPR and CCPA compliant by design. The captive portal presents a consent mechanism that meets the requirements of both regulations. If you are operating in a PCI DSS scope environment — a hotel with a payment terminal on the same network segment, for example — ensure your guest SSID is on a separate VLAN with appropriate firewall rules. Meraki's NAT mode for client IP assignment, which is the recommended setting, provides a degree of isolation, but your network segmentation architecture needs to be reviewed by your security team independently. RAPID-FIRE Q AND A (approximately 1 minute) Question: Can Purple integrate with Meraki MX security appliances as well as wireless APs? Answer: Yes. The configuration process is essentially identical — the MX supports the same splash page and RADIUS configuration as the wireless APs. The support article covers AP, MX, and Z1 teleworker gateway configurations. Question: How long does a full deployment take for a 50-site hotel group? Answer: With the automated provisioning via the Meraki API, the access point import is a single operation per organisation. The SSID and RADIUS configuration can be templated across networks. A 50-site deployment with a competent network engineer should be achievable in two to three days of configuration work, plus testing time. Question: Does Purple support Meraki's newer Wi-Fi 6 and Wi-Fi 6E access points? Answer: Yes. The integration operates at the application layer — RADIUS and HTTP redirect — so it is hardware-generation agnostic. Purple works with any Meraki AP that supports the splash page and RADIUS configuration described. SUMMARY AND NEXT STEPS (approximately 1 minute) To summarise: the Cisco Meraki and Purple WiFi integration is a mature, well-documented deployment that combines Meraki's excellent cloud-managed infrastructure with Purple's guest intelligence and data capture capabilities. The integration uses two primary mechanisms — the Meraki Dashboard API for automated provisioning, and the Captive Portal API with RADIUS authentication for the guest experience layer. The three things to get right are: your walled garden configuration, your RADIUS timeout and retry settings, and your NAS-ID configuration for accurate location analytics. The business case is compelling. McDonald's Belgium, Walmart Canada, and Harrods are all live Purple and Cisco deployments. AGS Airports achieved an 842 percent return on investment. Harrods turned 600,000 WiFi logins into a 57 times return on investment. If you are ready to move forward, the next step is to generate your Meraki API key, log into the Purple Portal, and use the Hardware Import Wizard to pull in your access point estate. From there, your Purple account team can walk you through the SSID and RADIUS configuration in a single session. Thank you for your time.

Cisco Meraki access points, and the MX and Z-series appliances, are cloud-managed from the Meraki dashboard and run the radio side of your network. Purple adds the guest layer on top: the captive portal your visitors see, the sign-in journey, and the first-party data you collect. It does not replace any of your Meraki kit.

How Cisco Meraki works with Purple guest WiFi

Purple is a cloud overlay. Your Meraki gear keeps running the WiFi; Purple runs the guest experience through two standard mechanisms the dashboard already supports.

  • External web authentication. You point the SSID at a custom splash page hosted by Purple and set the splash mode to sign-on with a RADIUS server. A new device is held at the splash page until the visitor signs in, then control passes back to Meraki.
  • RADIUS. Meraki checks each sign-in against Purple's RADIUS service on the standard ports, 1812 for authentication and 1813 for accounting. The accounting data is what powers your visitor analytics.

A walled garden, a short allow-list of addresses a device can reach before it signs in, lets the splash page load and any payment or social-login steps complete.

That is the whole model: Meraki moves the packets, Purple owns the sign-in and the data. Because it runs on standard web authentication and RADIUS, it works the same way across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Purple is hardware-agnostic by design.

What you need

  • A Cisco Meraki network (AP, MX or Z-series) with admin access to the Meraki dashboard.
  • A Purple venue with your splash page and sign-in journey set up.
  • Your Purple RADIUS details and walled garden addresses, from your Purple dashboard.

Set it up with Purple

The exact dashboard settings, the access-control splash mode, the RADIUS authentication and accounting servers, the walled garden and the splash page URLs, are documented step by step in Purple's support guide, with the precise values to enter.

Cisco Meraki AP / MX / Z1 setup guide

Follow that guide for the configuration. This page explains how the pieces fit together, so you know what each step is doing.

What you get

Once guests sign in through Purple, every visit becomes verified, conscious-choice opt-in first-party data: who visited, how often, and how to reach them with permission. That is the difference between WiFi that connects people and WiFi that builds a marketing audience you own. Purple is GDPR-aligned and ISO 27001 certified, with 99.999% uptime across more than 80,000 live venues.

Key Definitions

Captive portal

The sign-in page a visitor sees before they get online. Purple hosts and runs it; Meraki redirects devices to it.

The guest layer Purple adds on top of your Meraki WiFi.

External web authentication

A splash-page mode that redirects an un-authenticated device to an externally hosted sign-in page, then resumes once the visitor signs in.

How Meraki hands the guest to the Purple splash page.

RADIUS

A standard protocol for checking sign-ins and recording session data, on ports 1812 (authentication) and 1813 (accounting).

How Meraki validates each guest against Purple and feeds analytics.

Walled garden

A short allow-list of addresses a device can reach before it has signed in.

Lets the splash page, payments and social login load pre-authentication.

Meraki dashboard

Cisco Meraki's cloud management console for access points, MX security appliances and Z-series devices.

Where the Meraki guest configuration is done.