Allied Telesis TQ Series AP and guest WiFi: captive portal setup with Purple

You are a senior network consultant speaking to a client's IT director in a private briefing. Speak in British English with a confident, authoritative, conversational tone. Measured pace, clear diction. No filler words. Occasional natural pauses for emphasis: Welcome to this technical briefing on integrating Allied Telesis TQ-Series access points with Purple WiFi. I'm going to walk you through the full deployment picture, from guest captive portal redirection through to multi-tenant PPSK isolation. By the end of this, you'll have a clear implementation roadmap. [medium pause] Let's start with context. Allied Telesis produces the TQ-Series, including the TQ5403 and TQ6702 GEN2 Wi-Fi 6 access points. These are enterprise-grade APs running AlliedWare Plus firmware, and they're deployed widely across hospitality, retail, and public sector environments. Purple is a hardware-agnostic cloud overlay platform operating across 80,000 venues and handling 440 million logins in 2024. The integration between these two platforms is clean, standards-based, and production-ready. [medium pause] Now, the first thing most IT teams need to configure is guest captive portal redirection. The Allied Telesis AP supports three captive portal modes: click-through, RADIUS authentication, and external page redirect. For Purple integration, you'll use the External Page Redirect mode. Here's how that works in practice. You log into the AP's device GUI, navigate to Wireless, select the relevant VAP, go to Advanced Settings, then the Security tab. Set Captive Portal to External Page Redirect. In the External Page URL field, you enter the Purple splash page URL provided in your Purple dashboard. That's the URL your guests will hit when they first connect. [short pause] Now, the AP intercepts the first HTTP or HTTPS packet from each new client and redirects that traffic to your Purple splash page. The guest authenticates through Purple, and Purple's RADIUS server sends an Access-Accept back to the AP. The AP then grants network access. [medium pause] For the RADIUS configuration, Purple provides you with a RADIUS server IP address, a shared secret, and the authentication port, which is UDP 1812. Accounting runs on UDP 1813. You configure these under Network Services, then RADIUS in the AP GUI. The NAS identifier should be set to the AP's management IP or a descriptive hostname. Purple's RADIUS as a Service handles the authentication backend, so you don't need to run your own RADIUS infrastructure. [short pause] One thing to get right is the Walled Garden. Before a guest authenticates, the AP blocks all traffic except to whitelisted destinations. You need to add Purple's platform domains to the walled garden so the splash page loads correctly. At minimum, whitelist the Purple splash page domain, any CDN endpoints Purple uses for assets, and any social login providers you've enabled, such as Google or Facebook. You configure this in the same VAP Advanced Settings panel under Walled Garden. [medium pause] Let's move on to Staff WiFi using 802.1X. This is where you configure WPA Enterprise on a separate VAP. In the AP GUI, select WPA Enterprise from the Security dropdown, then point the RADIUS Authentication Group at your external RADIUS server, which in this case is Purple's SecurePass service or your own Microsoft Entra ID or Okta-backed RADIUS. Staff devices authenticate using EAP-PEAP with MSCHAPv2, or EAP-TLS with certificates for higher security environments. The AP acts as the 802.1X authenticator, forwarding credentials to the RADIUS server and enforcing the response. [short pause] For dynamic VLAN assignment on the staff network, you enable Dynamic VLAN in the VAP's Advanced Security settings. When the RADIUS server returns an Access-Accept, it includes three standard attributes: Tunnel-Type set to VLAN, Tunnel-Medium-Type set to IEEE 802, and Tunnel-Private-Group-Id set to the VLAN ID. The AP reads these attributes and places the authenticated device onto the correct VLAN automatically. This is the mechanism defined in RFC 3580 and it works consistently across Allied Telesis hardware. [medium pause] Now let's talk about the most interesting capability for multi-tenant deployments: Allied Telesis PPSK, or Private Pre-Shared Key. This is sometimes called iPSK on other platforms. The concept is straightforward. You have a single SSID, but each tenant or user group gets a unique passphrase. When a device connects, the AP sends that passphrase to the RADIUS server as the password field in a RADIUS Access-Request. The RADIUS server matches the passphrase to a user record, and returns an Access-Accept with a Tunnel-Private-Group-Id attribute specifying the VLAN for that tenant. [short pause] So in a mixed-use building, Tenant A in the retail unit connects with their passphrase and lands on VLAN 100. The restaurant on the ground floor uses a different passphrase and lands on VLAN 300. The building's guest WiFi uses a third passphrase and lands on VLAN 400 where Purple's captive portal is active. All of this runs on one SSID. No SSID proliferation. Clean, scalable, and easy to manage. [medium pause] On the Purple side, you configure the PPSK user records in the Purple dashboard or via the RADIUS as a Service interface. Each tenant gets a unique passphrase mapped to a VLAN ID. Purple's RADIUS server handles the matching and returns the correct Tunnel-Private-Group-Id. When you need to revoke a tenant's access, you delete or disable their PPSK record in Purple. The AP enforces the change at the next authentication attempt. [medium pause] Let me give you two real-world scenarios where this matters. First, a 250-room conference hotel. The hotel runs three networks: guest WiFi with Purple splash page and social login, staff WiFi on 802.1X tied to Active Directory via Microsoft Entra ID, and a conference delegate network for events. The Allied Telesis TQ6702 GEN2 APs handle all three on separate VAPs with separate VLANs. Purple manages the guest splash page, collects first-party data for the hotel's CRM, and provides analytics on peak usage periods. The hotel's IT team manages the staff network through Purple's SecurePass without maintaining a separate RADIUS server on-site. [short pause] Second scenario: a retail park with 12 independent tenants. The landlord wants to offer WiFi as a service to each tenant without giving them access to each other's traffic. They deploy Allied Telesis APs throughout the site with a single SSID. Each tenant receives a unique PPSK. Purple's RADIUS server maps each PPSK to a dedicated VLAN. The landlord can onboard a new tenant in under ten minutes by creating a new PPSK record in Purple and handing the passphrase to the tenant. No AP reconfiguration required. [medium pause] Now, a few pitfalls to avoid. The most common issue we see is misconfigured walled gardens. If you forget to whitelist a Purple CDN endpoint, the splash page will partially load or fail on certain devices. Test with a fresh device that has no cached DNS before going live. Second, RADIUS shared secret mismatches. The secret configured on the AP must exactly match the secret in Purple's RADIUS server configuration. A single character difference causes silent authentication failures. Use a password manager to generate and store the secret. Third, Dynamic VLAN not enabling. On Allied Telesis APs, Dynamic VLAN is disabled by default even when WPA Enterprise is active. You must explicitly enable it in the VAP Advanced Security settings. We see this missed regularly. Fourth, PPSK and MAC authentication conflict. If you have MAC authentication enabled on the same VAP as PPSK, the authentication order matters. Check the AP documentation for your firmware version to confirm which method takes precedence. [medium pause] Quick-fire questions I get from IT teams. Can I use Purple's RADIUS server for both guest Captive Portal and staff 802.1X on the same deployment? Yes. Purple's RADIUS as a Service supports both authentication flows. You configure separate RADIUS groups or policies in Purple for each use case. Do Allied Telesis APs support WPA3 with captive portal? The TQ6702 GEN2 running firmware 5.5.4-2.3 or later supports WPA3 CCMP cipher. However, captive portal with external redirect typically runs on an open or WPA2 Personal SSID. Staff 802.1X can use WPA3 Enterprise. What happens if the Purple RADIUS server is unreachable? The AP will deny new authentication attempts. Existing sessions continue until they time out. You should configure a secondary RADIUS server in the AP's RADIUS group for redundancy. Purple's platform maintains 99.999% uptime, but defence in depth is good practice. [medium pause] To summarise. Allied Telesis TQ-Series APs integrate with Purple through three primary mechanisms: external captive portal redirect for guest WiFi, WPA Enterprise with RADIUS for staff 802.1X, and PPSK with dynamic VLAN for multi-tenant isolation. The RADIUS attributes you need are Tunnel-Type VLAN, Tunnel-Medium-Type IEEE 802, and Tunnel-Private-Group-Id carrying the VLAN ID. Purple provides the RADIUS as a Service backend, the splash page platform, and the analytics layer. [short pause] Your next steps: pull the Purple RADIUS credentials from your dashboard, configure the external page redirect on your guest VAP, add the walled garden entries, enable Dynamic VLAN on your staff VAP, and run a test authentication for each network segment before going live. If you're deploying PPSK for multi-tenant, plan your VLAN numbering scheme before you start, because changing VLAN IDs after tenants are live requires coordination. [medium pause] That's the briefing. For the full step-by-step configuration reference, the Mermaid architecture diagram, and the RADIUS attribute table, see the written guide. Thank you for your time.