Konfiguration der Captive Portal-Weiterleitung auf Enterprise-Netzwerk-Controllern

Welcome to the Purple Technical Briefing. I'm your host, and over the next ten minutes we're going straight into one of the most searched-for, least well-documented topics in enterprise WiFi: configuring captive portal redirection on network controllers. If you've ever searched for "configurar controlador portal cautivo" and come back empty-handed, this is the briefing you needed. We're covering the full picture - the technical architecture, the controller-by-controller configuration steps, the compliance requirements, and the real-world pitfalls that trip up even experienced network teams. Let's get into it. A captive portal is the mechanism that intercepts a guest device's first HTTP or HTTPS request after connecting to your WiFi network, and redirects it to a branded splash page before granting internet access. That splash page might ask for a social login, a form submission, a simple click-through acceptance of terms, or a RADIUS-backed credential check. The redirection itself is handled at the controller level - not the access point, not the firewall. The controller intercepts the unauthenticated client's traffic, applies a pre-authentication access control list - what we call a walled garden - and pushes the client's browser to your portal URL. Why does this matter commercially? Three reasons. First, compliance. Under GDPR, you are required to obtain explicit, informed consent before collecting personal data from visitors. A properly configured captive portal is your consent mechanism. Without it, you are collecting data without a lawful basis - and that is a regulatory exposure. Second, security. An open SSID with no authentication is a liability. Captive portal redirection, combined with VLAN segmentation and a RADIUS server, gives you per-session accountability. You know who connected, when, and from which device. Third, business intelligence. Every authenticated session is a first-party data point. Purple processes 440 million logins annually across 80,000 venues. That data - dwell time, visit frequency, demographic signals - is only available if your captive portal is correctly configured to capture and transmit it. Now let me walk you through the redirect flow, step by step. Step one: a guest device associates with your guest SSID. The controller assigns it an IP address via DHCP but places it in a restricted pre-authentication state. All traffic is blocked except for DNS and the walled garden domains you have explicitly permitted. Step two: the guest opens a browser. Their HTTP request hits the controller. The controller intercepts it and issues a 302 redirect to your portal URL. This is the core redirect mechanism. Step three: the guest's browser loads your splash page, hosted either on the controller itself or, more commonly in enterprise deployments, on an external cloud platform like Purple. Step four: the guest authenticates - via social login, form, or credentials. The portal sends an authorisation signal back to the controller, typically via a RADIUS Access-Accept message or a MAC authorisation bypass. Step five: the controller moves the client from the pre-authentication VLAN to the post-authentication VLAN, removes the redirect rule, and grants internet access. That five-step flow is consistent across all major controller platforms. What differs is how you configure each step on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, and the others. Let's go through the major platforms. Cisco Meraki. Meraki uses a custom splash page configured entirely through the Meraki Dashboard - there is no CLI. Navigate to Wireless, then Access Control, select your guest SSID, set the splash page to "Sign-on with my RADIUS server" or "Click-through", then enter your external portal URL in the Custom Splash URL field. The walled garden is configured in the Advanced Splash Settings section - you add the IP addresses of your portal server so the guest can reach the splash page before authentication. RADIUS server details go in the RADIUS section: authentication on port 1812, accounting on port 1813. HPE Aruba. On ArubaOS, you configure a captive portal profile under the AAA section, specifying the login URL, the server group pointing to your RADIUS server, and the redirect URL. You then apply that profile to your SSID via the virtual AP profile. The pre-authentication role - what Aruba calls the "logon" role - contains the ACL that permits DNS, DHCP, and access to your portal server's IP range. Post-authentication, the controller assigns the "authenticated" role, which permits full internet access. Ruckus SmartZone uses a Hotspot WLAN type for captive portal deployments. Under WLAN configuration, set the WLAN type to Hotspot, then configure the portal URL, the RADIUS server for authentication and accounting, and the walled garden entries. The Northbound Portal Interface handles the MAC authorisation flow between the portal and the controller. Juniper Mist uses a cloud-native approach. Under Network, then WLANs, create a guest WLAN and set the portal type to "External Captive Portal". Enter your portal URL and configure the RADIUS server details. Mist passes the client MAC, the AP MAC, and the SSID name as URL parameters to the portal. Ubiquiti UniFi. In the UniFi Network Controller, navigate to Settings, then WiFi, select your guest network, and under Advanced Options set the Guest Policy to enable the hotspot portal. Set the portal type to "External" and enter your portal URL. Configure the RADIUS server under Profiles, then RADIUS. The walled garden is the most commonly misconfigured element in captive portal deployments. Get this wrong and your guests will see a browser error instead of your splash page. The walled garden must permit, at minimum: your portal server's IP addresses or domain, your RADIUS server's IP addresses, DNS resolution on port 53, and DHCP on port 67 and 68. If your portal loads assets from a CDN - fonts, images, JavaScript - those CDN domains must also be in the walled garden. For Purple deployments, we provide the specific IP ranges and domains to whitelist during onboarding. The most common failure mode is a portal that loads the HTML frame but fails to render images or execute JavaScript because the CDN domains are missing from the walled garden. Two compliance standards dominate here: GDPR and PCI DSS. Under GDPR, your captive portal must present a clear, specific consent mechanism before collecting personal data. This means separate, unticked checkboxes for WiFi access and marketing consent. You cannot bundle them. The consent record must be stored and retrievable for audit purposes. Purple's platform handles this automatically, storing consent records against each authenticated session. Under PCI DSS, if your venue processes card payments, your guest WiFi network must be isolated from your payment card environment. This means a dedicated guest VLAN with firewall rules preventing any routing between the guest segment and your POS network. PCI DSS version 4.0, which became mandatory in March 2024, requires network segmentation testing at least every six months. Let me give you two concrete scenarios. Scenario one: a 350-room hotel running Cisco Meraki. The hotel wants to replace a basic click-through portal with a branded guest experience that captures email addresses for their loyalty programme. The configuration: create a dedicated guest SSID on a separate VLAN with internet access only. Configure the Meraki splash page to point to Purple's portal URL. Set up RADIUS authentication using Purple's RADIUS server details. Configure the walled garden with Purple's IP ranges. In the Purple dashboard, build a branded splash page with a form capturing name, email, and room number, with explicit GDPR consent checkboxes. Connect the Purple CRM connector to the hotel's marketing platform. Premier Inn implemented this model across their estate and saw measurable increases in direct booking rates from WiFi-acquired guests. Scenario two: a regional retail chain with 40 stores running HPE Aruba. The retailer needs a consistent guest WiFi experience across all sites, with footfall analytics to compare store performance. Deploy Aruba Central to manage all 40 sites from a single dashboard. Configure a guest WLAN template with external captive portal pointing to Purple. Apply the template across all sites using Aruba Central's group policy feature. In Purple, configure a single portal template that applies across all venues, with per-venue analytics dashboards. The walled garden and RADIUS configuration are defined once in the template and propagated automatically. Result: the IT team manages 40 sites from one console. The marketing team gets per-store footfall data, dwell time analysis, and repeat visit rates - all from a single Purple dashboard. Four pitfalls I see repeatedly. One: HTTPS interception failures. Modern browsers and mobile operating systems use HTTPS probes to detect captive portals. If your controller cannot intercept HTTPS traffic - which requires a valid certificate for the redirect domain - the probe fails silently and the guest sees no redirect. The fix: configure your controller's virtual interface with a trusted certificate, or use HTTP-only probes on your guest SSID. Two: DNS leakage. If your pre-authentication ACL permits unrestricted DNS, guests can use DNS tunnelling to bypass the captive portal entirely. Restrict DNS to your designated resolver only. Three: session timeout mismatches. If your controller session timeout is shorter than your portal's session token validity, guests get redirected back to the portal mid-session. Align these values - typically 24 hours for hospitality, eight hours for retail. Four: missing accounting. RADIUS accounting - the Accounting-Start and Accounting-Stop messages - is how your portal knows a session has ended. Without accounting configured, your portal's session records will be inaccurate and your analytics will be unreliable. Quick questions, quick answers. Can I use an external portal with any controller? Yes, provided the controller supports external captive portal redirect - which all the platforms we have discussed do. Do I need a RADIUS server to run a captive portal? Not always. Simple click-through portals can use MAC authorisation bypass without a full RADIUS server. But for credential-based or social login portals, RADIUS is the standard mechanism. Does captive portal work with WPA3? Yes. WPA3 handles the wireless encryption layer. Captive portal handles the authentication layer. They operate independently and are fully compatible. How does Purple integrate with my existing controller? Purple acts as the external portal server. You point your controller's splash URL to Purple's portal endpoint, configure the walled garden with Purple's IP ranges, and set up RADIUS using Purple's server details. The integration is the same process regardless of whether you're on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi. To summarise. Captive portal redirection is configured at the controller level, not the access point. The core components are: the splash URL pointing to your portal, the walled garden permitting access to your portal server, RADIUS for authentication and accounting, and VLAN segmentation for network isolation. The configuration steps differ by vendor but the architecture is consistent. For compliance, your portal must implement GDPR-compliant consent capture and PCI DSS-compliant network segmentation. WPA3 is the current standard for wireless encryption and should be your baseline specification on any new deployment. Purple integrates natively with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. Across 80,000 venues and 440 million logins in 2024, the platform is hardware-agnostic by design - your controller choice does not constrain your ability to capture first-party guest data or run analytics. Your next step: review your current controller configuration against the walled garden and RADIUS accounting checklist in this guide. If you're deploying a new guest WiFi network, start with the vendor-specific configuration steps for your controller platform and connect Purple as your external portal. Thanks for listening. This has been the Purple Technical Briefing.