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.