Alcatel-Lucent OmniAccess Stellar and guest WiFi: captive portal setup with Purple

Welcome to the Purple technical briefing. Today we are covering the Alcatel-Lucent Enterprise OmniAccess Stellar integration with Purple WiFi. This briefing is for IT managers, network architects, and venue operations directors who need to deploy secure, scalable, and intelligent wireless networks. Let us start with the context. You have a venue. Maybe a hotel, a retail chain, or a stadium. You have invested in ALE OmniAccess hardware. Now you need to extract business value from that infrastructure. You need to capture first-party data, segment your users securely, and provide a seamless onboarding experience. That is where the Purple cloud overlay comes in. Purple operates across more than 80,000 live venues worldwide and processed over 440 million logins in 2024. It is hardware-agnostic, which means it sits on top of your existing ALE infrastructure without requiring any hardware replacement. The entire authentication and data-capture logic lives in the Purple cloud. The core of this integration relies on RADIUS. When a guest walks into your venue and connects to the open Guest WiFi SSID, the ALE AP intercepts their web traffic. Instead of letting them straight onto the internet, it redirects their browser to a Purple-hosted captive portal. This is your splash page. It is where you present your brand, collect email addresses, or offer social logins via Facebook, LinkedIn, or Google. Once the user submits their details, the Purple cloud RADIUS server authenticates them and sends an Access-Accept message back to the ALE AP. The AP then drops the firewall rules and grants internet access. The entire flow takes under three seconds. Now, let us get into the technical deep-dive. How do we actually configure this? First, you need to configure the RADIUS server settings in your OmniVista or Stellar management interface. You will input the Purple RADIUS IP addresses, set the authentication port to 1812, and the accounting port to 1813. Crucially, ensure RADIUS Accounting is enabled with an interval of 300 seconds. This is what feeds session data back to Purple for analytics and compliance logging. Next is the Walled Garden. This trips up a lot of deployments. Before a user is authenticated, they have no internet access. But they need to reach the Purple portal to log in. You must whitelist the Purple domains in your pre-authentication access list. The core domains are region1.purpleportal.net, venuewifi.com, and cloudfront.net. If you are using Facebook or LinkedIn login, you must whitelist their domains too. If the Walled Garden is wrong, the captive portal will not load. Full stop. For the SSID configuration, create a new wireless network, set the security level to Open, and enable the External Captive Portal option. Point the redirect URL to your specific Purple splash page URL, which you will find in the Purple portal under your venue's hardware settings. Let us move to a more advanced scenario: Multi-Tenant WiFi. Imagine a coworking space or student accommodation. You have multiple tenants who need their own secure, isolated networks. You do not want to broadcast 20 different SSIDs. That destroys your RF performance and creates a poor user experience. The solution is PPSK - Private Pre-Shared Keys - combined with dynamic VLAN steering. You broadcast one secure SSID. But every tenant gets a unique passphrase. When Tenant A enters their passphrase, the ALE AP sends that request to the Purple RADIUS server. Purple recognises the passphrase, authenticates the user, and sends back an Access-Accept message. But here is the important part. That message includes specific RADIUS attributes. Attribute 64 for Tunnel-Type, set to 13 for VLAN. Attribute 65 for Tunnel-Medium-Type, set to 6 for Ethernet. And Attribute 81, the Tunnel-Private-Group-ID, which contains the actual VLAN ID. The ALE AP receives this and drops Tenant A directly onto VLAN 30. When Tenant B logs in with a different passphrase, they land on VLAN 40. One SSID, total Layer 2 isolation. This is Identity-Based Networking in practice. Let us look at a real-world example. A 200-room hotel deployed this architecture across their existing ALE OmniAccess Stellar APs. They needed to serve hotel guests, back-of-house staff, and a ground-floor restaurant as three completely separate network segments. Rather than deploying three SSIDs, they used PPSK with dynamic VLAN steering. The result was a single SSID, three isolated VLANs, and a significant reduction in management overhead compared to their previous multi-SSID approach. Now let us discuss implementation recommendations and pitfalls. First, maintain a hardware-agnostic design. Build your policies in Purple, not on the local controller. This allows you to scale or swap hardware vendors later without rebuilding your security policies from scratch. Second, watch out for firmware versions. Ensure your ALE APs are running firmware that explicitly supports dynamic VLAN assignment via RADIUS. Older Stellar firmware versions may not fully support the Tunnel-Private-Group-ID attribute. Check the ALE release notes before deploying. Third, DNS is your friend and your enemy. If your captive portal is not appearing, check your DHCP scope first. If the client is not receiving a valid DNS server, they cannot resolve the portal URL, and the whole process stops. This is the single most common support issue in captive portal deployments. Fourth, for secure Staff WiFi using 802.1X, use PEAP with MSCHAPv2 for most environments, or EAP-TLS for certificate-based deployments. The Purple RADIUS server supports both. Staff devices authenticate against Microsoft Entra ID or Okta, and the RADIUS server returns the appropriate VLAN assignment for the staff network segment. Let us do a rapid-fire question and answer session. Question: Can I use this integration for PCI DSS compliance in a retail environment? Answer: Yes. By using dynamic VLAN steering, you can ensure that point-of-sale devices are always placed on an isolated VLAN, completely separated from guest traffic. This satisfies the network segmentation requirements under PCI DSS 4.0. Question: Does Purple require a hardware appliance on-site? Answer: No. Purple is a cloud overlay. It communicates directly with your existing ALE hardware via standard RADIUS over the internet. There is nothing to rack and stack. Question: What happens if the Purple cloud is unreachable? Answer: You can configure a fallback policy on the ALE AP. For guest networks, you can allow open access as a fallback. For staff networks, configure a deny-all fallback to maintain security. Question: Can I capture analytics data from the integration? Answer: Yes. Every authenticated session generates a visitor profile in the Purple platform. You get dwell time, visit frequency, device type, and demographic data from the registration form. This feeds directly into your CRM via Purple's library of over 400 connectors. To summarise the key takeaways from today's briefing. One: The ALE OmniAccess integration with Purple uses standard RADIUS on ports 1812 and 1813. No proprietary protocols required. Two: The Walled Garden is critical. Get it wrong and the captive portal will not load. Whitelist the Purple domains before anything else. Three: PPSK with dynamic VLAN steering is the right architecture for multi-tenant environments. One SSID, unique passphrases, isolated VLANs per tenant. Four: RADIUS Attributes 64, 65, and 81 are the three you need for dynamic VLAN assignment. If any one of them is missing, the steering fails. Five: Purple is hardware-agnostic. Your policies live in the cloud, not on the controller. This gives you flexibility to scale across different hardware vendors. Your next step is to log into your Purple portal, navigate to your venue's hardware settings, and retrieve your specific RADIUS credentials and splash page URL. Then follow the configuration steps in this guide to connect your ALE OmniAccess infrastructure to the Purple cloud. Thank you for listening to this Purple technical briefing. For more information, visit purple.ai.