Vai al contenuto principale
Italiano

Captive Portal vs Splash Page

Questa guida autorevole analizza la distinzione fondamentale tra Captive Portal e splash page nelle reti WiFi per gli ospiti. Chiarisce come il meccanismo di intercettazione di rete sottostante funzioni in sinergia con l'interfaccia visiva per gli ospiti, aiutando i responsabili IT e i gestori delle strutture a prendere decisioni architetturali e di acquisto informate.

📖 8 minuti di lettura📝 1,872 parole🔧 3 esempi pratici❓ 3 domande di esercitazione📚 8 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast
CAPTIVE PORTAL VS SPLASH PAGE — A PURPLE TECHNICAL BRIEFING Podcast Script — Approximately 10 Minutes UK English Voice --- SEGMENT 1: INTRODUCTION AND CONTEXT (approximately 1 minute) Welcome to the Purple Technical Briefing series. I'm your host, and today we're cutting through one of the most persistent sources of confusion in guest WiFi procurement and deployment: the difference between a captive portal and a splash page. If you've ever sat in a vendor meeting and heard these two terms used interchangeably, you're not alone. It happens constantly — in RFP documents, in IT strategy decks, even in conversations between network engineers who really should know better. And the confusion matters, because when you conflate the two, you end up either over-specifying the wrong component, under-investing in the right one, or worse — deploying a guest WiFi solution that looks great but has no proper network control underneath it, or one that's technically solid but drives guests away with a clunky, unbranded login screen. So let's fix that today. By the end of this briefing, you'll have a clear mental model of what each component does, how they interact, and what to look for when you're evaluating solutions for your venue — whether that's a hotel, a retail estate, a stadium, or a public-sector building. --- SEGMENT 2: TECHNICAL DEEP-DIVE (approximately 5 minutes) Let's start with the captive portal, because it's the foundation everything else sits on. A captive portal is a network-layer mechanism. Its job is to intercept all outbound traffic from a newly connected device and hold it in a kind of digital waiting room until that device has been authenticated. When a guest connects to your WiFi SSID, their device gets an IP address via DHCP — that part works normally. But before any actual internet traffic is allowed through, the captive portal intercepts it. Here's the technical sequence. The guest's device sends an HTTP or HTTPS request — it might be trying to load a website, or it might be the operating system's own connectivity check, which modern devices like iPhones and Android phones run automatically. The captive portal controller — which sits either on your wireless controller, your router, or a cloud-based platform — intercepts that DNS query or HTTP request and redirects it. Instead of reaching the internet, the device receives a redirect response pointing it to a specific URL. That URL is where the splash page lives. Now, the redirection mechanism itself uses one of two primary techniques. The first is DNS hijacking — the captive portal intercepts DNS queries and returns the IP address of the portal server instead of the real destination. The second is HTTP redirect — the portal intercepts the HTTP request at the gateway and issues a 302 redirect response. For HTTPS traffic, this is more complex, because you can't intercept an encrypted session without triggering a certificate warning. That's why most captive portal implementations rely on the operating system's built-in Captive Network Assistant — the pop-up that appears on your phone when you connect to a new network — which uses a known HTTP endpoint to detect captive portals before attempting HTTPS connections. At the network layer, the captive portal is enforcing access control using firewall rules. Unauthenticated devices are placed in a restricted VLAN or subnet where all traffic except DNS and HTTP to the portal server is blocked. Once authentication is confirmed — whether that's a simple click-through, a social login, an email capture, or a full 802.1X credential exchange — the portal controller updates the firewall rules for that device's MAC address, moving it from the restricted zone to the authorised zone with full internet access. This is important: the captive portal is invisible to the guest. They never see it directly. What they see is the splash page. The splash page is the application layer — it's the HTML, CSS, and JavaScript that renders in the guest's browser or in the Captive Network Assistant pop-up. It's the visual interface: your brand, your logo, your welcome message, your terms and conditions, your social login buttons, your marketing opt-in checkboxes. It's what turns a cold network authentication event into a branded guest experience. Think of it this way. The captive portal is the bouncer at the door — it decides who gets in and enforces the rules. The splash page is the reception desk — it's the face of your venue, it collects information, and it makes the guest feel welcome. You need both, and they need to work together seamlessly. Now, why does this distinction matter commercially? Because when you're evaluating a guest WiFi solution, you need to ask different questions about each component. For the captive portal, you're asking: What authentication methods does it support? Can it handle 802.1X for corporate devices alongside social login for guests? Does it support MAC address bypass for devices that can't display a browser? How does it handle session timeouts and re-authentication? Is it compliant with your data protection obligations under GDPR? Does it integrate with your RADIUS infrastructure? Can it segment traffic by user type — separating guest traffic from staff traffic at the network layer? For the splash page, you're asking: How customisable is it? Can your marketing team edit it without touching the network configuration? Does it support A/B testing? Can it serve different content to different user segments — loyalty members versus first-time visitors, for example? Does it support video backgrounds, promotional banners, or post-connection redirect pages? How does it perform on mobile? Is it accessible? These are fundamentally different procurement criteria, and conflating the two leads to poor decisions. We've seen organisations invest heavily in a beautiful splash page design and then discover that the underlying captive portal doesn't support the authentication methods required by their IT security policy. We've also seen the reverse — technically robust captive portal deployments with splash pages so poorly designed that guest adoption rates are in the thirties. Let's talk about the standards underpinning all of this. The captive portal mechanism doesn't have a single governing standard, but it operates within the framework of several important ones. IEEE 802.1X is the port-based network access control standard that governs how devices authenticate to a network using credentials, certificates, or tokens. It's the foundation of enterprise WiFi security and is increasingly relevant even in guest WiFi contexts where you want to offer seamless, credential-based access to returning visitors. WPA3, the latest WiFi security protocol, introduces Opportunistic Wireless Encryption, which encrypts traffic even on open networks — relevant to captive portal deployments because it changes how the initial connection handshake works. From a compliance perspective, GDPR has significant implications for splash page design. If your splash page collects personal data — an email address, a name, a social login — you need explicit, informed consent, a clear privacy notice, and a lawful basis for processing. The splash page is where that consent is captured, but the captive portal is what enforces the connection between consent and access. If a guest declines your marketing opt-in, the captive portal still needs to grant them internet access — consent to marketing cannot be a condition of accessing the network under GDPR. PCI DSS is relevant if your guest WiFi network is in scope for card data environments — typically in retail or hospitality. Network segmentation enforced by the captive portal is a key control here, ensuring guest traffic is isolated from payment systems. --- SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approximately 2 minutes) Let me give you two real-world scenarios that illustrate how this plays out in practice. First, a 200-room hotel group. They deployed a guest WiFi solution where the splash page was beautifully branded — their logo, a welcome message, a promotional offer for the spa. But the underlying captive portal was a basic open-source implementation that used DNS hijacking without any session management. The result: guests who returned to the hotel were prompted to log in again on every visit, even within the same stay. The splash page looked great, but the captive portal had no MAC address persistence, no session timeout configuration, and no integration with the property management system. The fix required replacing the captive portal controller entirely — the splash page was fine. Second, a national retail chain. They deployed an enterprise-grade captive portal with full 802.1X support, RADIUS integration, and sophisticated traffic segmentation. But their splash page was a default template — plain white, no branding, a generic "Connect to WiFi" message. Guest adoption was 34%. After they invested in a properly designed, branded splash page with a single-click social login option, adoption rose to 71% within three months. The captive portal hadn't changed at all. The lesson from both scenarios: these separate components require separate investment and separate expertise. Don't let your network team own the splash page design, and don't let your marketing team make decisions about captive portal architecture. Common pitfalls to avoid: first, assuming that a splash page is a captive portal. It isn't. A splash page without a captive portal is just a web page that nobody is forced to visit. Second, deploying a captive portal without HTTPS support for the splash page. Any data collected on an unencrypted splash page — email addresses, login credentials — is transmitted in plaintext. That's a GDPR and security risk. Third, ignoring the mobile experience. Over 80% of guest WiFi connections are from mobile devices. If your splash page isn't optimised for mobile, you're creating friction at exactly the moment you should be creating a positive brand impression. --- SEGMENT 4: RAPID-FIRE Q AND A (approximately 1 minute) Let me run through a few questions we hear regularly. Can I have a splash page without a captive portal? Technically yes — you can host a web page and direct people to it — but without the captive portal enforcing the redirect, guests have no reason to visit it. You'd have no data capture, no consent management, and no network access control. Can I have a captive portal without a splash page? Yes, and this is common in enterprise environments where 802.1X handles authentication silently. But for guest-facing deployments, you almost always want a splash page to handle the user experience and data capture. Does WPA3 break captive portals? Not if implemented correctly. WPA3 with Opportunistic Wireless Encryption is compatible with captive portal deployments, but it requires the portal to use HTTPS and the network to advertise the portal URL correctly. Some older client devices have compatibility issues, which is why many venues run dual SSID configurations. Is social login via the splash page secure? It depends on the implementation. OAuth 2.0-based social login — via Google, Facebook, or Apple — is secure when implemented correctly. The splash page handles the OAuth flow, and the captive portal receives a token confirming authentication. The key risk is in how that token is validated and how the session is managed. --- SEGMENT 5: SUMMARY AND NEXT STEPS (approximately 1 minute) Let's wrap up with the key takeaways. One: a captive portal and a splash page are not the same thing. The captive portal is the network control mechanism — it intercepts traffic and enforces access rules. The splash page is the visual interface — it's what the guest sees and interacts with. Two: they work together. The captive portal redirects the guest to the splash page. The splash page collects authentication or consent. The captive portal then grants access based on that outcome. Three: evaluate them separately. Ask different questions, apply different expertise, and budget for both independently. Four: compliance lives at the intersection. GDPR consent is captured on the splash page but enforced by the captive portal. Get both right. Five: Purple provides both. If you're looking for a platform that handles enterprise-grade captive portal control alongside rich, customisable splash page design — with full analytics, GDPR compliance tooling, and integrations with your existing infrastructure — that's exactly what Purple is built for. For your next steps, I'd recommend reviewing the Purple implementation guides on 802.1X authentication and guest WiFi analytics. Links are in the show notes. And if you're in the middle of a procurement process, reach out to the Purple team for a technical assessment — it's worth getting the architecture right before you commit to a deployment. Thanks for listening. Until next time. --- END OF SCRIPT

📚 Part of our core series: La guida definitiva ai Captive Portal →

header_image.png

Sintesi esecutiva

Per i responsabili IT, gli architetti di rete e i direttori operativi delle strutture, il WiFi per gli ospiti non è più solo un servizio di cortesia; è un punto di contatto fondamentale per l'acquisizione di dati di prima parte, il coinvolgimento di marketing e la sicurezza della rete. Tuttavia, una costante fonte di confusione nelle RFP e nelle discussioni di implementazione è la sovrapposizione tra Captive Portal e splash page.

Questa guida chiarisce questa distinzione fondamentale. Un Captive Portal è un meccanismo di controllo a livello di rete che intercetta il traffico, blocca l'accesso a Internet e gestisce l'autenticazione sicura. Una splash page è l'interfaccia visiva a livello applicativo: la pagina web che gli ospiti vedono, con cui interagiscono e che utilizzano per autenticarsi.

Confondere questi due componenti comporta rischi significativi in fase di acquisto e implementazione, come l'acquisto di una splash page dal design accattivante ma con controlli backend non sicuri, o l'implementazione di un Captive Portal altamente sicuro ma con un'interfaccia utente macchinosa e priva di branding che scoraggia l'adozione da parte degli ospiti. Comprendendo come queste tecnologie lavorano insieme, le organizzazioni possono sfruttare piattaforme come Purple per offrire un'esperienza WiFi per gli ospiti sicura, conforme e altamente coinvolgente, in grado di generare un valore aziendale misurabile.

comparison_chart.png

Approfondimento tecnico

Il Captive Portal: intercettazione del traffico a livello di rete

Il Captive Portal opera ai livelli inferiori del modello OSI (tipicamente Layer 2 e Layer 3) per applicare il controllo degli accessi. Quando un dispositivo ospite si connette a un SSID aperto, il server DHCP locale gli assegna un indirizzo IP, una subnet mask e un gateway predefinito. Tuttavia, l'access point (AP) wireless o il controller del gateway inserisce l'indirizzo MAC del dispositivo in uno stato non autenticato all'interno della tabella delle sessioni del firewall.

In questo stato, the firewall blocca tutto il traffico IP in uscita, ad eccezione dei servizi di rete essenziali come DNS e DHCP. Quando l'ospite tenta di accedere a un sito web esterno, il Captive Portal intercetta il traffico utilizzando uno dei due metodi principali:

  1. Reindirizzamento HTTP (Redirect 302): il gateway intercetta la richiesta HTTP iniziale e restituisce una risposta HTTP 302 Found, reindirizzando il browser del client all'URL della splash page.
  2. DNS Hijacking: il gateway intercetta le query DNS e risolve tutti i nomi di dominio con l'indirizzo IP del server locale della splash page. Sebbene semplice, questo metodo è sempre più deprecato a causa del DNSSEC e degli avvisi di sicurezza a livello di browser.

I moderni sistemi operativi mobili utilizzano un daemon integrato chiamato Captive Network Assistant (CNA). Al momento della connessione a una rete, il CNA tenta di raggiungere un endpoint HTTP noto e non crittografato (ad es. captive.apple.com di Apple o connectivitycheck.gstatic.com di Google). Se la risposta viene intercettata e reindirizzata, il sistema operativo riconosce di trovarsi dietro un Captive Portal e mostra automaticamente la splash page in una finestra del browser di sistema dedicata, evitando che l'utente debba aprire manualmente un browser web.

Una volta che l'utente completa il flusso di autenticazione sulla splash page, il server di autenticazione (tipicamente un server RADIUS) invia un pacchetto Access-Accept al controller di rete. Il controller aggiorna quindi le sue regole del firewall per consentire all'indirizzo MAC del dispositivo il pieno accesso a Internet, spesso utilizzando il MAC Address Bypass (MAB) per ricordare il dispositivo per una durata di sessione specificata.

La Splash Page: esperienza utente a livello applicativo

A differenza del Captive Portal, la splash page è un'applicazione web standard che opera al Layer 7 (il livello applicativo). È costruita utilizzando tecnologie web standard (HTML, CSS e JavaScript) ed è ospitata localmente sul controller del gateway o, più comunemente, su una piattaforma basata su cloud come Purple.

La splash page funge da interfaccia visiva e punto di contatto del brand per l'ospite. Le sue principali funzioni tecniche includono:

  • Federazione delle identità: facilitazione dei login social (Google, Facebook, Apple) tramite protocolli OAuth 2.0.
  • Acquisizione dati: raccolta dei dettagli degli ospiti come indirizzi e-mail, nomi e numeri dei programmi fedeltà.
  • Gestione del consenso: acquisizione di opt-in espliciti per il marketing e accettazione dei Termini di servizio e delle Informative sulla privacy, garantendo la conformità a normative come il GDPR [1] e il California Consumer Privacy Act (CCPA).
  • Ad Serving e Branding: erogazione di banner promozionali mirati, annunci video o pagine di reindirizzamento post-connessione per monetizzare lo spazio fisico.

Poiché la splash page è un'applicazione web, deve essere altamente reattiva e ottimizzata per i dispositivi mobili, che rappresentano oltre l'80% delle connessioni WiFi degli ospiti.

architecture_overview.png

Guida all'implementazione

L'implementazione di una soluzione WiFi per gli ospiti di livello enterprise richiede un'attenta coordinazione tra l'infrastruttura di rete e il software basato su cloud. Di seguito è riportata una guida architetturale neutrale rispetto ai fornitori per l'implementazione di un sistema di Captive Portal e splash page.

Architettura di implementazione passo dopo passo

  1. Segmentazione della rete: configura una VLAN Guest dedicata sui tuoi switch e access point per isolare il traffico degli ospiti dalle reti aziendali interne, dai terminali POS (point-of-sale) e dai dispositivi IoT. Questo è un requisito fondamentale per la conformità PCI DSS [2].
  2. Configurazione dell'SSID: configura un SSID aperto con Opportunistic Wireless Encryption (OWE), se supportato dal tuo hardware, o un SSID aperto standard. Abilita il reindirizzamento al Captive Portal sul profilo SSID all'interno del tuo controller wireless (ad es. Cisco Catalyst, Aruba Instant On o Ruckus SmartZone).
  3. Configurazione del Walled Garden (ACL): Prima die l'autenticazione, il dispositivo ospite deve essere autorizzato ad accedere a determinati domini esterni per visualizzare correttamente la splash page. Questo è noto come "Walled Garden" o Access Control List (ACL). È necessario includere:
    • Il dominio della splash page ospitata nel cloud (ad es. *.purple.ai).
    • Gli endpoint OAuth per i provider di social login (ad es. *.facebook.com, *.google.com, *.apple.com).
    • Le Content Delivery Network (CDN) che ospitano le risorse necessarie (font, fogli di stile, immagini).
  4. Integrazione del server RADIUS: Configurare il controller wireless per utilizzare un server RADIUS esterno (come il cloud RADIUS di Purple) per l'autenticazione e l'accounting (802.1X / AAA) [3].
  5. Personalizzazione della Splash Page: Progettare la splash page all'interno del portale Purple, garantendo la coerenza del brand, la reattività sui dispositivi mobili e caselle di controllo chiare per il consenso legale.
  6. Criteri di sessione e larghezza di banda: Definire i timeout di sessione (ad es. 8 ore), i timeout di inattività (ad es. 30 minuti) e i limiti di larghezza di banda per utente (ad es. 5 Mbps in download, 2 Mbps in upload) sul controller di rete per prevenire abusi di rete e garantire un accesso equo a tutti gli ospiti.
Parametro tecnico Captive Portal (Gateway di rete) Splash Page (Applicazione cloud)
Livello OSI Livello 2 / Livello 3 (Rete/Collegamento dati) Livello 7 (Applicazione)
Protocollo primario RADIUS, DHCP, HTTP (reindirizzamento 302) HTTP, HTTPS, HTML5, CSS3, OAuth 2.0
Funzione principale Intercettazione del traffico, controllo degli accessi, limitazione della larghezza di banda Interfaccia utente, raccolta dati, consenso, branding
Visibilità utente Completamente invisibile (meccanismo di backend) Visibile al 100% (la schermata di benvenuto visiva)
Standard di sicurezza IEEE 802.1X, WPA3, OWE, PCI DSS HTTPS, SSL/TLS, GDPR, CCPA
Hardware tipico AP wireless, router gateway, controller Server cloud, CDN

Best Practice

Per garantire una rete WiFi per gli ospiti ad alte prestazioni, sicura e conforme alle normative di legge, i team IT devono attenersi alle seguenti best practice del settore:

1. Imporre certificati HTTPS e SSL/TLS

Tutto il traffico tra il dispositivo ospite e la splash page deve essere crittografato tramite HTTPS. L'esecuzione di una splash page su HTTP non crittografato espone i dati degli ospiti (comprese le credenziali di accesso e gli indirizzi e-mail) al packet sniffing e agli attacchi man-in-the-middle. Assicurarsi che il dominio della splash page disponga di un certificato SSL/TLS valido e pubblicamente attendibile. I certificati autofirmati genereranno gravi avvisi del browser, spingendo gli ospiti ad abbandonare la connessione.

2. Implementare la segmentazione della rete

Non instradare mai il traffico WiFi degli ospiti attraverso la stessa VLAN o subnet delle risorse aziendali. Il traffico degli ospiti deve essere isolato in una VLAN "solo ospiti" con regole di firewall rigide che impediscano qualsiasi instradamento inter-VLAN verso le subnet interne. Ciò riduce il rischio di propagazione di malware e di accesso non autorizzato a dati aziendali sensibili.

3. Garantire la conformità a GDPR e CCPA

Se la tua struttura opera nel Regno Unito, nell'UE o in California, o serve i relativi cittadini, la tua splash page deve essere conforme alle rigide leggi sulla privacy dei dati:

  • Consenso liberamente espresso: Le caselle di controllo per l'adesione al marketing devono essere deselezionate per impostazione predefinita. L'accesso a Internet non può essere vincolato al consenso alle comunicazioni di marketing.
  • Informativa sulla privacy chiara: Fornire un link diretto e facilmente accessibile all'informativa sulla privacy sulla splash page.
  • Diritto alla cancellazione: Assicurarsi che la piattaforma WiFi per gli ospiti (come Purple) supporti flussi di lavoro automatizzati per consentire agli ospiti di richiedere la cancellazione dei propri dati personali.

4. Ottimizzare per dispositivi mobili e CNA

Assicurarsi che la splash page sia leggera e altamente reattiva. Evitare sfondi video pesanti o immagini di grandi dimensioni non compresse che rallentano i tempi di caricamento della pagina, specialmente in ambienti ad alta densità di utenti (ad es. stadi o centri congressi). Testare la splash page su vari sistemi operativi mobili per garantire una visualizzazione fluida all'interno del browser nativo Captive Network Assistant (CNA).

Risoluzione dei problemi e mitigazione dei rischi

Modalità di guasto comuni e strategie di mitigazione

  • Mancata visualizzazione del pop-up CNA: Se il reindirizzamento del captive portal non riesce ad attivare il CNA del dispositivo, gli ospiti potrebbero rimanere connessi all'SSID senza accesso a Internet e senza un modo ovvio per accedere.
    • Mitigazione: Assicurarsi che il server DNS assegnato agli ospiti tramite DHCP sia completamente funzionante e in grado di risolvere i domini esterni. Se la risoluzione DNS non riesce, il CNA non può eseguire il controllo di connettività e il reindirizzamento non verrà mai attivato.
  • Errata configurazione del Walled Garden: Gli ospiti non riescono a completare il social login perché la pagina di accesso OAuth non si carica o mostra un errore di connessione.
    • Mitigazione: Ricontrollare l'ACL del Walled Garden del gateway. I provider di social login cambiano frequentemente i loro intervalli IP e domini. L'utilizzo di una piattaforma WiFi per gli ospiti gestita in cloud come Purple garantisce che i domini del Walled Garden vengano aggiornati e sincronizzati automaticamente con l'hardware.
  • Restrizioni del browser CNA: Il browser CNA nativo sui dispositivi mobili ha funzionalità limitate rispetto ai browser standard (ad es. Safari o Chrome). Potrebbe bloccare cookie, pop-up o reindirizzamenti esterni.
    • Mitigazione: Evitare JavaScript complessi o integrazioni di terze parti sulla splash page che richiedono la persistenza dei cookie o pop-up del browser. Mantenere il flusso di autenticazione il più semplice e diretto possibile.

ROI e impatto aziendale

Comprendere la distinzione tra captive portal e splash page consente alle organizzazioni di massimizzare il ritorno sull'investimento (ROI) ottimizzando sia le prestazioni tecniche che l'utilità commerciale della loro rete WiFi per gli ospiti.

Valore aziendale di una soluzione a doppia ottimizzazione

  • Maggiore coinvolgimento degli ospiti: Una splash page progettata in modo professionale, allineata con i prodotti principali di Purple come Guest WiFi e WiFi Analytics [4] [5], può aumentare i tassi di accesso degli ospiti fino al 40% rispetto alle schermate di benvenuto generiche e senza brand.
  • Raccolta di dati proprietari (First-Party) dettagliati: Offrendo un social login fluido e campi di modulo strutturati, le sedi in settori come Retail , Hospitality , Sanità e Trasporti possono acquisire indirizzi email puliti e verificati, dati demografici e dati sulla frequenza delle visite.
  • Opportunità di monetizzazione: Sfruttare la splash page per la monetizzazione dei retail media consente alle sedi di mostrare annunci pubblicitari mirati agli ospiti al momento della connessione, attingendo a un mercato della pubblicità digitale in rapida crescita.
  • Efficienza operativa: Un Captive Portal robusto riduce i ticket di supporto IT automatizzando l'onboarding dei dispositivi, gestendo i timeout delle sessioni e applicando limiti di larghezza di banda per prevenire la congestione della rete.

Implementando la soluzione enterprise di Purple, le sedi possono garantire che la loro architettura di rete sia sicura e conforme, offrendo al contempo ai team di marketing la libertà creativa di progettare splash page straordinarie e ad alta conversione che stimolano la fidelizzazione dei clienti e i ricavi.

Riferimenti

Definizioni chiave

Captive Portal

A network-layer mechanism that intercepts client traffic and restricts internet access until authentication criteria are met.

Encountered by IT teams when configuring wireless controllers, gateways, or firewalls to redirect unauthenticated MAC addresses.

Splash Page

The visual, web-based landing page rendered in a guest's browser that facilitates authentication, data capture, and brand engagement.

Managed by marketing and venue operations teams to design the user onboarding experience and collect customer data.

Captive Network Assistant (CNA)

A built-in operating system feature on mobile devices that automatically detects a captive portal and opens the splash page in a system browser window.

Crucial for user experience, as it bypasses the need for guests to manually open a browser to log in.

Walled Garden (ACL)

A list of IP addresses or domains that an unauthenticated user is permitted to access before logging into the network.

Must be configured correctly on the wireless gateway to allow the splash page and social login OAuth flows to load.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users connecting to a network.

Used by the captive portal to verify guest credentials against a database and grant network access.

MAC Address Bypass (MAB)

A mechanism that allows a device to bypass the captive portal login screen on subsequent connections by remembering its hardware MAC address.

Used to create a seamless experience for returning guests by eliminating the need to log in repeatedly.

Opportunistic Wireless Encryption (OWE)

A WiFi standard (part of WPA3) that provides encryption on open networks without requiring a shared password.

Enables secure data transmission on public guest networks while still allowing captive portal redirection.

VLAN Segmentation

The practice of dividing a physical network into multiple logical networks at Layer 2 to isolate traffic.

Essential for guest WiFi deployments to ensure guest traffic is completely isolated from secure corporate networks.

Esempi pratici

A national retail chain with 150 stores wants to implement a guest WiFi network that captures customer emails for marketing purposes, but their IT security team is concerned about guest traffic accessing corporate Point-of-Sale (POS) systems. How should this be architected?

  1. Configure a dedicated Guest VLAN (e.g., VLAN 50) on all switches and access points across all 150 stores, completely isolated from the corporate POS VLAN (VLAN 10) using firewall ACLs. 2. Enable captive portal redirection on the Guest SSID, pointing the redirect URL to Purple's secure cloud-hosted splash page. 3. Configure the network gateway to restrict all pre-authenticated traffic on VLAN 50, allowing access only to DNS, DHCP, and Purple's Walled Garden domains. 4. Utilize Purple's integration with the wireless controller to authenticate guests via RADIUS, granting internet access only after the guest provides a verified email address and accepts the terms of service on the splash page.
Commento dell'esaminatore: This architecture achieves the dual goals of marketing and security. By separating the network layers (VLAN segmentation at Layer 2/3) from the application layer (email capture on the splash page at Layer 7), the retail chain ensures PCI DSS compliance for their POS systems while maximizing marketing data capture.

A 50,000-seat sports stadium wants to offer free WiFi during events. The operations team wants a seamless login experience to prevent network congestion at the start of games, while the marketing team wants to display sponsor video ads on the splash page. How do you balance these requirements?

  1. Deploy high-density access points and configure a captive portal with MAC Address Bypass (MAB) set to 30 days, so returning fans do not have to see the splash page on every visit. 2. For new connections, design an ultra-lightweight splash page optimized for fast loading on mobile devices. 3. Embed a short, 5-second sponsor video ad that plays directly on the splash page, with a 'Skip and Connect' button that immediately triggers the captive portal authentication. 4. Configure the captive portal to allocate a generous bandwidth profile (e.g., 10 Mbps) per user to ensure smooth video streaming and web browsing.
Commento dell'esaminatore: In high-density environments, performance is paramount. Using MAB for returning fans drastically reduces the load on the captive portal and RADIUS servers during peak times. The lightweight splash page design and short video ad ensure that the marketing team achieves their sponsorship goals without causing network frustration or onboarding delays.

A large public hospital wants to provide guest WiFi for patients and visitors. The compliance team requires that the network comply with healthcare data privacy standards and that patients cannot access malicious or inappropriate web content. What is the recommended deployment strategy?

  1. Configure the captive portal to redirect users to a splash page that contains a clear healthcare-specific privacy notice and terms of service. 2. Integrate the captive portal gateway with a cloud-based DNS filtering service (such as Cisco Umbrella or Webroot) to automatically block access to adult content, malware, and phishing sites. 3. Disable social login options to prevent the collection of unnecessary personal data, relying instead on a simple 'Accept and Connect' button or a basic email verification form. 4. Enforce strict bandwidth shaping on the captive portal to prioritize clinical applications and hospital IoT devices over guest streaming traffic.
Commento dell'esaminatore: Healthcare environments require a conservative approach to data privacy and content filtering. By omitting social login, the hospital minimizes its compliance footprint under healthcare data regulations. Integrating DNS filtering directly at the captive portal gateway ensures that content policies are enforced network-wide, regardless of what the user does on the splash page.

Domande di esercitazione

Q1. An IT manager notices that guests are connecting to the guest WiFi SSID, but the branded splash page is not appearing, and users cannot access the internet. What is the most likely technical cause of this issue, and how should it be diagnosed?

Suggerimento: Consider the role of DNS in the captive portal redirection process.

Visualizza risposta modello

The most likely cause is a failure in the DNS resolution process. When a device connects, it must resolve the splash page domain name to load the welcome screen. If the DNS server assigned to the guest VLAN is down, misconfigured, or blocked by the gateway's pre-authentication firewall rules, the device cannot resolve the domain, and the redirect will fail. To diagnose, connect a test device to the SSID, verify that it receives a valid IP and DNS server address via DHCP, and attempt to ping or resolve a public domain. If DNS fails, check the DNS server status and ensure that DNS traffic (UDP port 53) is allowed in the gateway's pre-authentication ACL.

Q2. A retail venue wants to allow guests to log in using their Facebook accounts. However, when users click the Facebook login button on the splash page, they receive a 'Connection Refused' error. The rest of the splash page loads perfectly. What is the issue, and how do you resolve it?

Suggerimento: Think about what external resources a pre-authenticated device is allowed to access.

Visualizza risposta modello

The issue is that the Facebook authentication domains are not included in the gateway's pre-authentication Walled Garden Access Control List (ACL). Because the user is not yet authenticated, the captive portal blocks all external traffic. When the user clicks the Facebook button, the browser attempts to reach Facebook's OAuth servers, which is blocked by the gateway. To resolve this, the IT team must add the required Facebook OAuth domains (e.g., *.facebook.com, *.facebook.net) to the Walled Garden ACL on the wireless controller or gateway.

Q3. A hospitality venue has deployed a guest WiFi network. The marketing team wants to collect guest email addresses and immediately send a welcome newsletter. However, the legal team is concerned about GDPR compliance regarding consent. How should the splash page and captive portal be configured to satisfy both teams?

Suggerimento: GDPR requires that consent for marketing must be freely given and not a condition of service.

Visualizza risposta modello

To satisfy both marketing and legal teams under GDPR: 1. The splash page must feature a clear, un-checked checkbox for the marketing opt-in ('I consent to receive marketing emails'). 2. Agreeing to the Terms of Service and Privacy Policy must be a separate checkbox or clearly stated as a condition of using the free network. 3. The underlying captive portal and splash page system must be configured to grant internet access regardless of whether the marketing checkbox is checked or unchecked. If a user leaves the marketing box unchecked but accepts the Terms of Service, the system must still send an Access-Accept packet to the network controller. This ensures consent is freely given, satisfying GDPR, while still allowing marketing to collect emails from users who do opt-in.

Continua a leggere questa serie

Login al Captive Portal: Risoluzione dei problemi e guida esplicativa

Questa guida fornisce un riferimento tecnico completo per comprendere, implementare e risolvere i problemi dei sistemi di login al captive portal in ambienti WiFi aziendali per ospiti. Spiega gli esatti meccanismi di reindirizzamento HTTP e di dirottamento DNS utilizzati dai moderni captive portal, descrive in dettaglio come l'HSTS e i browser HTTPS sicuri possano bloccare i reindirizzamenti locali e fornisce una checklist di risoluzione dei problemi chiara e pratica che copre sia le soluzioni lato client (disattivazione delle VPN, disattivazione della randomizzazione MAC, utilizzo di NeverSSL) sia le risoluzioni lato operatore (configurazione del walled garden, ottimizzazione del tempo di lease DHCP, verifica dell'intercettazione DNS). I gestori delle sedi, i responsabili IT e gli architetti di rete troveranno questa guida essenziale per ridurre al minimo i ticket di supporto degli ospiti e massimizzare il ROI della loro infrastruttura wireless.

Leggi la guida →

Come configurare un hotspot WiFi per la tua attività

Questa guida autorevole fornisce a leader IT, architetti di rete e direttori delle operazioni di sede un modello pratico e indipendente dal fornitore per l'implementazione di hotspot WiFi per ospiti sicuri, conformi e che migliorano il business. Copre decisioni architetturali critiche — dalla segmentazione VLAN e configurazione del Captive Portal alla conformità GDPR e alla modellazione del traffico — e dimostra come trasformare l'infrastruttura di rete da un centro di costo a una piattaforma di analisi che genera entrate utilizzando le capacità di Guest WiFi e analisi di Purple.

Leggi la guida →

Purple vs Cisco Spaces (DNA Spaces): Quando scegliere ciascuno

Questa guida di riferimento tecnico fornisce un confronto completo tra Purple e Cisco Spaces (precedentemente DNA Spaces) per le implementazioni di captive portal aziendali e WiFi per ospiti. Valuta le differenze architetturali, la profondità dell'automazione del marketing e la questione critica del vendor lock-in hardware per aiutare i leader IT a prendere decisioni informate sull'infrastruttura.

Leggi la guida →