Cisco Meraki के लिए Captive Portal

Welcome to the Purple Technical Briefing Series. I'm your host, and today we're covering something that comes up on almost every enterprise guest WiFi deployment we work on: configuring a captive portal on Cisco Meraki MR access points, and specifically how to integrate that with Purple's cloud platform using RADIUS authentication. Whether you're an MSP onboarding a new hospitality client or an in-house network architect at a retail chain, this episode will give you the precise configuration steps and the reasoning behind each one. Let's set the scene. You've got a venue — could be a hotel, a conference centre, a stadium, or a retail park — running Cisco Meraki MR access points managed through the Meraki Dashboard. The brief is to deploy a branded guest WiFi experience that captures first-party data, enforces terms of service acceptance, and feeds analytics back into a marketing platform. That's exactly what Purple is built to do, and Meraki is one of our most common hardware deployments globally. Now, the key architectural point to understand before you touch a single setting is this: on Cisco Meraki, RADIUS authentication for a splash page is not processed locally by the access point. The RADIUS Access-Request is sourced from the Meraki cloud — from the Dashboard infrastructure — not from the AP on your LAN. This is a critical distinction that catches out a lot of engineers on their first Meraki deployment. It means your RADIUS server, in this case Purple's cloud RADIUS endpoint, needs to be reachable from the internet, and your firewall rules need to permit traffic from Meraki's Dashboard IP ranges, not just from your local AP subnet. You'll find the current Dashboard IP ranges under Help, then Firewall Info in your Meraki Dashboard. Right, let's get into the configuration. I'll walk you through this in the order you'd actually do it in a live deployment. Step one: SSID configuration. In the Meraki Dashboard, navigate to Wireless, then Configure, then SSIDs. Select the SSID slot you want to use for guest access. Give it a clear name — something like GuestWiFi or VenueName underscore Guest. Under the Association requirements, set Security to Open, no encryption. This is correct and intentional — the security layer for guests is handled by the captive portal and the RADIUS authentication, not by WPA encryption. If you're deploying in a PCI DSS environment, you'll want to ensure guest traffic is isolated on its own VLAN, which we'll cover shortly. Step two: Splash page and authentication. Still on the Access Control page for your SSID, scroll down to the Splash page section. Set it to Sign-on with, and from the dropdown, select my RADIUS server. This is the critical setting that tells Meraki to authenticate users against an external RADIUS server before granting network access. Below that, you'll see the Captive portal strength option. Set this to Block all access until sign-on is complete. This is what enforces the walled garden — without it, guests could bypass the portal entirely. Step three: RADIUS server configuration. Under the RADIUS section, click Add server. You'll need three pieces of information from your Purple account: the RADIUS server IP address or FQDN, the authentication port which is UDP 1812, and the shared secret. Purple provides these in the venue configuration section of the portal. For redundancy in production deployments, you should add a secondary RADIUS server — Purple provides a failover endpoint. Set the accounting port to UDP 1813 if you want session data fed back into Purple's analytics engine, which I'd strongly recommend for any venue where dwell time and session duration are meaningful metrics. A quick note on RADIUS attributes. Meraki honours the Session-Timeout attribute returned in the RADIUS Access-Accept response. Purple uses this to control how long a guest session lasts before re-authentication is required. For a hotel, you might set this to 86,400 seconds — that's 24 hours. For a coffee shop, something like 3,600 seconds, one hour, is more appropriate. The Idle-Timeout attribute is also honoured, but only if RADIUS accounting is enabled. This disconnects idle sessions, which is important for capacity management in high-density venues. Step four: Splash page URL. Navigate to Wireless, then Configure, then Splash page. Select your guest SSID from the dropdown. Set the Custom splash URL to the Purple portal URL for your venue. This is the URL that Meraki will redirect unauthenticated clients to. Meraki appends query parameters to this URL — including a login_url parameter — which Purple uses to complete the authentication handshake. Do not modify or strip these parameters. Step five: the walled garden. This is where most deployments run into trouble. The walled garden is the list of domains and IP ranges that a guest device can reach before they've authenticated. Without the correct entries, the captive portal page itself won't load, because the browser will be blocked from reaching the Purple CDN and the social login providers. Navigate back to Access Control for your guest SSID. Set Walled garden to Walled garden is enabled. In the Walled garden ranges field, you need to add the following. First, the Purple platform domains: star dot purple dot ai, and star dot venuewifi dot com. Second, the CDN domains that Purple uses to serve portal assets: star dot cloudfront dot net, and star dot akamaihd dot net. Third, the Meraki redirect infrastructure: star dot network-auth dot com. Fourth, if you're offering social login options, you need the relevant OAuth domains. For Google: accounts dot google dot com, star dot googleapis dot com, star dot gstatic dot com. For Facebook: star dot facebook dot com, star dot fbcdn dot net, and connect dot facebook dot net. For Twitter or X: star dot twitter dot com and star dot twimg dot com. One important note on how Meraki handles wildcard domains in the walled garden. Meraki does support wildcard entries using the asterisk prefix, for example star dot cloudfront dot net. However, this is a DNS-based match — Meraki resolves the domain and allows the resulting IP addresses. This means that for CDN providers like CloudFront or Akamai, where the resolved IPs can change frequently, you should use the domain wildcard rather than static IP ranges. Static IP entries are fine for Purple's RADIUS endpoints, which are stable, but not for CDN traffic. Now let's talk about two real-world scenarios I've worked on directly. The first is a 350-room hotel in the UK. The client was running Meraki MR46 access points across three buildings, with about 400 concurrent guest devices at peak. The initial deployment used a click-through splash page — no RADIUS, just terms acceptance. The problem was they had zero insight into who was connecting, no email capture, and no way to run post-stay marketing campaigns. We migrated them to Purple with RADIUS-based sign-on. The configuration was straightforward, but the gotcha was that their upstream firewall was blocking outbound UDP on port 1812 to anything outside the local subnet. Once we added the Meraki Dashboard IP ranges to the firewall allow-list, authentication worked immediately. Post-deployment, the hotel captured email addresses from approximately 68 percent of connecting guests in the first month, and their marketing team ran a re-engagement campaign that drove a measurable uplift in direct bookings. The second scenario is a retail chain with 45 stores, each running Meraki MR33 access points. The challenge here was scale and consistency. Manually configuring 45 SSIDs with the correct RADIUS settings and walled garden lists would be error-prone and time-consuming. The solution was to use Meraki's template-based configuration. We built a single network template with the correct SSID, RADIUS, and walled garden settings, then bound all 45 store networks to that template. Any change — say, adding a new social login provider to the walled garden — is made once in the template and propagates to all stores automatically. Purple's analytics then aggregated footfall and dwell time data across all stores, giving the retail operations team a single dashboard view of guest behaviour by store, by region, and by time of day. Let me give you three rules of thumb that will save you time on every Meraki captive portal deployment. Rule one: Always check the Meraki Dashboard IP ranges before you configure RADIUS. The ranges change occasionally, and if your firewall is blocking them, authentication will fail silently from the user's perspective — they'll just see the portal page hang. Use the built-in RADIUS test tool in the Dashboard under Access Control to verify connectivity before you go live. Rule two: Use domain wildcards in the walled garden, not IP ranges, for any CDN-hosted content. CDN IP ranges are large and change frequently. A wildcard domain entry is more maintainable and more reliable. Rule three: Enable RADIUS accounting on port 1813 even if you think you don't need it yet. Session data is valuable for troubleshooting disconnection issues and for feeding accurate dwell time metrics into your analytics platform. It costs nothing to enable and is very hard to retrofit after the fact. Now, a few rapid-fire questions I get asked regularly. Can I use Meraki's built-in splash page instead of Purple? Yes, but you lose the data capture, the analytics, the marketing automation, and the GDPR-compliant consent management. The built-in splash is fine for a basic click-through, but it's not a guest intelligence platform. Does this configuration work on Meraki MX firewalls as well as MR access points? The RADIUS splash page configuration is supported on MR access points. MX appliances handle client VPN authentication differently. For guest WiFi specifically, you're configuring the MR SSIDs. What about WPA3? Meraki MR access points support WPA3 on enterprise SSIDs. For guest captive portal deployments, the SSID is typically Open, so WPA3 doesn't apply directly. However, if you're deploying a Passpoint or OpenRoaming SSID alongside your captive portal SSID — which Purple supports — that SSID uses WPA3-Enterprise with 802.1X, and that's where WPA3 becomes relevant. To wrap up: the Cisco Meraki and Purple integration is well-tested and reliable, but it requires attention to three things: RADIUS source IP routing, walled garden completeness, and session timeout configuration. Get those three right and the deployment is straightforward. The business case is clear — venues that deploy a properly configured guest WiFi platform with data capture consistently see measurable returns in marketing engagement and operational insight. If you want to go deeper, check out Purple's guide on implementing 802.1X authentication with cloud RADIUS, and our Cisco Wireless AP deployment guide on the Purple blog. Both are linked in the show notes. Thanks for listening. If you've got a specific deployment scenario you'd like us to cover, get in touch with the Purple technical team. We'll see you in the next episode.