Skip to main content

Cisco Catalyst WLC and guest WiFi: captive portal setup with Purple

How a Cisco Catalyst 9800 (IOS-XE) wireless LAN controller works 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📝 399 words📚 5 key definitions

Listen to this guide

View podcast transcript
Welcome to the Purple technical briefing series. Today we're covering something that lands on the desk of almost every enterprise network architect working in hospitality, retail, or large-scale venues: integrating Cisco Wireless LAN Controllers and Catalyst wireless infrastructure with Purple's Guest WiFi platform. If you're running Cisco Catalyst 9800 series controllers, or the legacy AireOS platform, and you need to deliver a compliant, segmented, analytics-driven guest network, this is the briefing for you. [medium pause] Let's start with context. Purple operates across more than 80,000 live venues globally, and Cisco is the dominant wireless infrastructure vendor in enterprise environments. Getting these two platforms to work together cleanly is not complicated, but it does require you to make the right architectural decisions upfront. Get them wrong, and you'll spend weeks troubleshooting redirect loops, VLAN mismatches, and RADIUS timeouts. Get them right, and you have a network that segments guests, staff, and IoT devices automatically, collects first-party data compliantly, and scales across hundreds of sites without manual intervention. [medium pause] So let's get into the architecture. [short pause] When a guest connects to your WiFi network on a Cisco deployment, there are three things that need to happen before they reach the internet. First, the Cisco Catalyst 9800 WLC needs to intercept that initial HTTP request and redirect the client to Purple's captive portal. Second, Purple's portal needs to authenticate the user, whether that's via social login, email, SMS, or a simple terms-and-conditions acceptance. Third, Purple's RADIUS server needs to signal back to the WLC that the user is authorised, and optionally assign them to a specific VLAN. [medium pause] The mechanism that handles step one is called External Web Authentication, or EWA. On the Catalyst 9800, you configure a web authentication parameter map that points to Purple's splash page URL. The WLC intercepts all HTTP traffic from unauthenticated clients and issues a 302 redirect to that URL. You'll also need to configure a pre-authentication ACL, or use the 9800's URL filter feature, to whitelist Purple's portal IP addresses so clients can actually reach the splash page before they're authorised. Purple provides two IP addresses for its portal, and you'll need to permit both in your pre-auth ACL. [medium pause] Here's the configuration sequence for the Catalyst 9800. First, create the parameter map. Then configure your URL filter to permit Purple's domain pre-authentication. Apply this to your WLAN policy profile, set Layer 2 security to None, enable Web Policy on Layer 3, and point it at your parameter map. [medium pause] Now, RADIUS. Purple acts as the RADIUS server in this architecture. You configure the WLC to point to Purple's RADIUS endpoint, which you'll find in the Purple dashboard under your venue's network settings. The shared secret is generated per-venue. On the Catalyst 9800, navigate to Configuration, Security, AAA, Servers, and add Purple's RADIUS server with the correct IP and shared secret. Then create a server group, an authentication method list, and apply it to your WLAN. [medium pause] One thing that catches people out: on the 9800, you must also configure the virtual IP address in the global web auth parameter map. Use 192.0.2.1 as the virtual IPv4 address. If you skip this, clients sometimes get redirected to the internal portal instead of Purple's portal, and you'll spend a frustrating afternoon wondering why. [medium pause] Let's move on to Staff WiFi with 802.1X. [short pause] For staff networks, you want certificate-based authentication using EAP-TLS, or at minimum PEAP with MSCHAPv2 for environments where certificate deployment isn't feasible. On the Catalyst 9800, create a separate WLAN for staff, set Layer 2 security to WPA2 Enterprise, and point the authentication to your RADIUS server. If you're using Microsoft Entra ID or Okta as your identity provider, Purple's SecurePass add-on acts as the RADIUS proxy, translating 802.1X authentication requests into identity provider lookups. This means you don't need a separate on-premises RADIUS server for staff authentication. Purple handles the EAP termination and forwards the identity check to your identity provider. [medium pause] For EAP-TLS specifically, you'll need to deploy client certificates to staff devices, either via Microsoft Intune, Jamf, or a similar MDM platform. The certificate chain must be trusted by Purple's RADIUS server, which means uploading your root CA certificate to the Purple dashboard. Once that's in place, staff devices authenticate silently, no password prompts, no splash pages. The user connects, the certificate is validated, and they're on the staff VLAN within seconds. [medium pause] Now, the part that most architects find genuinely interesting: Cisco Identity PSK, or iPSK. [short pause] iPSK solves a specific problem that comes up constantly in multi-tenant environments. Imagine a hotel with 300 rooms, or a retail estate with 50 stores, or a build-to-rent development with 200 apartments. You want a single SSID, but you need each tenant, each room, or each device group to be isolated on its own VLAN. The traditional answer was to create a separate SSID per tenant, which doesn't scale and creates radio frequency congestion. iPSK gives you a single SSID where each client or group of clients has a unique pre-shared key, and the RADIUS server maps that key to a specific VLAN. [medium pause] Here's how it works technically. When a client associates to the SSID, the Catalyst 9800 WLC sends a RADIUS Access-Request to Purple's RADIUS server, including the client's MAC address. Purple's RADIUS server looks up that MAC address in its iPSK database, finds the associated PSK and VLAN assignment, and returns a RADIUS Access-Accept containing the Cisco AV-pair with the PSK, and the IETF tunnel attributes for VLAN assignment. The WLC uses the returned PSK to complete the WPA2 four-way handshake, and then places the client on the assigned VLAN. [medium pause] The three RADIUS attributes you need for dynamic VLAN assignment are: IETF attribute 64, Tunnel-Type, set to VLAN with a value of 13. IETF attribute 65, Tunnel-Medium-Type, set to 802, with a value of 6. And IETF attribute 81, Tunnel-Private-Group-ID, set to the VLAN ID as a string. These three attributes, sent together in the RADIUS Access-Accept, tell the WLC exactly which VLAN to assign. The VLAN must already exist on the WLC as a dynamic interface, and the uplink switch port must be configured as a trunk carrying all relevant VLANs. [medium pause] On the WLC side, enable MAC filtering on the iPSK WLAN, enable AAA Override, and set the Layer 2 security to WPA2-PSK. The global PSK you configure on the WLAN acts as a fallback only. The RADIUS-returned PSK takes precedence for any client whose MAC address is registered in Purple's iPSK database. For unregistered devices, you can either deny access or fall back to the global PSK, depending on your policy. [medium pause] Let me give you two real-world scenarios to make this concrete. [short pause] First scenario: a 200-room hotel. The hotel wants guests on VLAN 10 with internet access only, staff on VLAN 20 with access to the property management system, and IoT devices, door locks, thermostats, CCTV, on VLAN 30 with no internet access. They're running Cisco Catalyst 9800 controllers with Cisco 9100 series access points. [medium pause] The architecture: three policy profiles on the WLC, one per VLAN. A single SSID for guests using External Web Authentication pointing to Purple. A separate SSID for staff using WPA2 Enterprise with EAP-TLS, authenticated via Purple SecurePass against Microsoft Entra ID. And iPSK for IoT devices, with each device's MAC address registered in Purple's portal and assigned to VLAN 30. The hotel's property management system provisions new IoT devices via Purple's API, so when a new door lock is installed, its MAC address is automatically registered and assigned to the correct VLAN. No manual RADIUS configuration required. [medium pause] Second scenario: a retail chain with 80 stores. Each store has a guest WiFi network, a staff network, and a network for payment terminals. PCI DSS compliance requires the payment terminal network to be completely isolated from the guest network. The retailer uses Cisco Catalyst 9800-L controllers at each site, managed centrally via Cisco Catalyst Centre. [medium pause] Purple deploys as a cloud overlay. Each store's WLC is configured with Purple's RADIUS server details. Guest authentication uses a branded splash page with email capture, feeding first-party data into Purple's analytics platform. Staff authentication uses PEAP against Active Directory via Purple SecurePass. Payment terminals use iPSK with a dedicated VLAN, and the pre-auth ACL explicitly blocks any traffic between the payment VLAN and the guest VLAN, satisfying PCI-DSS requirement 1.3 for network segmentation. [medium pause] Now let's talk about the pitfalls. [short pause] The most common failure mode is the redirect loop. This happens when the pre-auth ACL doesn't correctly whitelist Purple's portal IP addresses, so the WLC redirects the client to Purple's portal, but the client can't reach the portal because the ACL blocks it, so the WLC redirects again, indefinitely. Fix: verify your URL filter or pre-auth ACL includes both of Purple's portal IP addresses, and confirm DNS resolution is permitted pre-authentication. [medium pause] The second common issue is VLAN mismatch. The RADIUS server returns a VLAN ID that doesn't exist as a dynamic interface on the WLC. The WLC then places the client on the native VLAN, which is usually the management VLAN. This is a security risk. Fix: before deploying, audit your WLC dynamic interfaces against the VLAN IDs configured in Purple's RADIUS policies. They must match exactly. [medium pause] Third pitfall: certificate trust failures in EAP-TLS deployments. If the client's certificate chain isn't trusted by Purple's RADIUS server, authentication fails silently from the user's perspective. They just can't connect. Fix: upload your root CA and any intermediate CA certificates to Purple's SecurePass configuration before deploying client certificates. Test with a single device before rolling out to the fleet. [medium pause] Quick-fire questions. [short pause] Can I use Purple with Cisco Meraki instead of WLC? Yes. Cisco Meraki has its own captive portal integration mechanism, and Purple supports it natively. The RADIUS configuration is similar but uses Meraki's dashboard rather than the WLC command line. [short pause] Does Purple support WPA3 on Cisco? Yes. WPA3-SAE is supported on Cisco Catalyst 9800 with IOS-XE 17.3 and later. Purple's RADIUS integration works identically with WPA3. [short pause] What's the RADIUS timeout recommendation? Set your primary RADIUS server timeout to three seconds with two retries. Configure a secondary RADIUS server for failover. Purple provides redundant RADIUS endpoints for enterprise customers. [short pause] Can I use Cisco ISE alongside Purple? Yes. Some organisations use ISE for posture assessment and device profiling while using Purple for guest portal and analytics. The two RADIUS servers are configured on separate WLANs. [medium pause] To summarise. [short pause] Cisco WLC and Catalyst wireless infrastructure integrates cleanly with Purple using External Web Authentication for guest captive portal redirection, 802.1X EAP-TLS or PEAP for staff authentication via Purple SecurePass, and Cisco iPSK with dynamic VLAN assignment for multi-tenant and IoT segmentation. The three RADIUS VLAN attributes, Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private-Group-ID, are the mechanism that drives dynamic segmentation. Get your pre-auth ACLs right, match your VLAN IDs between RADIUS and WLC, and test certificate trust chains before fleet deployment. [medium pause] Purple operates across more than 80,000 venues and has processed 440 million logins in 2024. The Cisco integration is one of our most deployed configurations globally. If you want to get started, the Purple dashboard walks you through RADIUS configuration per-venue, and our integration team is available for enterprise deployments. [medium pause] That's it for this briefing. Thanks for listening.

Cisco Catalyst 9800 wireless LAN controllers running IOS-XE handle 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 Cisco kit.

How Cisco Catalyst works with Purple guest WiFi

Purple is a cloud overlay. Your Catalyst controller keeps running the WiFi; Purple runs the guest experience through two standard mechanisms your controller already supports.

  • External web authentication. The controller redirects a new device to your Purple splash page instead of granting access straight away. The visitor signs in, and the page hands control back to the controller.
  • RADIUS. The controller 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: Cisco 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 Catalyst 9800 controller on IOS-XE, with admin access to the web interface.
  • 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 controller settings, the Web Auth parameter map, the AAA server entries, Change of Authorisation and the walled garden, are documented step by step in Purple's support guide, with the precise values to enter.

Cisco Catalyst WLC (IOS-XE) 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; your controller redirects devices to it.

The guest experience layer Purple adds on top of your Cisco WiFi.

External web authentication

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

How the Catalyst controller hands the guest to the Purple splash page.

RADIUS

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

How the controller 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.

Change of Authorisation (CoA)

A RADIUS message that updates or ends a session after it has started.

Used to move a guest's access once they have signed in.