Passer au contenu principal
Français

Captive Portal vs Splash Page

Ce guide de référence détaille la distinction cruciale entre les captive portals et les splash pages au sein des réseaux WiFi invités. Il explique comment le mécanisme d'interception réseau sous-jacent fonctionne en synergie avec l'interface visuelle destinée aux invités, aidant ainsi les responsables informatiques et les exploitants de sites à prendre des décisions d'architecture et d'achat éclairées.

📖 8 min de lecture📝 1,872 mots🔧 3 exemples concrets❓ 3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du 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: Le guide ultime des Captive Portals →

header_image.png

Résumé analytique

Pour les responsables informatiques, les architectes réseau et les directeurs d'exploitation de sites, le WiFi invités n'est plus un simple service de confort ; c'est un point de contact critique pour la collecte de données de première partie (first-party), l'engagement marketing et la sécurité réseau. Cependant, la confusion entre captive portals et splash pages reste une source d'ambiguïté récurrente dans les appels d'offres et les discussions de déploiement.

Ce guide clarifie cette distinction fondamentale. Un captive portal est un mécanisme de contrôle au niveau de la couche réseau qui intercepte le trafic, bloque l'accès à Internet et gère l'authentification sécurisée. Une splash page est l'interface visuelle au niveau de la couche applicative — la page web que les invités voient, avec laquelle ils interagissent et qu'ils utilisent pour s'authentifier.

Confondre ces deux composants entraîne des risques importants lors de l'achat et de l'implémentation, comme l'acquisition d'une splash page au design soigné mais dotée de contrôles backend non sécurisés, ou le déploiement d'un captive portal hautement sécurisé mais doté d'une interface utilisateur obsolète et sans image de marque, ce qui décourage l'adoption par les invités. En comprenant comment ces technologies fonctionnent ensemble, les entreprises peuvent s'appuyer sur des plateformes comme Purple pour offrir une expérience WiFi invités sécurisée, conforme et hautement engageante, génératrice de valeur commerciale mesurable.

comparison_chart.png

Analyse technique approfondie

Le Captive Portal : interception du trafic au niveau de la couche réseau

Le captive portal opère au niveau des couches inférieures du modèle OSI (généralement la couche 2 et la couche 3) pour appliquer le contrôle d'accès. Lorsqu'un appareil invité se connecte à un SSID ouvert, le serveur DHCP local lui attribue une adresse IP, un masque de sous-réseau et une passerelle par défaut. Cependant, le point d'accès sans fil (AP) ou le contrôleur de passerelle place l'adresse MAC de l'appareil dans un état non authentifié au sein de la table de session du pare-feu.

Dans cet état, le pare-feu bloque tout le trafic IP sortant, à l'exception des services réseau essentiels tels que le DNS et le DHCP. Lorsque l'invité tente d'accéder à un site web externe, le captive portal intercepte le trafic en utilisant l'une des deux méthodes principales suivantes :

  1. Redirection HTTP (redirection 302) : la passerelle intercepte la requête HTTP initiale et renvoie une réponse HTTP 302 Found, redirigeant le navigateur du client vers l'URL de la splash page.
  2. Détournement DNS (DNS Hijacking) : la passerelle intercepte les requêtes DNS et résout tous les noms de domaine vers l'adresse IP du serveur local de la splash page. Bien que simple, cette méthode est de plus en plus obsolète en raison de DNSSEC et des avertissements de sécurité au niveau du navigateur.

Les systèmes d'exploitation mobiles modernes utilisent un démon intégré appelé Captive Network Assistant (CNA). Lors de la connexion à un réseau, le CNA tente de joindre un point de terminaison HTTP non chiffré connu (par exemple, captive.apple.com d'Apple ou connectivitycheck.gstatic.com de Google). Si la réponse est interceptée et redirigée, le système d'exploitation reconnaît qu'il se trouve derrière un captive portal et affiche automatiquement la splash page dans une fenêtre de navigateur système dédiée, évitant ainsi à l'utilisateur d'avoir à ouvrir manuellement un navigateur web.

Une fois que l'utilisateur a terminé le processus d'authentification sur la splash page, le serveur d'authentification (généralement un serveur RADIUS) envoie un paquet Access-Accept au contrôleur réseau. Le contrôleur met ensuite à jour ses règles de pare-feu pour accorder à l'adresse MAC de l'appareil un accès complet à Internet, en utilisant souvent le MAC Address Bypass (MAB) pour mémoriser l'appareil pendant une durée de session définie.

La Splash Page : l'expérience utilisateur au niveau de la couche applicative

Contrairement au captive portal, la splash page est une application web standard fonctionnant au niveau de la couche 7 (la couche applicative). Elle est construite à l'aide de technologies web standards (HTML, CSS et JavaScript) et est hébergée soit localement sur le contrôleur de passerelle, soit, plus fréquemment, sur une plateforme cloud comme Purple.

La splash page sert d'interface visuelle et de point de contact avec la marque pour l'invité. Ses principales fonctions techniques comprennent :

  • Fédération d'identité : faciliter les connexions via les réseaux sociaux (Google, Facebook, Apple) à l'aide des protocoles OAuth 2.0.
  • Collecte de données : recueillir les informations des invités telles que les adresses e-mail, les noms et les numéros de programme de fidélité.
  • Gestion du consentement : recueillir les consentements explicites (opt-ins) pour le marketing et l'acceptation des conditions d'utilisation et des politiques de confidentialité, garantissant ainsi la conformité avec des réglementations telles que le règlement général sur la protection des données (GDPR) [1] et le California Consumer Privacy Act (CCPA).
  • Diffusion publicitaire et image de marque : diffuser des bannières promotionnelles ciblées, des publicités vidéo ou des pages de redirection post-connexion pour monétiser l'espace physique.

La splash page étant une application web, elle doit être hautement réactive (responsive) et optimisée pour les appareils mobiles, qui représentent plus de 80 % des connexions WiFi invités.

architecture_overview.png

Guide d'implémentation

Le déploiement d'une solution WiFi invités de classe entreprise nécessite une coordination rigoureuse entre l'infrastructure réseau et les logiciels basés sur le cloud. Vous trouverez ci-dessous un guide d'architecture neutre vis-à-vis des fournisseurs pour implémenter un système de captive portal et de splash page.

Architecture de déploiement étape par étape

  1. Segmentation réseau : configurez un VLAN invité dédié sur vos commutateurs et points d'accès afin d'isoler le trafic invité des réseaux d'entreprise internes, des terminaux de point de vente (POS) et des appareils IoT. Il s'agit d'une exigence essentielle pour la conformité PCI DSS [2].
  2. Configuration du SSID : configurez un SSID ouvert avec le chiffrement OWE (Opportunistic Wireless Encryption) s'il est pris en charge par votre matériel, ou un SSID ouvert standard. Activez la redirection vers le captive portal sur le profil SSID au sein de votre contrôleur sans fil (par exemple, Cisco Catalyst, Aruba Instant On ou Ruckus SmartZone).
  3. Configuration du Walled Garden (ACL) : Avane l'authentification, l'appareil de l'invité doit être autorisé à accéder à certains domaines externes pour afficher correctement la splash page. C'est ce que l'on appelle le « Walled Garden » ou la liste de contrôle d'accès (ACL). Vous devez inclure :
    • Le domaine de votre splash page hébergée dans le cloud (par ex., *.purple.ai).
    • Les points de terminaison OAuth pour les fournisseurs de connexion sociale (par ex., *.facebook.com, *.google.com, *.apple.com).
    • Les réseaux de diffusion de contenu (CDN) hébergeant les ressources requises (polices, feuilles de style, images).
  4. Intégration du serveur RADIUS : Configurez le contrôleur sans fil pour utiliser un serveur RADIUS externe (tel que le RADIUS cloud de Purple) pour l'authentification et la comptabilisation (802.1X / AAA) [3].
  5. Personnalisation de la splash page : Concevez la splash page au sein du portail Purple, en veillant à la cohérence de la marque, à l'adaptabilité mobile et à la clarté des cases à cocher de consentement légal.
  6. Politiques de session et de bande passante : Définissez les délais d'expiration de session (par ex., 8 heures), d'inactivité (par ex., 30 minutes) et les limites de bande passante par utilisateur (par ex., 5 Mbps en descente, 2 Mbps en montée) sur le contrôleur réseau afin d'éviter les abus et de garantir un accès équitable pour tous les invités.
Paramètre technique Captive Portal (Passerelle réseau) Splash Page (Application cloud)
Couche OSI Couche 2 / Couche 3 (Réseau/Liaison de données) Couche 7 (Application)
Protocole principal RADIUS, DHCP, HTTP (redirection 302) HTTP, HTTPS, HTML5, CSS3, OAuth 2.0
Fonction principale Interception du trafic, contrôle d'accès, limitation de la bande passante Interface utilisateur, collecte de données, consentement, image de marque
Visibilité utilisateur Complètement invisible (mécanisme backend) 100 % visible (l'écran d'accueil visuel)
Normes de sécurité IEEE 802.1X, WPA3, OWE, PCI DSS HTTPS, SSL/TLS, GDPR, CCPA
Matériel typique Points d'accès sans fil, routeurs passerelles, contrôleurs Serveurs cloud, CDN

Bonnes pratiques

Pour garantir un réseau WiFi invité performant, sécurisé et conforme à la législation, les équipes informatiques doivent respecter les bonnes pratiques sectorielles suivantes :

1. Imposer le protocole HTTPS et les certificats SSL/TLS

Tout le trafic entre l'appareil de l'invité et la splash page doit être chiffré via HTTPS. L'exécution d'une splash page sur un protocole HTTP non chiffré expose les données des invités (y compris les identifiants de connexion et les adresses e-mail) à l'interception de paquets et aux attaques de l'homme du milieu (man-in-the-middle). Assurez-vous que le domaine de votre splash page dispose d'un certificat SSL/TLS valide et publiquement approuvé. Les certificats auto-signés déclencheront de graves avertissements du navigateur, incitant les invités à abandonner la connexion.

2. Mettre en œuvre la segmentation du réseau

Ne routez jamais le trafic WiFi invité via le même VLAN ou sous-réseau que les ressources de l'entreprise. Le trafic invité doit être isolé dans un VLAN « réservé aux invités » avec des règles de pare-feu strictes empêchant tout routage inter-VLAN vers les sous-réseaux internes. Cela limite le risque de propagation de logiciels malveillants et d'accès non autorisé aux données sensibles de l'entreprise.

3. Assurer la conformité GDPR et CCPA

Si votre établissement est situé au Royaume-Uni, dans l'UE ou en Californie, ou s'il dessert des citoyens de ces régions, votre splash page doit être conforme aux lois strictes sur la confidentialité des données :

  • Consentement librement donné : Les cases à cocher d'inscription marketing (opt-in) doivent être décochées par défaut. L'accès à Internet ne peut pas être conditionné au consentement à recevoir des communications marketing.
  • Politique de confidentialité claire : Fournissez un lien direct et facilement accessible vers votre politique de confidentialité sur la splash page.
  • Droit à l'effacement : Assurez-vous que votre plateforme WiFi invité (comme Purple) prend en charge des flux de travail automatisés permettant aux invités de demander la suppression de leurs données personnelles.

4. Optimiser pour les appareils mobiles et les CNA

Veillez à ce que la splash page soit légère et hautement adaptative. Évitez les arrière-plans vidéo lourds ou les grandes images non compressées qui ralentissent le temps de chargement des pages, en particulier dans les environnements à forte densité d'utilisateurs (par ex., les stades ou les centres de conférence). Testez la splash page sur différents systèmes d'exploitation mobiles pour garantir un affichage fluide dans le navigateur natif Captive Network Assistant (CNA).

Dépannage et atténuation des risques

Dysfonctionnements courants et stratégies d'atténuation

  • La fenêtre contextuelle CNA ne s'affiche pas : Si la redirection du Captive Portal ne parvient pas à déclencher le CNA de l'appareil, les invités peuvent rester connectés au SSID sans accès à Internet et sans moyen évident de se connecter.
    • Atténuation : Assurez-vous que le serveur DNS attribué aux invités via DHCP est entièrement fonctionnel et peut résoudre les domaines externes. Si la résolution DNS échoue, le CNA ne peut pas effectuer sa vérification de connectivité et la redirection ne se déclenchera jamais.
  • Mauvaise configuration du Walled Garden : Les invités ne parviennent pas à finaliser leur connexion via les réseaux sociaux car la page de connexion OAuth ne se charge pas ou affiche une erreur de connexion.
    • Atténuation : Vérifiez à deux reprises l'ACL Walled Garden de votre passerelle. Les fournisseurs de connexion sociale modifient fréquemment leurs plages d'adresses IP et leurs domaines. L'utilisation d'une plateforme WiFi invité gérée dans le cloud comme Purple garantit que les domaines du Walled Garden sont automatiquement mis à jour et synchronisés avec votre matériel.
  • Restrictions du navigateur CNA : Le navigateur CNA natif sur les appareils mobiles a des capacités limitées par rapport aux navigateurs standards (par ex., Safari ou Chrome). Il peut bloquer les cookies, les fenêtres contextuelles ou les redirections externes.
    • Atténuation : Évitez le JavaScript complexe ou les intégrations tierces sur la splash page qui nécessitent la persistance des cookies ou des fenêtres contextuelles du navigateur. Maintenez le flux d'authentification aussi simple et direct que possible.

ROI et impact commercial

Comprendre la distinction entre les Captive Portals et les splash pages permet aux organisations de maximiser leur retour sur investissement (ROI) en optimisant à la fois les performances techniques et l'utilité commerciale de leur réseau WiFi invité.

Valeur commerciale d'une solution doublement optimisée

  • Engagement accru des invités : Une splash page conçue de manière professionnelle, alignée sur les produits phares de Purple tels que Guest WiFi et WiFi Analytics [4] [5], peut augmenter les taux de connexion des visiteurs jusqu'à 40 % par rapport aux écrans d'accueil génériques et sans marque.
  • Collecte enrichie de données First-Party : En proposant une connexion sociale fluide et des champs de formulaire structurés, les établissements de secteurs tels que le Commerce de détail , l' Hôtellerie-Restauration , la Santé et les Transports peuvent collecter des adresses e-mail propres et vérifiées, des données démographiques ainsi que la fréquence des visites.
  • Opportunités de monétisation : L'exploitation de la splash page pour la monétisation retail media permet aux établissements de diffuser des publicités ciblées aux visiteurs au moment de la connexion, tirant ainsi parti d'un marché de la publicité numérique en forte croissance.
  • Efficacité opérationnelle : Un Captive Portal robuste réduit les tickets d'assistance informatique en automatisant l'enregistrement des appareils, en gérant les expirations de session et en appliquant des limites de bande passante pour éviter la congestion du réseau.

En déployant la solution de classe entreprise de Purple, les établissements peuvent s'assurer que leur architecture réseau est sécurisée et conforme, tout en offrant à leurs équipes marketing la liberté créative de concevoir des splash pages attrayantes et à fort taux de conversion qui stimulent la fidélité des clients et les revenus.

Références

Définitions clés

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.

Exemples concrets

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.
Commentaire de l'examinateur : 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.
Commentaire de l'examinateur : 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.
Commentaire de l'examinateur : 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.

Questions d'entraînement

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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.

Continuer la lecture de cette série

Comment configurer un hotspot WiFi pour votre entreprise

Ce guide faisant autorité fournit aux responsables informatiques, aux architectes réseau et aux directeurs des opérations de sites un plan pratique et neutre vis-à-vis des fournisseurs pour le déploiement de hotspots WiFi invités sécurisés, conformes et améliorant l'activité. Il couvre les décisions architecturales critiques – de la segmentation VLAN et la configuration du Captive Portal à la conformité GDPR et la gestion du trafic – et démontre comment transformer l'infrastructure réseau d'un centre de coûts en une plateforme d'analyse génératrice de revenus en utilisant les capacités de Guest WiFi et d'analyse de Purple.

Lire le guide →

Purple vs Cisco Spaces (DNA Spaces) : Quand choisir l'un ou l'autre

Ce guide de référence technique offre une comparaison complète de Purple et Cisco Spaces (anciennement DNA Spaces) pour les déploiements de portails captifs d'entreprise et de WiFi invité. Il évalue les différences architecturales, la profondeur de l'automatisation marketing et la question cruciale du verrouillage par le fournisseur de matériel afin d'aider les responsables informatiques à prendre des décisions éclairées en matière d'infrastructure.

Lire le guide →

Purple vs GlobalReach Technology : Comparaison du WiFi de qualité opérateur

Ce guide offre une comparaison technique faisant autorité entre Purple et GlobalReach Technology, couvrant les capacités de captive portal, la préparation à WBA OpenRoaming, l'architecture de déchargement opérateur et les modèles commerciaux. Il est destiné aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de magasins, de stades et de municipalités qui doivent prendre une décision concernant une plateforme ce trimestre. La conclusion principale est que, bien que GlobalReach soit leader en matière de déchargement opérateur MNO approfondi et d'élaboration de normes, Purple perturbe le marché avec une surcouche indépendante du matériel et un niveau de fournisseur d'identité OpenRoaming véritablement gratuit, rendant le WiFi de qualité opérateur accessible à tout site sans coûts de licence logicielle initiaux.

Lire le guide →