WatchGuard Wi-Fi Cloud AP and guest WiFi: captive portal setup with Purple

Welcome to the integration briefing. Today we are covering the WatchGuard Firebox and Access Point integration with Purple WiFi. This is a technical playbook for IT managers, network architects, and venue operations directors who need to deploy secure, scalable wireless infrastructure. We will be looking at Guest WiFi captive portals, Secure Staff WiFi using 802.1X, and Multi-Tenant segmentation using WatchGuard Private Pre-Shared Keys, or PPSK. Let's get straight into the context. When you are managing a complex venue, say a stadium, a large retail centre, or a multi-dwelling unit, you need precise control over who accesses the network and what they can do once connected. You also need to capture first-party data to drive marketing revenue. WatchGuard provides the unified security platform and the hardware. Purple provides the cloud overlay, the identity management, and the analytics. By integrating the two, you automate identity-based access control. You eliminate the need for separate guest and staff gateways, which reduces hardware expenditure and simplifies management. Purple currently serves over 80,000 live venues and has processed 440 million logins in 2024 alone, so the platform is built to handle the scale of any venue you are likely to be managing. Let's move into the technical deep-dive. The architecture relies on standard RADIUS protocols and HTTP redirection. We have three main access tiers. First, Guest WiFi. This is an open SSID. The WatchGuard AP intercepts HTTP requests and redirects the user to Purple's hosted splash page. Second, Staff WiFi. This is a secure WPA3-Enterprise SSID using 802.1X. Devices authenticate directly against Purple's RADIUS servers using EAP-TLS or PEAP. Third, Multi-Tenant WiFi. This uses WatchGuard PPSK. Multiple users connect to a single SSID, but each uses a unique password. The WatchGuard AP queries Purple's RADIUS server, which then dynamically assigns a VLAN based on that specific key. So, how do we configure the Guest WiFi captive portal? Step one is setting up the RADIUS server in WatchGuard Cloud or the Firebox Policy Manager. You point the primary RADIUS server to Purple's IP address for your region. Authentication is on port 1812, accounting on port 1813. You enter the shared secret provided by Purple, and crucially, you ensure the NAS ID matches the MAC address of the Firebox or AP. This tells Purple which venue the request is coming from. Step two is the captive portal redirection itself. In the SSID settings, you select Third-Party Hosted Captive Portal with RADIUS Authentication. You enter the Purple splash page URL, and you enter the portal shared secret. This is a specific secret generated in the Purple Analyze dashboard, and it is used to create an HMAC digest to validate authentication requests. The HMAC-SHA1 algorithm ensures that the authentication success message from Purple is genuine and has not been tampered with in transit. Step three, and this is where many deployments stumble, is the Walled Garden. If you do not configure this, the device cannot load the splash page. You must allow access to star dot mypurple dot com, api dot mypurple dot com, and cdn dot mypurple dot com before login. If you are using social logins like Microsoft Entra ID or Google Workspace, you need to add those identity provider domains too. Think of the Walled Garden as the pre-authentication lobby. Without it, the guest cannot even reach the front door. Now, let's look at Multi-Tenant segmentation with WatchGuard PPSK. If you manage a retail centre with 15 shops, broadcasting 15 different SSIDs is a poor approach. It causes co-channel interference, it clutters the airspace, and it creates a management overhead. PPSK solves this elegantly. You broadcast one SSID, say Centre-Retail. You enable Private Pre-Shared Key in the WatchGuard SSID settings, which requires firmware version 2.6 or higher on your WatchGuard Access Points. In Purple, you create unique keys, one per tenant. To isolate the traffic, you use Dynamic VLAN Assignment. In WatchGuard Cloud, you set the VLAN to Dynamic VLAN assigned by RADIUS. When a shop connects a device using their specific key, the AP sends an Access-Request to Purple's RADIUS server. Purple validates the key and sends back an Access-Accept packet with three vital IETF RADIUS attributes. Tunnel-Type, which is attribute 64, set to VLAN. Tunnel-Medium-Type, attribute 65, set to 802. And Tunnel-Private-Group-ID, attribute 81, set to the assigned VLAN ID, for example VLAN 100 for Retail Tenant A. The WatchGuard AP then places that device onto VLAN 100, completely isolated from the other tenants. This is Identity-Based Networking in practice. Let's discuss implementation recommendations and common pitfalls. First, session timeouts. Configure strict session timeouts in both Purple and WatchGuard to force re-authentication. This keeps your analytics accurate and ensures stale sessions do not consume bandwidth. Set your RADIUS Interim-Update intervals to 10 minutes. Second, firmware. You must ensure your WatchGuard Access Points are running firmware version 2.6 or higher to support PPSK. Earlier firmware versions do not support this feature. Third, MAC randomisation. Modern devices randomise their MAC addresses by default. For your secure Staff WiFi network, educate your staff to disable this feature for that specific SSID to ensure stable 802.1X authentication. MAC randomisation can cause authentication failures and inconsistent analytics data. What happens when things go wrong? If the captive portal fails to load, check the Walled Garden first. If the device cannot resolve DNS or reach the Purple servers, it will show a timeout error rather than the splash page. If VLAN steering fails and the client receives an IP from the wrong VLAN, check the RADIUS logs in the Purple portal. Ensure the Tunnel-Private-Group-ID attribute is formatted correctly as a string and matches a VLAN that actually exists on the switch port connected to the AP. If you see HMAC digest errors in the WatchGuard logs, your Captive Portal Shared Secret does not match between WatchGuard and Purple. It must be identical in both systems, character for character. Time for a rapid-fire Q&A. Question: Can I use PPSK and the Captive Portal on the same SSID? Answer: No. WatchGuard does not support running Dynamic VLANs via PPSK and a Captive Portal on the same SSID simultaneously. You need one SSID for the portal and a separate SSID for PPSK. Plan your SSID architecture accordingly. Question: What happens if the RADIUS server does not return a VLAN ID for a PPSK user? Answer: In WatchGuard Cloud, you configure an Unassigned Clients fallback option. You can drop them onto an untagged VLAN or a specific isolated quarantine VLAN to ensure they do not gain access to the corporate network. Always configure this fallback to avoid accidental access. To summarise, integrating WatchGuard Firebox with Purple gives you a unified platform for security, identity, and analytics across Guest, Staff, and Multi-Tenant networks. You use external captive portal redirection for guests, 802.1X for staff, and PPSK with dynamic VLANs for multi-tenant environments. The ROI is clear. You reduce hardware costs by consolidating gateways, you simplify management through a single cloud platform, and you drive revenue by capturing first-party data through the Purple captive portal. Your next steps are to review your current SSID architecture, ensure your WatchGuard firmware is at version 2.6 or higher, and begin configuring your RADIUS settings in the Purple portal. Thank you for listening.