OpenWrt and guest WiFi: captive portal setup with Purple

[0:00 - 1:00] Introduction & Context Welcome to the Purple Technical Briefing. I'm your host, and in the next ten minutes, we are going to dissect the OpenWrt custom firmware integration with Purple WiFi. If you are an IT manager, a network architect, or a CTO deploying custom firmware across hospitality, retail, or public-sector environments, this briefing is for you. We will cut through the academic theory and give you the exact playbook for configuring CoovaChilli, securing staff networks with 802.1X, and segmenting multi-tenant environments using Private Pre-Shared Keys. Why does this matter? Because deploying custom firmware like OpenWrt gives you incredible flexibility and hardware independence. But without a structured, identity-driven access control layer, that flexibility becomes a security liability. You need to capture first-party data securely, enforce GDPR compliance, and segment your traffic reliably. Let us get into the technical deep-dive. [1:00 - 6:00] Technical Deep-Dive The core of the OpenWrt integration relies on CoovaChilli. CoovaChilli is the open-source access controller that intercepts unauthenticated client traffic and redirects it to the Purple captive portal. When a guest connects to your open SSID, CoovaChilli acts as the gatekeeper. It assigns an IP address via its own internal DHCP server, running on the tun0 interface, and blocks all traffic except for what you explicitly allow in the walled garden. When the guest attempts to browse, CoovaChilli intercepts the HTTP request and issues a redirect to the Purple splash page. This is where the walled garden configuration is critical. In your chilli.conf file, you must define the HS_UAMDOMAINS parameter. This is a comma-separated list of domains that guests can reach before they authenticate. You must include splash.purple.ai, api.purple.ai, and the various CDN domains we use to serve the portal assets. If you miss a domain, the portal will fail to load, or the social login buttons will break. It is that simple. Once the guest authenticates on the Purple portal, Purple's cloud RADIUS server sends an Access-Accept message back to CoovaChilli on UDP port 1812. CoovaChilli then authorises the MAC address, opens the firewall rules for that session, and begins sending accounting data on UDP port 1813. Accounting is not optional. It is how Purple tracks session duration and data usage for your analytics dashboard. Now, let us talk about staff WiFi. You do not use CoovaChilli for staff. For staff networks, you use hostapd with WPA2-Enterprise or WPA3-Enterprise. This is standard 802.1X authentication. The access point acts as the authenticator, forwarding EAP messages to your RADIUS server. For corporate devices, you should be deploying EAP-TLS, which uses digital certificates instead of passwords. This completely eliminates credential theft. You configure hostapd.conf to point to your RADIUS server, and the RADIUS server dictates the VLAN assignment for that specific user. This brings us to one of the most powerful features in modern OpenWrt deployments: Private Pre-Shared Keys, or PPSK. In a multi-tenant environment - say, a build-to-rent property or a coworking space - you do not want fifty different SSIDs broadcasting. It ruins your airtime efficiency. Instead, you broadcast one SSID. When a device connects, hostapd sends the MAC address to the RADIUS server. The RADIUS server responds with a specific passphrase and a specific VLAN ID for that device, using the Tunnel-Password attribute. This means the retail staff member in shop A gets dropped onto VLAN 10, while the event attendee in the main hall gets dropped onto VLAN 30, all connecting to the exact same SSID. It is elegant, it scales, and it enforces least-privilege access at the edge. [6:00 - 8:00] Implementation Recommendations & Pitfalls Let us discuss implementation. When deploying OpenWrt with Purple, your first step is always retrieving your RADIUS credentials from the Purple portal. You need the primary and secondary RADIUS IP addresses, the shared secret, and the portal URL. In your OpenWrt configuration, you will define your guest network interface - typically eth1 or wlan0 - and bind CoovaChilli to it. Ensure that the HS_RADSECRET in your chilli.conf matches exactly what is in the Purple portal. A single character mismatch will cause silent authentication failures. The biggest pitfall we see is DNS resolution pre-authentication. CoovaChilli intercepts DNS requests. If your upstream firewall blocks the OpenWrt router from resolving external DNS, the captive portal redirect will fail. Ensure your OpenWrt router has unfettered DNS access to public resolvers like Google or OpenDNS. Another common issue is the captive portal detection mechanisms built into iOS and Android. Apple devices reach out to captive.apple.com to check for internet connectivity. If you whitelist captive.apple.com in your walled garden, the device thinks it has internet access and will not pop up the captive network assistant. If you want the automatic pop-up, keep Apple's domains out of the walled garden. [8:00 - 9:00] Rapid-Fire Q&A Let us do a rapid-fire Q and A. Question one: Can I run CoovaChilli and hostapd 802.1X on the same OpenWrt access point? Yes. You bind CoovaChilli to your guest SSID interface, and you configure hostapd with 802.1X on your staff SSID interface. They operate independently. Question two: Does Purple support dynamic VLAN assignment with OpenWrt? Yes. Purple's RADIUS servers can return standard RADIUS attributes, including Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private-Group-ID, instructing OpenWrt to drop the authenticated user onto a specific VLAN. Question three: What happens if the OpenWrt router loses connection to the Purple RADIUS server? CoovaChilli will fail to authenticate new sessions. Existing authorised sessions will remain active until their session timeout expires. Always configure the secondary Purple RADIUS server to ensure high availability. [9:00 - 10:00] Summary & Next Steps To summarise: OpenWrt provides a robust, hardware-agnostic platform for enterprise WiFi. By integrating CoovaChilli for guest access and hostapd for secure staff and multi-tenant PPSK, you build an Identity-Based Network. Purple abstracts the complexity of the RADIUS infrastructure, providing a cloud-managed portal that captures first-party data and ensures compliance. Your next step is to audit your current custom firmware deployments. Ensure your walled gardens are fully populated, verify your RADIUS accounting intervals, and begin planning your migration from shared PSKs to dynamic PPSK segmentation. Thank you for listening to the Purple Technical Briefing. To learn more about how Purple can secure and monetise your guest WiFi, visit purple.ai. Until next time.