SonicWall and guest WiFi: captive portal setup with Purple

SONICWALL TZ AND SONICWAVE INTEGRATION WITH PURPLE WIFI Purple WiFi Intelligence Platform - Technical Briefing Series Duration: Approximately 10 minutes Voice: UK English, senior consultant tone - confident, conversational, authoritative --- SEGMENT 1: INTRODUCTION AND CONTEXT (approximately 1 minute) Welcome to the Purple Technical Briefing Series. Today we are covering one of the more technically involved integrations in the enterprise WiFi space: SonicWall TZ firewalls and SonicWave access points, deployed alongside Purple for guest authentication, staff access control, and multi-tenant network isolation. If you are an IT security engineer or an MSP managing venues - hotels, retail chains, conference centres, or mixed-use developments - this briefing is for you. We are going to move quickly through the architecture, the configuration steps, and the places where deployments go wrong. SonicWall is a strong choice in the SMB and mid-market space. The TZ series firewalls are widely deployed, and SonicWave APs integrate natively through SonicOS and the Wireless Network Manager. When you add Purple on top, you get a cloud-managed guest WiFi layer with branded splash pages, RADIUS-based authentication, and first-party data capture - all without replacing your existing SonicWall infrastructure. Let us get into the architecture. --- SEGMENT 2: TECHNICAL DEEP-DIVE (approximately 5 minutes) There are four distinct use cases to cover here, and each one has a different configuration path. Guest WiFi with captive portal redirection. Walled Garden exceptions. Secure Staff WiFi using 802.1X. And multi-tenant isolation using SonicWall Private Pre-Shared Keys - PPSK - with dynamic VLAN steering. Let us start with Guest WiFi and the SonicWall captive portal. SonicOS uses a mechanism called Lightweight Hotspot Messaging - LHM - to handle external captive portal redirects. When a guest connects to your guest SSID and opens a browser, the SonicWall intercepts that HTTP request and redirects it to Purple's splash page URL. The guest authenticates on Purple's platform - via social login, email, or a click-through - and Purple sends an LHM authorisation back to the SonicWall on TCP port 4043. The SonicWall then opens internet access for that device's MAC address. The configuration in SonicOS 7.x works like this. First, navigate to Object, then Match Objects, then Zones. Edit the zone assigned to your guest WiFi - typically a WLAN or custom zone. Under Guest Services, enable both "Enable Guest Services" and "External Guest Authentication." Then go to Configure, Guest Services, General. Set the Client Redirect Protocol to HTTP. Enter Purple's portal hostname as the web server address - that is portal.purple.ai. Set the redirect path to your venue's specific splash page URL, which Purple provides in the venue dashboard. The port is 4043. On the Auth Pages tab, set the login URL to Purple's external portal URL. Set the logout URL if you want to handle session termination. On the Advanced tab, enable "Allow unauthenticated users to access HTTPS sites" only if you need to support HTTPS-first devices - but be aware this weakens the redirect enforcement. Once saved, SonicOS automatically creates a NAT policy and a WAN-to-WAN access rule permitting TCP 4043. Do not delete these auto-generated rules. They are what allows the LHM handshake to complete. Now, Walled Garden configuration. Before a guest authenticates, their device needs to reach certain domains to make the splash page work. Purple's platform depends on its own CDN and API endpoints. The OS captive portal detection probes - captive.apple.com for iOS devices, connectivitycheck.gstatic.com for Android, and msftconnecttest.com for Windows - must all be whitelisted. If you are offering social login, add accounts.google.com, oauth2.googleapis.com, apis.google.com, and gstatic.com for Google. Add www.facebook.com, graph.facebook.com, connect.facebook.net, and the fbcdn.net CDN domain if you are offering Facebook login. In SonicOS, add these as FQDN address objects under Object, Match Objects, Addresses. Then create access rules in the guest zone that permit unauthenticated devices to reach these FQDNs. Use dynamic DNS resolution - SonicOS resolves FQDN objects at regular intervals - rather than static IP entries, which will drift as CDN IP ranges change. Moving on to Secure Staff WiFi with 802.1X. This is where SonicWave APs and Purple's RADIUS server work together. The SonicWave AP acts as the authenticator in the 802.1X exchange. The supplicant is the staff device. Purple's RADIUS server is the authentication server. The EAP method you choose depends on your identity provider. If you are using Microsoft Entra ID or Okta, PEAP-MSCHAPv2 is the most common choice because it works with username and password credentials. If you have deployed device certificates - which is the recommended approach for managed devices - use EAP-TLS. In the Wireless Network Manager, navigate to Policies, Policy Hierarchy, select your AP policy, and click the 802.1X tab. Enter Purple's RADIUS server IP address - available in your Purple venue dashboard under the RADIUS settings section. The shared secret is generated by Purple and must match exactly on both sides. Set the authentication port to 1812 and the accounting port to 1813. For EAP settings, select the method that matches your identity provider configuration. On the Purple side, create a RADIUS policy for staff authentication. Map the staff SSID to a specific VLAN - for example, VLAN 200 for staff. Purple's RADIUS server returns the VLAN assignment using three standard attributes: Tunnel-Type set to VLAN, Tunnel-Medium-Type set to 802, and Tunnel-Private-Group-ID set to the VLAN ID as a string - so "200" for VLAN 200. The SonicWall firewall and SonicWave AP honour these attributes and place the authenticated staff device into the correct VLAN automatically. Now, the most architecturally interesting use case: PPSK and multi-tenant isolation. Private Pre-Shared Keys allow you to run a single SSID and assign each tenant, resident, or user group a unique passphrase. When a device connects using a specific PPSK, the SonicWave AP sends that key to Purple's RADIUS server for validation. Purple looks up the key, identifies the associated tenant or user group, and returns the appropriate VLAN assignment via the Tunnel-Private-Group-ID attribute. The SonicWall then steers that device into the correct VLAN - completely isolated from other tenants on the same SSID. This is Identity-Based Networking in practice. You are not managing SSIDs per tenant. You are managing identities per tenant. In a mixed-use development with ten retail units, one SSID broadcasts across the entire building. Each tenant gets their own PPSK. Each PPSK maps to a dedicated VLAN and subnet. Tenant A's devices never see Tenant B's traffic, even though they are sharing the same physical access points. The PPSK configuration in SonicOS requires RADIUS-based PPSK mode on the SSID. In the Wireless Network Manager, edit the SSID, set the security mode to WPA2-Enterprise with PPSK, and point the RADIUS server at Purple. Purple authorises the PPSK-to-VLAN mapping table centrally. When you add a new tenant, you create a new PPSK in Purple, assign it a VLAN, and the change propagates to all SonicWave APs in that venue without touching the firewall configuration. --- SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approximately 2 minutes) Let me give you the three things that most commonly go wrong in SonicWall and Purple deployments. First: the LHM port. TCP 4043 must be open from the WAN to the SonicWall's WAN interface. If your ISP or upstream firewall blocks this port, the LHM authorisation handshake never completes, and guests get stuck on the splash page after authenticating. They see a successful login on Purple's side, but the SonicWall never receives the authorisation signal. Test this with a telnet or curl check to port 4043 from an external IP before go-live. Second: FQDN object resolution timing. SonicOS resolves FQDN address objects at boot and then at a configurable interval. If you add a new walled garden domain and the resolution has not refreshed yet, unauthenticated devices cannot reach it. Force a manual refresh after adding new FQDN objects, or set the DNS refresh interval to 60 seconds in high-traffic deployments. Third: VLAN sub-interface configuration. Dynamic VLAN assignment via RADIUS only works if the target VLANs exist as sub-interfaces on the SonicWall before the first device authenticates. If a RADIUS response returns Tunnel-Private-Group-ID 110 but VLAN 110 does not exist as a sub-interface on the SonicWall, the device either gets dropped or falls back to the default VLAN. Build and test all VLAN sub-interfaces before enabling RADIUS VLAN assignment. For MSPs managing multiple venues, Purple's cloud dashboard lets you manage RADIUS policies, PPSK tables, and splash page configurations centrally. You can push configuration changes to all venues from a single interface. That is the operational advantage of a cloud overlay approach - the SonicWall hardware stays in place, and Purple handles the identity and policy layer above it. --- SEGMENT 4: RAPID-FIRE Q&A (approximately 1 minute) A few questions that come up regularly. "Can I use SonicWave APs in standalone mode with Purple?" Yes, but you lose some functionality. In standalone mode, SonicWave APs manage their own RADIUS configuration locally. You can still point them at Purple's RADIUS server for 802.1X. But for PPSK with dynamic VLAN assignment, you need the SonicWall TZ as the RADIUS proxy or the Wireless Network Manager managing the AP policy centrally. "Does Purple support WPA3 on SonicWave?" WPA3 support on SonicWave depends on the firmware version and AP model. SonicWave 600 series APs support WPA3. For captive portal use cases, WPA3 with Opportunistic Wireless Encryption is compatible with Purple's LHM redirect flow, but test on your specific firmware version before deploying at scale. "How does Purple handle GDPR for guest data collected via the splash page?" Purple is ISO 27001 certified, GDPR compliant, and Cyber Essentials certified. Consent is captured at the splash page with configurable opt-in checkboxes. Purple stores first-party data in line with your data retention policy. Guests can access and delete their data via Purple's self-service portal. "What RADIUS attributes does Purple return for dynamic VLAN assignment?" Three attributes: Tunnel-Type with value VLAN, Tunnel-Medium-Type with value 802, and Tunnel-Private-Group-ID with the VLAN ID as a string. These are the standard RFC 2868 attributes supported by SonicOS and SonicWave. --- SEGMENT 5: SUMMARY AND NEXT STEPS (approximately 1 minute) To summarise. SonicWall TZ firewalls and SonicWave APs integrate with Purple via two primary mechanisms: LHM for guest captive portal redirection, and RADIUS for 802.1X staff authentication and PPSK-based multi-tenant isolation. The key configuration steps are: enable External Guest Authentication on the guest zone, configure the Purple portal URL on port 4043, build your walled garden FQDN objects, configure RADIUS on the SonicWave AP policy in Wireless Network Manager, and create your VLAN sub-interfaces on the SonicWall before enabling dynamic VLAN assignment. For multi-tenant deployments, PPSK with RADIUS-based VLAN steering is the architecture to use. One SSID, one set of APs, complete tenant isolation via identity-based VLAN assignment. If you are planning a deployment or reviewing an existing one, Purple's technical team can provide venue-specific RADIUS configuration files and walled garden domain lists. The Purple platform supports 80,000 live venues and has processed 440 million logins in 2024 - the integration patterns we have covered today are proven at scale. Thanks for listening. The full written guide with step-by-step configuration tables and Mermaid architecture diagrams is available on the Purple website. --- END OF SCRIPT