View podcast transcript
CAPTIVE PORTAL FOR ARUBA: INTEGRATING PURPLE FOR ENTERPRISE GUEST WIFI
A Purple Technical Briefing — Approximately 10 Minutes
[INTRODUCTION & CONTEXT — approx. 1 minute]
Welcome to the Purple Technical Briefing series. I'm your host, and today we're covering something that comes up in almost every enterprise wireless deployment conversation we have: how to configure a captive portal on Aruba infrastructure, and specifically, how to connect that portal to Purple's guest WiFi intelligence platform.
If you're running Aruba Instant APs, or you're managing a fleet of access points through Aruba Central, this episode is for you. We're going to move quickly — this is a practitioner briefing, not a lecture — so I'll assume you know your way around a WLAN configuration screen and you understand the basics of RADIUS authentication.
The core problem we're solving is this: Aruba's built-in guest portal is functional, but it's limited. It doesn't give you the marketing data capture, GDPR-compliant consent flows, or the real-time analytics that enterprise venues need. Replacing it with Purple's external captive portal is the right architectural decision, and today I'll walk you through exactly how to do it.
[TECHNICAL DEEP-DIVE — approx. 5 minutes]
Let's start with the architecture. When a guest connects to your Aruba SSID and opens a browser, the AP intercepts that HTTP request on TCP port 80 and redirects it to the external portal URL — in this case, Purple's cloud-hosted splash page. The guest authenticates through Purple's portal, which then sends a RADIUS Access-Request to Purple's RADIUS servers on UDP port 1812. On success, the RADIUS server returns an Access-Accept message, and the AP grants the client full internet access. Accounting records are sent on UDP port 1813 throughout the session.
That's the fundamental flow. Now let's get into the configuration.
There are two management planes you might be working with: Aruba Instant, which is the on-premises virtual controller model running ArubaOS 8.x, and Aruba Central, which is HPE's cloud management platform. The configuration steps are similar in concept but differ in where you find the settings.
Starting with Aruba Instant on ArubaOS 8. First, you'll configure your RADIUS server. Navigate to Security, then Authentication Server, and click New. You'll need four pieces of information from Purple's platform: the primary server IP address, the authentication port — typically 1812 — the accounting port — typically 1813 — and the shared secret. Purple provides these in your venue configuration dashboard. Add a secondary server for resilience; Purple operates a multi-region RADIUS infrastructure, so you'll have a geographically appropriate backup.
Next, create the External Captive Portal profile. Go to Security, then Captive Portal, click New, and set the Type to External. Enter the splash page URL from your Purple venue configuration — this will be a Purple-hosted HTTPS endpoint. Set the port to 443, enable Use HTTPS, and critically, set the WISPr field to Enabled. WISPr — that's Wireless Internet Service Provider roaming — is the protocol that allows devices to auto-detect the captive portal and present it correctly, particularly on iOS and Android devices that use background captive portal detection. Without WISPr enabled, some devices will fail to trigger the portal automatically.
Now, the Guest SSID. Create a new WLAN, set Primary Usage to Guest, and in the Security tab, set Splash Page Type to External — RADIUS Server. Assign the captive portal profile and RADIUS server you just created. Set the Reauth Interval to something sensible — 1440 minutes, which is 24 hours, is a common choice for hospitality environments. Enable MAC authentication if you want returning guests to bypass the portal on subsequent visits within that window.
For Aruba Central on AOS-8, the flow is essentially the same but accessed through the WLAN wizard under Devices, Config, WLANs. Set Security Level to Visitors, Type to External Captive Portal, and create a new captive portal profile with the Purple splash URL. Add your primary and secondary RADIUS servers, enable accounting, and set an accounting interval of five minutes. This interval is important — it ensures Purple's analytics platform receives regular session updates for accurate dwell time and engagement reporting.
On AOS-10, which is the cloud-first architecture, there's one important difference: the walled garden is no longer configured in the WLAN Security tab. Instead, you configure it through Access Rules. You create a pre-authentication role — call it Guest Logon — and add allow rules for each domain in the walled garden whitelist. Then you assign that role as the Pre-Authentication Role on the SSID.
Speaking of the walled garden — this is where most deployments go wrong. The walled garden is the list of domains that unauthenticated guests can reach before they've completed the portal flow. Without these entries, the portal itself won't load, because the guest's device can't reach the Purple CDN to download the splash page assets.
The mandatory Purple entries are: star dot purple dot ai, star dot cloudfront dot net, and star dot venuewifi dot com. If you're using social login — Google, Facebook, Apple, Microsoft — you'll need to add the relevant OAuth domains for each provider. Google requires star dot google dot com, star dot googleapis dot com, and star dot gstatic dot com. Facebook requires star dot facebook dot com, star dot fbcdn dot net, and connect dot facebook dot net. Apple Sign-In needs star dot apple dot com and appleid dot apple dot com. Microsoft Entra ID requires star dot microsoft dot com and star dot microsoftonline dot com.
One thing worth calling out: on Aruba, you can enable Automatic URL Whitelisting in the captive portal profile. This feature dynamically whitelists URLs that the portal page references. It's useful as a fallback, but I'd recommend explicitly configuring the walled garden rather than relying on automatic whitelisting in production — it's more predictable and easier to audit.
Let's talk about RADIUS parameters specifically. The key attributes Purple uses are: NAS-IP-Address, which identifies your AP or controller; Called-Station-Id, which carries the BSSID and SSID in the format MAC-address:SSID-name — Purple uses this to map sessions to specific venues and access points; and Calling-Station-Id, which is the client MAC address. On the accounting side, Acct-Session-Id provides the unique session identifier, and Acct-Status-Type carries Start, Interim-Update, and Stop events. Make sure your Aruba configuration is sending all three accounting event types — some deployments only send Start and Stop, which means Purple's analytics miss the interim session data needed for accurate dwell time calculations.
[IMPLEMENTATION RECOMMENDATIONS & PITFALLS — approx. 2 minutes]
Let me give you the practical recommendations I'd give any client deploying this.
First: always test with a dedicated test device before going live. Connect to the guest SSID, open a browser to an HTTP URL — not HTTPS — and verify the redirect fires. If you go straight to HTTPS, the redirect won't work because the AP can't intercept encrypted traffic. This is the number one support call we see.
Second: firewall rules. Your AP management VLAN or controller needs outbound UDP access to Purple's RADIUS server IPs on ports 1812 and 1813. If you have a stateful firewall between your APs and the internet, make sure it allows these UDP flows. RADIUS is connectionless, so some firewalls need explicit rules rather than relying on stateful inspection.
Third: certificate trust. When you configure the splash page URL as HTTPS, the AP needs to trust the certificate presented by Purple's portal server. On Aruba Central, you may need to import a trusted CA certificate into the global settings before the portal redirect works correctly over HTTPS. Purple uses certificates from a widely trusted CA, but it's worth verifying this in your environment.
Fourth: VLAN segmentation. Your guest SSID should be on a dedicated VLAN that is isolated from your corporate network. This is both a security requirement — PCI DSS 3.2.1 requires network segmentation for cardholder data environments — and a practical necessity for captive portal functionality. The guest VLAN should have internet access but no route to internal resources.
Fifth: the WISPr setting. I mentioned this earlier but it bears repeating. Enable WISPr. Without it, iOS devices in particular will not automatically detect the captive portal, and guests will see a confusing experience where they appear to be connected but have no internet access.
[RAPID-FIRE Q&A — approx. 1 minute]
Let me run through the questions I get most often.
Can I use Aruba Instant On — the small-business product — with Purple? Yes, with some limitations. Instant On supports external captive portals, but the configuration interface is more limited than full Aruba Central. Purple has a dedicated Instant On integration guide.
Does Purple support RadSec for encrypted RADIUS? Yes. Purple supports RADIUS over TLS — RadSec — for deployments where RADIUS traffic traverses untrusted networks. This is increasingly relevant for cloud-managed deployments where the RADIUS exchange crosses the public internet.
What happens if the Purple portal is unreachable? You can configure the Captive Portal Failure setting to either Deny Internet — which is the secure default — or Allow Internet, which provides a fallback open access mode. For most enterprise venues, Deny Internet is the right choice.
Can I run multiple SSIDs with different Purple venues on the same Aruba infrastructure? Absolutely. Each SSID gets its own captive portal profile pointing to a different Purple venue URL. The Called-Station-Id RADIUS attribute carries the SSID name, which Purple uses to route the session to the correct venue configuration.
[SUMMARY & NEXT STEPS — approx. 1 minute]
Let me bring this together. Deploying Purple as an external captive portal on Aruba infrastructure is a well-trodden integration path. The key steps are: configure your RADIUS servers with Purple's credentials, create an external captive portal profile pointing to your Purple splash URL with WISPr enabled, build your guest SSID with the External RADIUS Server splash type, and configure your walled garden with the Purple core domains plus any social login provider domains you're enabling.
The AOS-10 difference to remember is that walled garden configuration moves to Access Rules rather than the WLAN Security tab.
From a business perspective, replacing Aruba's basic local portal with Purple gives you GDPR-compliant data capture, real-time location analytics, demographic reporting, and marketing automation — all from the same WiFi infrastructure you already own.
For your next steps: pull your Purple venue RADIUS credentials from the Purple dashboard, run through the configuration checklist in the accompanying written guide, and test with a dedicated device before rolling out to production. If you're deploying across multiple sites, Purple's multi-site management console lets you manage captive portal configurations, branding, and analytics across your entire estate from a single interface.
Thanks for listening. The full written guide, configuration tables, and walled garden reference lists are available at purple dot ai. Until next time.
[END OF SCRIPT]