WiFi Landing Page vs. Splash Page : Quelle est la différence ?

Ce guide de référence technique clarifie les différences architecturales et fonctionnelles entre les pages d'atterrissage WiFi et les pages de démarrage — deux termes fréquemment confondus par les équipes informatiques et les départements marketing. Il fournit aux architectes réseau, aux responsables informatiques et aux directeurs des opérations de site des stratégies de déploiement concrètes pour optimiser les performances du Captive Portal, assurer la conformité au GDPR et au PCI DSS, et maximiser le retour sur investissement (ROI) dans les environnements d'entreprise, y compris l'hôtellerie, le commerce de détail et le secteur public.

📖 8 min de lecture📝 1,923 mots🔧 2 exemples❓ 3 questions📚 9 termes clés

🎧 Écouter ce guide

Voir la transcription

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.

Points clés à retenir

✓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.

Résumé Exécutif

Pour les équipes informatiques d'entreprise gérant des sites à forte densité — des propriétés Hôtellerie aux domaines du Commerce de détail — les termes "splash page" et "landing page" sont fréquemment confondus. Les traiter comme interchangeables dans l'architecture réseau conduit à des parcours utilisateur interrompus, des vulnérabilités de sécurité et des opportunités de capture de données manquées.

À un niveau fondamental, la Splash Page est le gardien de la pré-authentification. Elle existe dans l'environnement contraint d'un Jardin Muré (Walled Garden), responsable de la vérification d'identité, de l'authentification MAC et du consentement légal sous GDPR et PCI DSS. La WiFi Landing Page est la destination post-authentification. Elle fonctionne sur l'internet ouvert, exploitant les données capturées lors de la connexion pour offrir des expériences personnalisées, stimuler les téléchargements d'applications et générer un ROI mesurable grâce aux intégrations WiFi Invité .

Ce guide détaille les spécifications techniques, les méthodologies de déploiement et les modes de défaillance courants associés à la conception de Captive Portal — permettant aux architectes réseau de construire des réseaux d'accès invité robustes, conformes et générateurs de revenus pour tout type de site.

Approfondissement Technique

L'Architecture du Captive Portal

Un Captive Portal intercepte le trafic HTTP/HTTPS des clients non authentifiés et les redirige vers une interface web désignée. Ce mécanisme repose sur une combinaison de détournement DNS, de redirection HTTP 302 et d'authentification RADIUS — les implémentations modernes adoptant de plus en plus le RFC 8908 (Captive Portal Identification in DHCP and Router Advertisements) pour permettre la découverte native du Captive Portal au niveau de l'OS sans interception HTTP fragile.

Dans cette architecture, la Splash Page et la Landing Page jouent des rôles fondamentalement différents à différents moments du cycle de vie de l'authentification.

1. La Splash Page (État de Pré-authentification)

Lorsqu'un appareil s'associe à un SSID, le contrôleur sans fil le place dans un VLAN non authentifié. Tout le trafic sortant est intercepté et redirigé vers le nom d'hôte du Captive Portal. L'Assistant de Réseau Captif (CNA) du système d'exploitation — un pseudo-navigateur spécialisé et isolé intégré à iOS, Android et Windows — détecte le Captive Portal et affiche la Splash Page.

Contraintes Techniques de l'Environnement CNA :

Le CNA n'est pas un navigateur complet. Il fonctionne avec des restrictions importantes qui impactent directement ce qui peut être déployé sur une Splash Page :

Les cookies et le stockage local sont souvent bloqués ou sévèrement limités
Les frameworks JavaScript complexes peuvent échouer à s'exécuter
Les ressources externes (polices, scripts, images) ne peuvent se charger que si leurs domaines sont mis sur liste blanche dans le Jardin Muré (Walled Garden)
Le CNA se fermera automatiquement s'il détecte que l'appareil a obtenu un accès internet avant que l'utilisateur n'ait terminé l'authentification
La persistance de session après la fermeture du CNA est peu fiable

Fonctions Principales de la Splash Page :

Compte tenu de ces contraintes, la Splash Page doit être conçue exclusivement pour : l'authentification (connexion sociale via OAuth, SMS OTP, identifiants basés sur formulaire ou intégration de programme de fidélité) ; l'acceptation des Conditions Générales ; la capture du consentement GDPR ; et l'enregistrement de l'adresse MAC pour une future connexion transparente.

Recommandation de Charge Utile : Gardez la Splash Page en dessous de 1 Mo. Utilisez du CSS en ligne, évitez les bibliothèques de polices externes et minimisez le JavaScript. Chaque dépendance externe nécessite une entrée de liste blanche correspondante dans le Jardin Muré (Walled Garden) — chacune représentant à la fois une charge de maintenance et une exposition potentielle à la sécurité.

2. La Landing Page (État Post-authentification)

Après une authentification réussie, le serveur RADIUS renvoie un message Access-Accept. Le contrôleur sans fil met à jour la session du client, migrant l'appareil vers un VLAN authentifié avec un routage internet complet. Le Jardin Muré (Walled Garden) est abandonné. Le contrôleur — ou la plateforme de Captive Portal basée sur le cloud — émet une redirection HTTP 302 vers la WiFi Landing Page.

À ce stade, l'appareil fonctionne avec un navigateur complet et un accès internet illimité. La Landing Page peut exploiter l'ensemble complet des capacités du développement web moderne :

Contenu dynamique et personnalisé, basé sur le profil utilisateur capturé sur la Splash Page
Instrumentation analytique complète (Google Analytics, pixels de suivi personnalisés, webhooks CRM)
Médias riches incluant vidéo, cartes interactives et tableaux de bord de fidélité
Invitations au téléchargement d'applications avec routage par lien profond
Promotions ciblées basées sur les données WiFi Analytics , incluant la fréquence de visite, le temps de présence et la zone du site

Fonctions Principales de la Landing Page : Engagement marketing, affichage du programme de fidélité, promotions ciblées, navigation sur le site et appels à l'action axés sur la conversion.

Flux d'Authentification : De bout en bout

La séquence ci-dessous illustre le flux complet, de l'association SSID à la livraison de la Landing Page :

L'appareil client s'associe au SSID invité
Le contrôleur attribue l'appareil à un VLAN non authentifié
Le client tente une requête HTTP ; le contrôleur intercepte et émet une redirection 302 vers la Splash Page
Le CNA charge la Splash Page (ressources servies uniquement depuis les domaines mis sur liste blanche du Jardin Muré (Walled Garden))
L'utilisateur termine l'authentification et accepte les Conditions Générales
La plateforme de Captive Portal envoie une requête Access-Request au serveur RADIUS
Le RADIUS renvoie un Access-Accept ; le contrôleur reçoit un message de Changement d'Autorisation (CoA)
Le contrôleur migre le client vers le VLAN authentifié
La plateforme de Captive Portal émet une redirection 302 vers la WiFi Landing Page
Le navigateur client charge la Landing Page complète via l'internet ouvert

Cette séparation claire des préoccupations — l'authentification surla Splash Page, l'engagement sur la Landing Page — est le fondement architectural de tout déploiement WiFi invité bien conçu.

Guide d'implémentation

Le déploiement d'une solution WiFi invité évolutive de niveau entreprise nécessite de séparer le plan de contrôle du réseau de la couche d'expérience utilisateur. Les étapes suivantes fournissent un cadre de déploiement indépendant du fournisseur, applicable aux infrastructures Cisco Meraki, Aruba, Ruckus et Ubiquiti.

Étape 1 : Configuration du Walled Garden

Configurez votre contrôleur de réseau local sans fil (WLC) pour n'autoriser que les domaines et les plages d'adresses IP strictement nécessaires au fonctionnement de la Splash Page. Cela inclut généralement :

Le nom d'hôte de la plateforme Captive Portal (par exemple, portal.purple.ai)
Domaines des fournisseurs d'identité pour la connexion sociale (par exemple, accounts.google.com, graph.facebook.com)
Domaines de passerelle SMS si l'authentification OTP est utilisée
Tous les actifs CDN utilisés par la Splash Page elle-même

Évitez le sur-listage blanc. Chaque entrée supplémentaire augmente la surface d'attaque de votre réseau de pré-authentification et complique la maintenance continue à mesure que les plages d'adresses IP changent.

Étape 2 : Gestion des certificats SSL

Configurez le WLC avec un certificat SSL valide et publiquement approuvé pour le nom d'hôte de redirection du Captive Portal. Les certificats auto-signés déclencheront des avertissements de sécurité du navigateur dans le CNA, ce qui incitera les utilisateurs à abandonner le processus de connexion. L'expiration des certificats est une cause majeure de pannes du WiFi invité — mettez en œuvre un renouvellement automatisé via Let's Encrypt ou votre plateforme de gestion des certificats.

Étape 3 : Optimisation du CNA

Concevez la Splash Page spécifiquement pour l'environnement CNA. Utilisez du CSS en ligne, évitez les frameworks JavaScript externes et testez sur plusieurs versions iOS et Android. Le comportement du CNA iOS en particulier change entre les versions majeures du système d'exploitation — maintenez une matrice de tests de régression couvrant au moins les deux versions majeures les plus récentes des deux plateformes.

Étape 4 : Logique de redirection post-authentification

Configurez la redirection post-authentification pour prendre en charge les URL dynamiques de Landing Page. Le serveur RADIUS peut renvoyer des attributs spécifiques au fournisseur (VSA) ou la plateforme Captive Portal peut utiliser le profil utilisateur authentifié pour construire une URL personnalisée. Cela permet la segmentation — un visiteur pour la première fois reçoit une offre de bienvenue, tandis qu'un membre de fidélité avec le statut Gold reçoit un tableau de bord personnalisé.

Étape 5 : Intégration des analyses

Instrumentez la Landing Page avec votre pile d'analyse. Étant donné que l'utilisateur est maintenant sur l'internet ouvert avec un navigateur complet, les outils d'analyse standard fonctionnent normalement. Intégrez-vous à votre CRM pour créer un profil client unifié qui combine les données de session WiFi avec l'historique des achats, le statut de fidélité et les métriques d'engagement marketing.

Pour une comparaison détaillée des architectures de Captive Portal basées sur le cloud par rapport aux architectures sur site, consultez Captive Portal basé sur le cloud ou sur site : lequel convient à votre entreprise ? .

Bonnes pratiques

Dissociez l'authentification et le marketing. La décision architecturale la plus impactante est d'utiliser la Splash Page strictement pour l'accès sécurisé et le consentement, et de déplacer tous les actifs marketing vers la Landing Page. Cela améliore les taux de connexion, réduit les tickets de support et simplifie les audits de conformité.

Tirez parti du contournement d'authentification MAC pour les utilisateurs récurrents. Pour les appareils récurrents, le contournement d'authentification MAC (MAB) élimine entièrement la Splash Page, redirigeant les utilisateurs directement vers une Landing Page personnalisée. Cela améliore considérablement l'expérience utilisateur pour les visiteurs réguliers dans les environnements Hôtellerie et Commerce de détail . Assurez-vous que votre politique de confidentialité couvre explicitement le suivi persistant des appareils.

Adoptez des architectures centrées sur le cloud. Tout comme l'industrie des réseaux s'est orientée vers le WAN défini par logiciel pour une gestion centralisée — comme détaillé dans Les avantages clés du SD WAN pour les entreprises modernes — les plateformes de Captive Portal devraient être hébergées dans le cloud. Cela permet une gestion centralisée des sites distribués, des mises à jour de contenu rapides sans modifications du micrologiciel du contrôleur, et une intégration transparente avec les CRM externes et les plateformes d'automatisation marketing.

Implémentez la RFC 8908 pour la compatibilité avec les systèmes d'exploitation modernes. La détection native du Captive Portal via la RFC 8908 réduit la dépendance à l'interception HTTP, améliorant la fiabilité sur les versions modernes d'iOS et Android qui imposent de plus en plus la navigation HTTPS uniquement.

Maintenez un calendrier d'audit du Walled Garden. Examinez les entrées du Walled Garden trimestriellement. Les plages d'adresses IP des principaux fournisseurs d'identité changent sans préavis. Les entrées obsolètes qui ne se résolvent plus créent des échecs d'authentification ; les entrées manquantes bloquent les flux d'authentification légitimes.

Dépannage et atténuation des risques

La boucle de connexion. Si un utilisateur s'authentifie mais est redirigé à plusieurs reprises vers la Splash Page, vérifiez que le message RADIUS Access-Accept atteint le contrôleur et que le client reçoit avec succès un bail DHCP sur le VLAN authentifié. Vérifiez également que le port CoA (Change of Authorization) (UDP 3799) n'est pas bloqué par un pare-feu intermédiaire.

Fermeture prématurée du CNA. Si le CNA se ferme avant que l'utilisateur ne puisse s'authentifier, l'appareil a probablement détecté un accès internet prématurément. Cela peut se produire si le Walled Garden est trop permissif, autorisant par inadvertance un routage internet complet avant que l'authentification ne soit terminée. Examinez les entrées du Walled Garden pour des plages CIDR trop larges.

Erreurs d'interception HTTPS. Les navigateurs modernes appliquent le HTTP Strict Transport Security (HSTS). Si un utilisateur tente de naviguer vers un domaine préchargé HSTS avant de s'authentifier, le navigateur bloquera la redirection du Captive Portal. Implémentez la RFC 8908 pour activer la découverte native du Captive Portal, ou demandez aux utilisateurs de naviguer vers un domaine non-HSTS pour déclencher le CNA.

Échecs de scripts tiers sur la Splash Page. Si les équipes marketing ont ajouté des pixels de suivi ou des scripts d'analyse à la Splash Page, ceux-ci échoueront silencieusement dans l'environnement CNA si leurs domaines ne sont pas mis sur liste blanche. La solution correcte consiste à supprimer entièrement ces scripts de la Splash Page et à les redéployer sur la Landing Page, où ils fonctionneront correctement.

Lacunes de conformité GDPR. Assurez-vous que le mécanisme de consentement sur la Splash Page respecte les exigences de l'Article 7 du GDPR — le consentement doit être donné librement, spécifique, éclairé et univoque. Les cases de consentement pré-cochées ne sont pas conformes. Maintenez un journal d'audit des consentements pendant au moins trois ans.

ROI et Impact Commercial

Une architecture Splash/Landing Page correctement implémentée transforme le WiFi invité d'un centre de coûts en un actif générateur de revenus mesurable. Le cas financier s'articule autour de trois dimensions.

Capture de Données et Intelligence de Première Partie. En rationalisant la Splash Page, les établissements augmentent les taux de connexion et le volume de données de première partie capturées. Dans les environnements Santé et Transport , ces données soutiennent l'analyse opérationnelle — schémas de fréquentation, temps de séjour par zone et prévisions de demande de pointe — permettant des décisions d'allocation de ressources avec des économies mesurables.

Attribution Directe des Revenus. La Landing Page est la surface de conversion principale. Un déploiement en stade peut utiliser la Landing Page pour promouvoir la commande de nourriture et de boissons à la place, corrélant directement l'accès au réseau avec les revenus transactionnels. Un hôtel peut proposer des réservations de spa ou des surclassements de chambre. Un détaillant peut diffuser des promotions spécifiques à une zone, basées sur des données de localisation en temps réel provenant de WiFi Analytics .

Fidélisation et Rétention. Les expériences personnalisées de Landing Page — basées sur le profil utilisateur capturé sur la Splash Page — augmentent l'engagement envers le programme de fidélité. Les utilisateurs récurrents qui reçoivent une expérience d'accueil personnalisée démontrent une durée de session et une fréquence de visites répétées significativement plus élevées par rapport aux utilisateurs confrontés à une landing page générique.

Les KPI mesurables pour un déploiement WiFi invité devraient inclure : le taux de connexion WiFi (cible >70% des visiteurs du site), le taux de capture de données (cible >85% des utilisateurs connectés), le taux de clics sur le CTA principal de la Landing Page, et les revenus directs attribués aux promotions basées sur le WiFi.

Écoutez le podcast complet du briefing technique ci-dessous :

Termes clés et définitions

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.

Études de cas

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.

Notes de mise en œuvre : 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.

Notes de mise en œuvre : 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.

Analyse de scénario

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?

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

Afficher l'approche recommandée

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?

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

Afficher l'approche recommandée

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?

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

Afficher l'approche recommandée

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.