WiFi Landing Page vs. Splash Page: Qual è la Differenza?

Questa guida di riferimento tecnico chiarisce le differenze architettoniche e funzionali tra le landing page WiFi e le splash page — due termini spesso confusi sia dai team IT che dai dipartimenti marketing. Fornisce ad architetti di rete, IT manager e direttori delle operazioni delle sedi strategie di implementazione attuabili per ottimizzare le prestazioni del captive portal, garantire la conformità GDPR e PCI DSS e massimizzare il ROI in tutte le sedi aziendali, inclusi ambienti di ospitalità, vendita al dettaglio e settore pubblico.

📖 8 min di lettura📝 1,923 parole🔧 2 esempi❓ 3 domande📚 9 termini chiave

🎧 Ascolta questa guida

Visualizza trascrizione

Welcome back to the Purple Technical Briefing. Today we're tackling a question that comes up in almost every initial scoping call with CTOs and network architects: What exactly is the difference between a WiFi landing page and a splash page?

In the consumer world, people use these terms interchangeably. But when you're architecting an enterprise guest network across fifty retail locations, or a high-density stadium deployment, confusing the two can lead to compliance headaches, broken user journeys, and missed ROI.

So, over the next ten minutes, we're going to define the technical distinction, look at the architecture, discuss common implementation pitfalls, and finish with a rapid-fire Q and A. Let's get into it.

[SECTION: TECHNICAL DEFINITIONS]

First, let's define the terms. When we talk about a Captive Portal, we're referring to the entire walled-garden mechanism that intercepts HTTP and HTTPS traffic and forces a client device to authenticate before granting external network access.

Within that portal flow, the Splash Page is the gatekeeper. It is the very first screen a user sees when they connect to the SSID. Its primary technical function is authentication and authorisation. It's where the user accepts the Terms and Conditions, enters their credentials, or authenticates via an identity provider — perhaps using OAuth or a loyalty integration. From a compliance standpoint, this is where you handle GDPR consent and PCI DSS disclaimers if you're processing payments.

Now, contrast that with the Landing Page. The landing page is the destination after successful authentication. Once the RADIUS server sends the Access-Accept message and the client device is placed onto the active VLAN with internet routing, the walled garden drops. The controller then redirects the user's browser to the Landing Page.

Why does this distinction matter? Because the Splash Page exists in a highly constrained environment. The device doesn't have full internet access yet. It can only reach the specific IP addresses or hostnames you've whitelisted in your Walled Garden configuration. If you try to load heavy external scripts, dynamic video players, or complex third-party trackers on a splash page without proper whitelisting, the page will break, and the user gets stuck in a connection loop.

The Landing Page, however, sits on the open internet. The user is authenticated. Here, you can load full marketing experiences, dynamic app download links, interactive venue maps, and targeted promotions driven by the first-party data you just captured on the splash page.

[SECTION: IMPLEMENTATION AND PITFALLS]

Now let's talk about implementation and where I see deployments go wrong.

The most common mistake is overloading the Splash Page. I've seen marketing teams hand over a five-megabyte page with four different external tracking pixels and a background video, asking IT to make it the login screen.

When you do that, you have to add dozens of CDNs and third-party domains to your Walled Garden whitelist. Not only is this a nightmare to maintain as those IP ranges change, but it's a security risk. You are poking holes in your pre-authentication firewall. Furthermore, modern mobile operating systems — like iOS and Android — use a specialised mini-browser to render captive portals. These Captive Network Assistants, or CNAs, have limited functionality. They often block cookies, restrict local storage, and will automatically close if they detect external navigation before the internet connection is fully established.

The best practice? Keep the Splash Page lean, fast, and focused purely on data capture and legal consent. Use a cloud-based captive portal solution that optimises the HTML payload for these CNA browsers.

Once the user hits Connect, then redirect them to the rich, dynamic Landing Page. This is where you leverage your WiFi Analytics platform. Because you've already captured their profile, the Landing Page can be personalised. If they are a returning guest at your hotel, the landing page can welcome them by name and offer a one-click booking for the spa. If they are in a retail environment, it can show a heatmap-driven promotion based on their current zone.

[SECTION: CASE STUDIES]

Let me give you two concrete case studies that illustrate this perfectly.

First, a five-hundred-room hotel resort. They were experiencing high drop-off rates on their guest WiFi login. The marketing team had added a four-megabyte promotional video and a complex interactive map to the initial connection screen. The fix was straightforward: replace the connection screen with a lightweight Splash Page under one megabyte, focused solely on room number and last name authentication plus Terms and Conditions acceptance. The video and map were moved to the post-authentication Landing Page. Connection rates improved by over forty percent within the first week.

Second, a retail chain with fifty locations. They wanted to offer seamless WiFi access to returning loyalty members without forcing them to log in every time. The solution was MAC Authentication Bypass integrated with the loyalty database. When a returning device associates with the SSID, the controller queries the RADIUS server, identifies the MAC address, and immediately returns an Access-Accept without presenting the Splash Page. The user is redirected to a personalised Landing Page with their loyalty status and a targeted offer. The result: a thirty percent increase in loyalty app engagement across the estate.

[SECTION: RAPID-FIRE Q&A]

Now, let's move to our Rapid-Fire Q and A. These are the top three questions I get from network engineers.

Question one: Can I bypass the Splash Page entirely for returning users?

Yes. This is called MAC Authentication Bypass, or seamless login. The controller recognises the device's MAC address from a previous session and automatically authorises them, taking them straight to the Landing Page or their original destination. Just ensure your privacy policy covers persistent device tracking.

Question two: Why is my Splash Page showing a certificate error?

This usually happens when you try to intercept HTTPS traffic without a valid SSL certificate on the controller, or if you're using a self-signed certificate. Always use a publicly trusted certificate for your captive portal hostname, and ensure your controller supports modern HTTPS redirection standards like RFC 8908.

Question three: Should the Landing Page be hosted locally on the controller or in the cloud?

Always in the cloud. Hosting on the controller limits your ability to update content dynamically, run A/B tests, or integrate with external CRMs. A cloud-based architecture separates the network control plane from the user experience layer, which is exactly what enterprise deployments require.

[SECTION: SUMMARY AND NEXT STEPS]

To summarise: The Splash Page is the secure, constrained gatekeeper for authentication and consent. Keep it lightweight — under one megabyte, no external dependencies, optimised for the Captive Network Assistant. The Landing Page is the post-authentication destination for engagement, marketing, and ROI generation. It operates on the open internet with full browser capabilities.

Understand the constraints of the Walled Garden and the Captive Network Assistant, and you'll avoid ninety percent of the support tickets associated with guest WiFi deployments.

The three key rules to take away: Splash for Security, Landing for Loyalty. The Walled Garden is a sandbox, not a playground. And always — Authentication before Animation.

Thanks for joining this technical briefing. If you want to dive deeper into configuring cloud-based captive portals, check out the full reference guide on the Purple website. Until next time, keep your networks secure and your users connected.

Punti chiave

✓The Splash Page is the pre-authentication gatekeeper operating within the restricted Walled Garden — its sole purpose is identity verification and legal consent.
✓The WiFi Landing Page is the post-authentication destination operating on the open internet — its purpose is marketing engagement, personalisation, and ROI generation.
✓The Captive Network Assistant (CNA) renders the Splash Page in a sandboxed mini-browser that blocks cookies, restricts JavaScript, and limits external resource loading.
✓Overloading the Splash Page with marketing assets is the leading cause of guest WiFi connection failures and elevated support ticket volumes.
✓MAC Authentication Bypass (MAB) eliminates the Splash Page for returning devices, redirecting them directly to a personalised Landing Page — improving experience for repeat visitors.
✓A cloud-based captive portal architecture separates the network control plane from the user experience layer, enabling centralised management, dynamic content updates, and CRM integration.
✓Measurable ROI from guest WiFi is generated primarily through the Landing Page — via direct revenue attribution, loyalty engagement, and first-party data capture feeding into WiFi Analytics.

Riepilogo Esecutivo

Per i team IT aziendali che gestiscono sedi ad alta densità — dalle proprietà Hospitality agli immobili Retail — i termini "splash page" e "landing page" sono spesso confusi. Trattarli come intercambiabili nell'architettura di rete porta a percorsi utente interrotti, vulnerabilità di sicurezza e opportunità di acquisizione dati mancate.

A un livello fondamentale, la Splash Page è il guardiano della pre-autenticazione. Esiste all'interno dell'ambiente vincolato di un Walled Garden, responsabile della verifica dell'identità, dell'autenticazione MAC e del consenso legale ai sensi del GDPR e del PCI DSS. La WiFi Landing Page è la destinazione post-autenticazione. Opera su internet aperto, sfruttando i dati acquisiti durante il login per offrire esperienze personalizzate, promuovere il download di app e generare un ROI misurabile tramite le integrazioni Guest WiFi .

Questa guida illustra le specifiche tecniche, le metodologie di implementazione e le modalità di errore comuni associate alla progettazione del captive portal — consentendo agli architetti di rete di costruire reti di accesso ospiti robuste, conformi e generatrici di entrate per qualsiasi tipo di sede.

Approfondimento Tecnico

L'Architettura del Captive Portal

Un captive portal intercetta il traffico HTTP/HTTPS da client non autenticati e li reindirizza a un'interfaccia web designata. Questo meccanismo si basa su una combinazione di dirottamento DNS, reindirizzamento HTTP 302 e autenticazione RADIUS — con implementazioni moderne che adottano sempre più RFC 8908 (Captive Portal Identification in DHCP and Router Advertisements) per consentire il rilevamento del captive portal a livello di sistema operativo nativo senza una fragile intercettazione HTTP.

All'interno di questa architettura, la Splash Page e la Landing Page svolgono ruoli fondamentalmente diversi in punti diversi del ciclo di vita dell'autenticazione.

1. La Splash Page (Stato di Pre-Autenticazione)

Quando un dispositivo si associa a un SSID, il controller wireless lo inserisce in una VLAN non autenticata. Tutto il traffico in uscita viene intercettato e reindirizzato all'hostname del captive portal. Il Captive Network Assistant (CNA) del sistema operativo — un pseudo-browser specializzato e in sandbox integrato in iOS, Android e Windows — rileva il captive portal e visualizza la Splash Page.

Vincoli Tecnici dell'Ambiente CNA:

Il CNA non è un browser completo. Opera con significative restrizioni che influenzano direttamente ciò che può essere implementato su una Splash Page:

I cookie e l'archiviazione locale sono spesso bloccati o gravemente limitati
Framework JavaScript complessi potrebbero non essere eseguiti
Le risorse esterne (font, script, immagini) possono essere caricate solo se i loro domini sono nella whitelist del Walled Garden
Il CNA si chiuderà automaticamente se rileva che il dispositivo ha ottenuto l'accesso a internet prima che l'utente abbia completato l'autenticazione
La persistenza della sessione alla chiusura del CNA non è affidabile

Funzioni Primarie della Splash Page:

Dati questi vincoli, la Splash Page dovrebbe essere progettata esclusivamente per: autenticazione (login sociale tramite OAuth, SMS OTP, credenziali basate su modulo o integrazione con programmi fedeltà); accettazione dei Termini e Condizioni; acquisizione del consenso GDPR; e registrazione dell'indirizzo MAC per futuri accessi senza interruzioni.

Raccomandazione sul Payload: Mantenere la Splash Page sotto 1MB. Utilizzare CSS inline, evitare librerie di font esterne e minimizzare JavaScript. Ogni dipendenza esterna richiede una corrispondente voce nella whitelist del Walled Garden — ognuna delle quali rappresenta sia un onere di manutenzione che una potenziale esposizione alla sicurezza.

2. La Landing Page (Stato di Post-Autenticazione)

Al successo dell'autenticazione, il server RADIUS restituisce un messaggio Access-Accept. Il controller wireless aggiorna la sessione del client, migrando il dispositivo a una VLAN autenticata con routing internet completo. Il Walled Garden viene disattivato. Il controller — o la piattaforma captive portal basata su cloud — emette un reindirizzamento HTTP 302 alla WiFi Landing Page.

A questo punto, il dispositivo opera con un browser completo e accesso internet illimitato. La Landing Page può sfruttare l'intero set di funzionalità dello sviluppo web moderno:

Contenuti dinamici e personalizzati guidati dal profilo utente acquisito sulla Splash Page
Strumentazione analitica completa (Google Analytics, pixel di tracciamento personalizzati, webhook CRM)
Contenuti multimediali ricchi, inclusi video, mappe interattive e dashboard fedeltà
Inviti al download di app con routing deep-link
Promozioni mirate basate sui dati di WiFi Analytics , inclusa la frequenza delle visite, il tempo di permanenza e la zona della sede

Funzioni Primarie della Landing Page: Coinvolgimento marketing, visualizzazione del programma fedeltà, promozioni mirate, navigazione della sede e call to action orientate alla conversione.

Flusso di Autenticazione: End-to-End

La sequenza seguente illustra il flusso completo dall'associazione SSID alla consegna della Landing Page:

Il dispositivo client si associa all'SSID ospite
Il controller assegna il dispositivo a una VLAN non autenticata
Il client tenta una richiesta HTTP; il controller intercetta ed emette un reindirizzamento 302 alla Splash Page
Il CNA carica la Splash Page (risorse servite solo da domini nella whitelist del Walled Garden)
L'utente completa l'autenticazione e accetta i Termini e Condizioni
La piattaforma captive portal invia una richiesta di accesso al server RADIUS
RADIUS restituisce Access-Accept; il controller riceve un messaggio Change of Authorization (CoA)
Il controller migra il client alla VLAN autenticata
La piattaforma captive portal emette un reindirizzamento 302 alla WiFi Landing Page
Il browser client carica la Landing Page completa su internet aperto

Questa chiara separazione delle preoccupazioni — autenticazione sula Splash Page, l'engagement sulla Landing Page — è la base architettonica di ogni implementazione WiFi per ospiti ben progettata.

Guida all'Implementazione

L'implementazione di una soluzione WiFi per ospiti scalabile e di livello enterprise richiede la separazione del piano di controllo della rete dallo strato dell'esperienza utente. I seguenti passaggi forniscono un framework di implementazione indipendente dal fornitore, applicabile alle infrastrutture Cisco Meraki, Aruba, Ruckus e Ubiquiti.

Fase 1: Configurazione del Walled Garden

Configura il tuo Wireless LAN Controller (WLC) per inserire in whitelist solo i domini e gli intervalli IP strettamente necessari al funzionamento della Splash Page. Questo include tipicamente:

L'hostname della piattaforma captive portal (es. portal.purple.ai)
Domini dei provider di identità per il social login (es. accounts.google.com, graph.facebook.com)
Domini del gateway SMS se si utilizza l'autenticazione OTP
Qualsiasi risorsa CDN utilizzata dalla Splash Page stessa

Evita l'eccessiva inclusione in whitelist. Ogni voce aggiuntiva aumenta la superficie di attacco della tua rete di pre-autenticazione e complica la manutenzione continua man mano che gli intervalli IP cambiano.

Fase 2: Gestione dei Certificati SSL

Configura il WLC con un certificato SSL valido e pubblicamente attendibile per l'hostname di reindirizzamento del captive portal. I certificati auto-firmati attiveranno avvisi di sicurezza del browser nella CNA, inducendo gli utenti ad abbandonare il processo di connessione. La scadenza dei certificati è una delle principali cause di interruzioni del WiFi per gli ospiti — implementa il rinnovo automatico tramite Let's Encrypt o la tua piattaforma di gestione dei certificati.

Fase 3: Ottimizzazione della CNA

Progetna la Splash Page specificamente per l'ambiente CNA. Utilizza CSS inline, evita framework JavaScript esterni e testa su più versioni iOS e Android. Il comportamento della CNA di iOS in particolare cambia tra le principali release del sistema operativo — mantieni una matrice di test di regressione che copra almeno le due versioni principali più recenti di entrambe le piattaforme.

Fase 4: Logica di Reindirizzamento Post-Autenticazione

Configura il reindirizzamento post-autenticazione per supportare URL dinamici della Landing Page. Il server RADIUS può restituire attributi specifici del fornitore (VSA) o la piattaforma captive portal può utilizzare il profilo utente autenticato per costruire un URL personalizzato. Ciò consente la segmentazione — un visitatore per la prima volta riceve un'offerta di benvenuto, mentre un membro fedeltà con status Gold riceve una dashboard personalizzata.

Fase 5: Integrazione degli Analytics

Strumenta la Landing Page con il tuo stack di analytics. Poiché l'utente è ora su internet aperto con un browser completo, gli strumenti di analytics standard funzionano normalmente. Integra con il tuo CRM per creare un profilo cliente unificato che combini i dati della sessione WiFi con la cronologia degli acquisti, lo stato di fedeltà e le metriche di engagement marketing.

Per un confronto dettagliato tra architetture captive portal basate su cloud e on-premise, consulta Captive Portal Basato su Cloud vs. On-Premise: Qual è quello giusto per la tua attività? .

Migliori Pratiche

Disaccoppia Autenticazione e Marketing. La decisione architettonica più impattante è utilizzare la Splash Page strettamente per l'accesso sicuro e il consenso, e spostare tutte le risorse di marketing sulla Landing Page. Ciò migliora i tassi di connessione, riduce i ticket di supporto e semplifica gli audit di conformità.

Sfrutta il MAC Authentication Bypass per gli Utenti di Ritorno. Per i dispositivi di ritorno, il MAC Authentication Bypass (MAB) elimina completamente la Splash Page, reindirizzando gli utenti direttamente a una Landing Page personalizzata. Ciò migliora drasticamente l'esperienza utente per i visitatori abituali negli ambienti Hospitality e Retail . Assicurati che la tua politica sulla privacy copra esplicitamente il tracciamento persistente dei dispositivi.

Adotta Architetture Cloud-Centriche. Così come l'industria del networking si è mossa verso il WAN software-defined per la gestione centralizzata — come dettagliato in I Vantaggi Chiave del SD WAN per le Aziende Moderne — le piattaforme captive portal dovrebbero essere ospitate su cloud. Ciò consente la gestione centralizzata su proprietà distribuite, aggiornamenti rapidi dei contenuti senza modifiche al firmware del controller e un'integrazione perfetta con CRM esterni e piattaforme di automazione del marketing.

Implementa RFC 8908 per la Compatibilità con i Sistemi Operativi Moderni. La rilevazione nativa del captive portal tramite RFC 8908 riduce la dipendenza dall'intercettazione HTTP, migliorando l'affidabilità su versioni moderne di iOS e Android che applicano sempre più la navigazione solo HTTPS.

Mantieni un Programma di Audit del Walled Garden. Rivedi le voci del Walled Garden trimestralmente. Gli intervalli IP per i principali provider di identità cambiano senza preavviso. Le voci obsolete che non si risolvono più creano errori di autenticazione; le voci mancanti bloccano i flussi di autenticazione legittimi.

Risoluzione dei Problemi e Mitigazione dei Rischi

Il Loop di Connessione. Se un utente si autentica ma viene ripetutamente reindirizzato alla Splash Page, verifica che il messaggio RADIUS Access-Accept stia raggiungendo il controller e che il client stia ricevendo correttamente un lease DHCP sulla VLAN autenticata. Controlla anche che la porta CoA (Change of Authorization) (UDP 3799) non sia bloccata da un firewall intermedio.

Chiusura Prematura della CNA. Se la CNA si chiude prima che l'utente possa autenticarsi, il dispositivo ha probabilmente rilevato l'accesso a internet prematuramente. Ciò può accadere se il Walled Garden è troppo permissivo, consentendo inavvertitamente il routing internet completo prima che l'autenticazione sia completata. Rivedi le voci del Walled Garden per intervalli CIDR eccessivamente ampi.

Errori di Intercettazione HTTPS. I browser moderni applicano l'HTTP Strict Transport Security (HSTS). Se un utente tenta di navigare verso un dominio precaricato HSTS prima di autenticarsi, il browser bloccherà il reindirizzamento del captive portal. Implementa RFC 8908 per abilitare la scoperta nativa del captive portal, o istruisci gli utenti a navigare verso un dominio non-HSTS per attivare la CNA.

Errori degli Script di Terze Parti sulla Splash Page. Se i team di marketing hanno aggiunto pixel di tracciamento o script di analisi alla Splash Page, questi falliranno silenziosamente nell'ambiente CNA se i loro domini non sono stati inseriti nella whitelist. La soluzione corretta è rimuovere completamente questi script dalla Splash Page e ridistribuirli sulla Landing Page, dove funzioneranno correttamente.

Lacune nella conformità GDPR. Assicurarsi che il meccanismo di consenso sulla Splash Page soddisfi i requisiti dell'Articolo 7 del GDPR — il consenso deve essere liberamente dato, specifico, informato e inequivocabile. Le caselle di consenso pre-spuntate non sono conformi. Mantenere un registro di audit del consenso per un minimo di tre anni.

ROI e Impatto sul Business

Un'architettura Splash/Landing Page correttamente implementata trasforma il WiFi per gli ospiti da centro di costo a risorsa misurabile per la generazione di entrate. Il caso finanziario opera su tre dimensioni.

Acquisizione Dati e Intelligence di Prima Parte. Ottimizzando la Splash Page, le sedi aumentano i tassi di connessione e il volume di dati di prima parte acquisiti. Negli ambienti Sanità e Trasporti , questi dati supportano l'analisi operativa — modelli di affluenza, tempo di permanenza per zona e previsione della domanda di picco — consentendo decisioni sull'allocazione delle risorse con risparmi sui costi misurabili.

Attribuzione Diretta delle Entrate. La Landing Page è la superficie di conversione principale. Un'implementazione in uno stadio può utilizzare la Landing Page per promuovere l'ordinazione di cibo e bevande al posto, correlando direttamente l'accesso alla rete con le entrate transazionali. Un hotel può offrire prenotazioni spa o upgrade di camera. Un rivenditore può servire promozioni specifiche per zona guidate da dati di localizzazione in tempo reale provenienti da WiFi Analytics .

Fidelizzazione e Ritenzione. Le esperienze personalizzate della Landing Page — guidate dal profilo utente acquisito sulla Splash Page — aumentano l'engagement nei programmi fedeltà. Gli utenti di ritorno che ricevono un'esperienza di benvenuto personalizzata dimostrano una durata della sessione e una frequenza di visite ripetute significativamente più elevate rispetto agli utenti a cui viene presentata una landing page generica.

I KPI misurabili per un'implementazione WiFi per gli ospiti dovrebbero includere: tasso di connessione WiFi (obiettivo >70% dei visitatori della sede), tasso di acquisizione dati (obiettivo >85% degli utenti connessi), click-through rate della Landing Page sulla CTA principale e entrate dirette attribuite alle promozioni basate sul WiFi.

Ascolta il podcast completo del briefing tecnico qui sotto:

Termini chiave e definizioni

Captive Portal

A web-based access control mechanism that intercepts network traffic from unauthenticated clients and redirects them to an authentication interface before granting broader network access.

The overarching system IT teams deploy to manage guest access, enforce acceptable use policies, capture user consent, and collect first-party data.

Splash Page

The initial authentication interface presented within the captive portal flow, operating within the restricted Walled Garden environment before the user has been granted internet access.

Where network architects must focus on lightweight design, identity verification, and legal consent. Incorrectly overloading this page with marketing assets is the leading cause of guest WiFi connection failures.

WiFi Landing Page

The post-authentication destination page loaded in the user's full browser after the device has been granted internet access by the RADIUS server.

Where marketing and operations teams deploy rich media, personalised content, loyalty integrations, and engagement campaigns. Operates without the constraints of the Walled Garden.

Walled Garden

A restricted network environment that allows unauthenticated users to access only a specific, explicitly whitelisted set of IP addresses or hostnames, blocking all other internet traffic.

The technical boundary within which the Splash Page must operate. Every external resource used by the Splash Page must have its domain or IP range added to the Walled Garden whitelist.

Captive Network Assistant (CNA)

A specialised, sandboxed pseudo-browser built into mobile operating systems (iOS, Android, Windows) that automatically detects and renders captive portal login pages.

The primary reason Splash Pages must be lightweight and avoid complex JavaScript, external cookies, or large media assets. CNA behaviour varies between OS versions and requires ongoing regression testing.

MAC Authentication Bypass (MAB)

A network access control technique that authenticates devices based on their hardware MAC address without requiring user interaction, enabling seamless login for returning devices.

Used to provide frictionless login experiences for returning guests or registered IoT devices. Requires integration between the RADIUS server and the venue's loyalty or device registry database.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol providing centralised Authentication, Authorisation, and Accounting (AAA) management for network access, defined in RFC 2865.

The backend server infrastructure that validates credentials submitted on the Splash Page, instructs the controller to grant access, and returns user attributes used to personalise the Landing Page.

RFC 8908

The IETF standard defining the Captive Portal API, enabling devices to discover and interact with captive portals natively through DHCP options and Router Advertisements rather than relying on HTTP interception.

A modern standard that improves captive portal reliability across iOS 14+ and Android 11+, reducing CNA-related connection failures caused by HTTPS interception issues.

Change of Authorization (CoA)

A RADIUS extension (RFC 5176) that allows the RADIUS server to dynamically modify an active network session — for example, migrating a client from an unauthenticated to an authenticated VLAN after successful login.

The mechanism by which the captive portal platform instructs the wireless controller to grant internet access after the user completes authentication on the Splash Page.

Casi di studio

A 500-room hotel resort is experiencing high drop-off rates on their guest WiFi login. The marketing team recently added a 4MB promotional video and a complex interactive venue map to the initial connection screen. Connection rates have dropped from 68% to 31% since the update. How should the network architect resolve this?

The architect must decouple the authentication and marketing functions. Step 1: Replace the current connection screen with a lightweight Splash Page under 1MB, containing only the authentication form (room number and last name), a GDPR-compliant consent checkbox, and Terms and Conditions acceptance. Step 2: Remove all external script dependencies from the Splash Page and serve all assets from the captive portal platform's own CDN, which is already whitelisted in the Walled Garden. Step 3: Configure the wireless controller's post-authentication redirection to send the user to a newly created Landing Page hosted on the open internet. Step 4: Move the 4MB promotional video and interactive venue map to this Landing Page. Step 5: Instrument the Landing Page with the hotel's CRM integration to personalise the welcome message based on the authenticated user profile. Step 6: Implement MAC Authentication Bypass for returning guests to eliminate the Splash Page entirely on subsequent visits.

Note di implementazione: This approach resolves the drop-off issue by acknowledging the fundamental constraints of the Captive Network Assistant (CNA). The heavy assets were causing the CNA to time out or fail to render within the restricted Walled Garden environment. Moving them to the post-authentication Landing Page ensures they load correctly using the device's full browser capabilities over an established internet connection. The MAB implementation for returning guests further improves the experience for the hotel's most valuable repeat customers, while the CRM integration on the Landing Page creates a measurable revenue attribution pathway.

A retail chain wants to offer seamless WiFi access to returning loyalty programme members across 50 locations, bypassing the login screen while still displaying a personalised welcome offer and current loyalty points balance. What is the recommended technical architecture?

Implement MAC Authentication Bypass (MAB) integrated with the loyalty database via RADIUS. Architecture: (1) When a returning device associates with the SSID, the controller sends a RADIUS Access-Request containing the device MAC address. (2) The RADIUS server queries the loyalty database to match the MAC address to a loyalty profile. (3) If a match is found, the RADIUS server returns an Access-Accept with a vendor-specific attribute (VSA) containing a signed user token. (4) The controller grants immediate internet access and issues a redirect to the Landing Page URL, appending the signed token as a query parameter. (5) The cloud-hosted Landing Page decodes the token, queries the loyalty API for the user's current points balance and personalised offer, and renders a customised welcome experience. For new users or unrecognised devices, the standard Splash Page flow is presented, with an option to link the device to their loyalty account for future seamless access.

Note di implementazione: This solution correctly utilises MAB for network access control while leveraging the Landing Page for the marketing requirement. The signed token approach prevents URL manipulation and ensures the personalised content is served only to the authenticated user. The fallback to the standard Splash Page for unrecognised devices ensures that new customer acquisition is not compromised. This architecture demonstrates a mature understanding of decoupled captive portal design and is directly applicable to enterprise retail deployments across distributed venue estates.

Analisi degli scenari

Q1. A public sector organisation requires all guest WiFi users to accept a lengthy Acceptable Use Policy (AUP) before accessing the internet. The communications team also wants to display a dynamic feed of upcoming community events and a live social media wall. How should you architect this requirement across the captive portal flow?

💡 Suggerimento:Consider the constraints of the Captive Network Assistant (CNA) and the Walled Garden when deciding where to place each content element.

Mostra l'approccio consigliato

Place the Acceptable Use Policy (AUP) on the Splash Page to ensure legal compliance before authentication. The AUP should be presented as inline text or a scrollable div — not loaded from an external URL — to avoid Walled Garden dependencies. Once the user accepts the AUP and is authenticated, redirect them to the Landing Page to display the dynamic community events feed and social media wall. The social media wall in particular requires external API calls that cannot function within the Walled Garden, making the Landing Page the only viable location.

Q2. During a new deployment at a conference centre, users report that the login screen appears correctly but when they click 'Sign in with LinkedIn', the page times out and returns an error. The controller configuration and RADIUS server are both functioning correctly for email/password authentication. What is the most likely cause and resolution?

💡 Suggerimento:Think about what network access is required for a third-party OAuth identity provider to complete its authorisation flow during the pre-authentication phase.

Mostra l'approccio consigliato

The Walled Garden configuration is incomplete. LinkedIn's OAuth flow requires the client device to communicate with LinkedIn's authorisation servers (e.g., www.linkedin.com, api.linkedin.com) during the pre-authentication phase. These domains are not whitelisted, so the OAuth redirect fails. The resolution is to identify all IP ranges and hostnames used by LinkedIn's OAuth API and add them to the Walled Garden whitelist on the wireless controller. Note that LinkedIn (and other major identity providers) may use multiple CDN-hosted domains — review the OAuth documentation or use a packet capture to identify all required endpoints.

Q3. A retail client wants to track user behaviour on the initial WiFi login screen using Google Analytics 4 and a custom retargeting pixel from their advertising platform. The marketing team has provided a tag manager snippet to be added to the Splash Page. Why is this technically problematic, and what is the recommended alternative that preserves the marketing team's measurement requirements?

💡 Suggerimento:Evaluate the capabilities of the CNA mini-browser and the implications of adding external script domains to the Walled Garden.

Mostra l'approccio consigliato

This is problematic for two reasons. First, the CNA often blocks cookies and restricts JavaScript execution, rendering client-side tracking scripts ineffective or unreliable. Second, Google Tag Manager and advertising pixels load scripts from multiple external domains — adding all of these to the Walled Garden creates significant security exposure and ongoing maintenance overhead. The recommended alternative is a two-part approach: (1) Capture the authentication event server-side via the captive portal platform's API or RADIUS accounting logs, and push this event to Google Analytics 4 using the Measurement Protocol (server-side), which does not require client-side JavaScript. (2) Deploy the full Google Tag Manager container and retargeting pixel on the post-authentication Landing Page, where the full browser environment ensures reliable script execution and cookie-based tracking functions normally.