Cisco WLC and Catalyst Integration with Purple WiFi: Step-by-Step Guest Access Guide

Welcome to the Purple Technical Briefing. I'm your host, and today we're covering a definitive deployment scenario for enterprise network architects: integrating Cisco Wireless LAN Controllers and Catalyst 9800 hardware with the Purple WiFi platform. If you manage IT for a hotel chain, a retail network, or a large public venue, you know that relying on basic Pre-Shared Keys is an unacceptable security risk. Today, we'll outline the step-by-step architecture to segment your network, secure your staff, and turn your guest WiFi into a data-driven asset. Let's establish the context. An enterprise wireless environment must handle three distinct profiles: Guests, Staff, and Headless or Tenant devices. You cannot treat them the same, and you cannot broadcast twenty different SSIDs to accommodate them. The solution is a unified hardware footprint leveraging different authentication mechanisms on a single Cisco Catalyst 9800 Wireless LAN Controller. Now let's dive into the technical architecture. The first tier is Guest WiFi. The goal here is low-friction access combined with data capture. We achieve this using an open SSID and Central Web Authentication, or CWA. When a guest connects, the Cisco WLC applies a pre-authentication Access Control List. This is your walled garden. It blocks general internet access but permits traffic to Purple's domains and essential services. When the guest tries to browse, the WLC intercepts the HTTP request and redirects them to the Purple captive portal splash page. Once they authenticate, perhaps via a registration form, a social login, or a one-time code, Purple acts as the RADIUS server. It sends a Change of Authorization message, known as a CoA, to the WLC. This moves the client to an isolated guest VLAN and grants internet access. The entire flow is automated, and every login is recorded in Purple's analytics platform. The second tier is Staff WiFi. For corporate devices, we mandate 802.1X authentication. Specifically, EAP-TLS, which stands for Extensible Authentication Protocol Transport Layer Security. This method uses digital certificates installed on corporate devices via your Mobile Device Management platform, whether that's Microsoft Intune, Jamf, or another solution. The WLC acts as the authenticator, passing EAP messages to the RADIUS server. Because we use certificates, there are no passwords to steal. If a device is lost or an employee leaves, you revoke the certificate. Access is terminated instantly, without changing a global password or disrupting anyone else. EAP-TLS is the gold standard for enterprise security. The third tier is Multi-Tenant or IoT WiFi. Think of retail mall tenants, coworking space members, or smart building sensors that do not support 802.1X. For this, we deploy Cisco Identity PSK, or iPSK. Everyone connects to the same SSID, but the RADIUS server assigns a unique password and a unique VLAN to each tenant based on their MAC address. When a tenant's device connects, the WLC sends a MAC authentication request to the RADIUS server. The server returns the specific PSK for that tenant as a Cisco AV-Pair attribute, along with three standard IETF RADIUS attributes to dynamically assign the client to the correct VLAN. Those attributes are: Tunnel-Type, set to VLAN; Tunnel-Medium-Type, set to 802; and Tunnel-Private-Group-ID, set to the target VLAN ID. The WLC processes these attributes and places the device on the correct isolated network segment. iPSK delivers enterprise segmentation with consumer simplicity. Now let's discuss implementation recommendations and the pitfalls we see most frequently in production deployments. The most common point of failure in guest deployments is the walled garden ACL. If guests connect but the splash page does not appear, check your DNS configuration first. If your pre-authentication ACL blocks UDP port 53, the client cannot resolve domain names. The operating system will not trigger the captive portal mini-browser, and the guest will see a No Internet error. Always explicitly permit DNS traffic in your walled garden ACL. This is the single most common support issue we encounter. The second pitfall is in staff deployments. If you choose to deploy PEAP-MSCHAPv2 instead of EAP-TLS, because you do not yet have an MDM solution to distribute certificates, you must configure your client devices to explicitly validate the RADIUS server certificate. This means specifying the exact Certificate Authority to trust and the expected server name in the WiFi profile. If you leave this to the end user to configure manually, an attacker can spin up a rogue access point, present a fraudulent certificate, and capture corporate credentials. This is not a theoretical attack. It is a well-documented real-world threat. Enforce certificate validation via Group Policy for Windows devices and via MDM profiles for macOS and mobile devices. The third pitfall is in iPSK deployments. If a client connects but receives the wrong VLAN, or fails to connect entirely, the most likely cause is that the target VLAN ID specified in the Tunnel-Private-Group-ID attribute does not exist on the WLC. The VLAN must be created and active on the controller before the RADIUS server can steer clients into it. Use the debug radius command on the WLC to verify that the attributes are being received correctly from the RADIUS server. Now let's do a rapid-fire question and answer session on the questions we hear most often. Question one: Can I use MAC Authentication Bypass instead of iPSK for IoT devices? You can, but you should not. MAC addresses are broadcast in plaintext and are trivial to spoof. MAC Authentication Bypass provides device identification, not security. iPSK provides actual cryptographic security for headless devices. If the device supports any form of PSK, use iPSK. Question two: Does Purple support Cisco Catalyst 9800 IOS-XE controllers? Yes. Purple fully supports modern Catalyst 9800 IOS-XE controllers as well as legacy AireOS WLCs. The RADIUS and Change of Authorization integration is fully validated for both platforms. Question three: How do I handle RADIUS server redundancy? Always configure both a primary and secondary RADIUS server in your WLC AAA method lists. The WLC will automatically fail over to the secondary server if the primary does not respond within the configured timeout. Purple provides two RADIUS server IP addresses for exactly this purpose. Never deploy a single RADIUS server in a production environment. Question four: What RADIUS port numbers does Purple use? Purple uses UDP port 1812 for authentication and UDP port 1813 for accounting. These are the IANA-registered standard ports for RADIUS, as defined in RFC 2865 and RFC 2866. To summarise the key takeaways from today's briefing. Audit your current wireless architecture. If you are using shared passwords for staff, plan a migration to 802.1X. If you are broadcasting multiple SSIDs for different tenants, consolidate them using Cisco iPSK. If your guest WiFi is simply an open network with no data capture, integrate it with Purple to collect first-party data, drive marketing return on investment, and ensure compliance with GDPR and PCI DSS requirements. By combining Cisco's enterprise-grade infrastructure with Purple's cloud overlay, you deliver secure, segmented, and intelligent connectivity across your venue. Purple operates across more than 80,000 live venues and recorded 440 million logins in 2024. The platform is hardware-agnostic, ISO 27001 certified, and built for enterprise scale. Your next step is clear. Review the full step-by-step configuration guide on the Purple website, obtain your RADIUS server credentials from the Purple portal, and begin the integration with your Cisco WLC today. For detailed configuration guides and hardware-specific documentation, visit the Purple support portal at support dot purple dot ai. Thank you for listening to this Purple Technical Briefing. Until next time, stay secure.