A Network Administrator’s Guide to Configuring RADIUS Authentication for Guest WiFi

A Network Administrator's Guide to Configuring RADIUS Authentication for Guest WiFi - Podcast Script [INTRO - approximately 1 minute] Hello and welcome. I'm going to walk you through everything you need to know about configuring RADIUS authentication for guest WiFi - from the underlying architecture through to the practical steps your team needs to take, and the pitfalls that catch most deployments out. This isn't a lecture. Think of it as a briefing from a senior consultant who has sat across the table from IT managers at hotels, retail chains, stadiums, and conference centres, and helped them get this right. We'll cover the technical fundamentals, real-world implementation patterns, and where Purple's cloud-native RADIUS platform fits into the picture. Let's get into it. [TECHNICAL DEEP-DIVE - approximately 5 minutes] So, what actually is RADIUS? RADIUS stands for Remote Authentication Dial-In User Service. It's a networking protocol - defined in RFC 2865 - that provides centralised authentication, authorisation, and accounting for network access. In plain terms: it's the system that decides whether a visitor's device is allowed onto your network, under what conditions, and for how long. It then logs the whole session. For guest WiFi specifically, RADIUS sits between your access points and your identity layer. A visitor connects to your SSID, their device sends an authentication request to the access point, the access point forwards that to a Network Access Server - or NAS - which then queries the RADIUS server. The RADIUS server validates the credentials, returns an Access-Accept or Access-Reject, and the session begins or is blocked. Accounting packets then track session duration, data consumed, and termination reason. The three core functions are often called AAA: Authentication, Authorisation, and Accounting. Authentication confirms identity. Authorisation defines what that identity can access - bandwidth limits, VLAN assignment, session duration. Accounting creates the audit trail. Now, for guest WiFi the authentication method matters enormously. In a corporate environment you'd typically use 802.1X with EAP-TLS - certificate-based, very secure. For guests, that's impractical. Guests don't have certificates on their personal devices. So the common pattern is a captive portal combined with RADIUS. The visitor lands on a splash page, enters their details or authenticates via social login, and the captive portal exchanges those credentials with the RADIUS server on their behalf. The RADIUS server then signals the access point to grant access. This is exactly the architecture Purple operates. Our cloud-native RADIUS service handles the authentication exchange, while the captive portal - which you brand and configure through the Purple platform - manages the visitor-facing experience. The access point simply needs to know the RADIUS server address, port, and shared secret. Purple provides all three. Let's talk ports and protocols. RADIUS authentication traffic runs on UDP port 1812. RADIUS accounting runs on UDP port 1813. You'll configure both on your access points. The shared secret is a pre-shared key between your access point and the RADIUS server - treat it like a password. Use a long, randomly generated string. Never reuse it across deployments. On the hardware side, Purple is hardware-agnostic. We work with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet, among others. The configuration steps vary by vendor, but the underlying RADIUS parameters are consistent: server IP or hostname, authentication port 1812, accounting port 1813, shared secret, and accounting interval. For Avaya access points, for instance, you configure the RADIUS attributes under the External RADIUS section, set the Called-Station-Id format to UC-hyphenated MAC format, enable accounting, and then configure the SSID with web page redirection pointing to Purple's captive portal URLs. Purple's support documentation covers the exact steps for Avaya at the link in the guide. For Pepwave MAX series devices, you can configure either through InControl2 - their cloud management platform - or directly through the local web interface. Either way, you're setting up an external captive portal, pointing authentication and accounting at Purple's RADIUS servers, and configuring the SSID with open security and the captive portal attached. Again, the exact steps are in Purple's support docs. One architecture decision worth flagging: primary and secondary RADIUS servers. Always configure both. Purple provides two RADIUS server addresses for redundancy. If the primary is unreachable, the access point fails over to the secondary automatically. Without a secondary, a RADIUS server blip means your guests can't connect. In a hotel with 300 rooms or a stadium with 40,000 fans, that's a serious incident. VLAN segmentation is the other critical piece. Your guest WiFi traffic should never touch your corporate or operational network. Assign guest sessions to a dedicated VLAN, route that VLAN to a separate internet uplink or at minimum through a firewall with strict egress rules. This is a PCI DSS requirement if you process card payments anywhere on the same physical infrastructure, and it's simply good practice regardless. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - approximately 2 minutes] Let me give you the three things that most commonly go wrong. First: shared secret mismatches. The shared secret on the access point must exactly match what's registered in the RADIUS server. Case-sensitive, character-for-character. A single wrong character produces an Access-Reject with no useful error message. Always copy-paste from your Purple dashboard rather than typing manually. Second: whitelist gaps. Before the visitor authenticates, their device needs to reach the captive portal. That means certain domains must be whitelisted on the access point - Purple's portal URLs, authentication endpoints, and any social login providers you're using. If the whitelist is incomplete, visitors see a blank page or a timeout. Purple maintains a current list of required domains in the support documentation - use that list, don't guess. Third: accounting interval. This controls how frequently the access point sends interim accounting updates to the RADIUS server. Set it too long and you lose session granularity. Set it too short and you generate unnecessary traffic. For most deployments, 240 to 300 seconds is the right range. Avaya's recommended interval is 300 seconds; Pepwave's is 180 to 240 seconds. Follow the vendor-specific guidance. On the compliance side: GDPR requires that you have a lawful basis for collecting visitor data. A well-configured captive portal with explicit consent checkboxes satisfies this. Purple's platform is GDPR compliant and ISO 27001 certified. Every login through Purple is a conscious-choice opt-in - the visitor actively agrees to your terms before connecting. That audit trail is your compliance evidence. [RAPID-FIRE Q&A - approximately 1 minute] Quick questions I get asked regularly. "Do I need to replace my existing hardware?" No. Purple layers on top of your existing infrastructure. No rip and replace required. "Can I use RADIUS for staff WiFi on the same platform?" Yes. Purple supports separate SSIDs for guest and staff, with different authentication policies on each. "What if my venue has multiple sites?" Purple manages multi-site deployments from a single pane of glass. You configure once and replicate across sites. "Is cloud RADIUS less secure than on-premise?" No. Purple's cloud RADIUS operates with 99.999% uptime, ISO 27001 certification, and end-to-end encryption. The attack surface is smaller than a self-managed server because patching and hardening are handled centrally. "How long does a full deployment take?" For a single venue with supported hardware, a network administrator can complete the RADIUS configuration in under two hours. Purple's onboarding team is available to assist. [SUMMARY AND NEXT STEPS - approximately 1 minute] To summarise. RADIUS authentication for guest WiFi gives you centralised access control, a full accounting trail, and the compliance foundation you need for GDPR and PCI DSS. The architecture is straightforward: access point to NAS to RADIUS server to Purple's cloud platform. The three things to get right are the shared secret, the domain whitelist, and the accounting interval. Purple operates cloud-native RADIUS across more than 80,000 venues worldwide, handling 440 million logins in 2024. The platform is hardware-agnostic, ISO 27001 certified, and GDPR compliant. Your next steps: check whether your hardware is on Purple's supported list, pull the RADIUS server credentials from your Purple dashboard, and follow the vendor-specific configuration guide in Purple's support centre. If you need a hand, Purple's technical team can walk you through it. Thanks for listening. The full written guide with diagrams, worked examples, and configuration references is linked below.