Connexion au Captive Portal : Dépannage et explications
Ce guide fournit une référence technique complète pour comprendre, déployer et dépanner les systèmes de connexion par Captive Portal dans les environnements WiFi invités d'entreprise. Il explique les mécanismes exacts de redirection HTTP et de détournement DNS utilisés par les Captive Portals modernes, détaille comment HSTS et les navigateurs HTTPS sécurisés peuvent bloquer les redirections locales, et propose une liste de contrôle de dépannage claire et exploitable couvrant à la fois les correctifs côté client (désactivation des VPN, désactivation de la randomisation MAC, utilisation de NeverSSL) et les résolutions côté opérateur (configuration du walled garden, optimisation du temps de bail DHCP, vérification de l'interception DNS). Les exploitants de sites, les responsables informatiques et les architectes réseau trouveront ce guide indispensable pour minimiser les tickets d'assistance des invités et maximiser le ROI de leur infrastructure sans fil.
Écouter ce guide
Voir la transcription du podcast
📚 Fait partie de notre série principale : Le guide ultime des Captive Portals →
Executive Summary
For modern enterprise venues, guest wireless networks are no longer a simple amenity; they represent a critical touchpoint for customer engagement, operational intelligence, and brand positioning. However, the business value of these networks depends entirely on the reliability of the initial connection experience. When a guest connects to a network and the captive portal login page fails to appear, the venue immediately suffers from increased front-of-house friction, a surge in support tickets, and lost opportunities for data capture.
At the core of these failures is a fundamental tension between secure web standards and the network-level interception techniques historically used by captive portals. Modern web browsers and operating systems are designed to detect and block unauthorized traffic redirection to protect users from man-in-the-middle (MitM) attacks. By understanding the precise HTTP and DNS redirection sequences, the impact of secure protocols like HTTP Strict Transport Security (HSTS), and the client-side settings that disrupt these mechanisms, IT organizations can implement robust configurations that ensure seamless onboarding.
This guide details how Purple's cloud-managed Guest WiFi platform addresses these challenges to deliver high-availability redirection across all consumer operating systems, minimizing venue support overhead and maximizing the return on wireless infrastructure investments. Whether you are deploying in Hospitality , Retail , Healthcare , or Transport environments, the principles and checklists in this guide apply universally.
Technical Deep-Dive
To effectively troubleshoot captive portal failures, network administrators must understand the exact sequence of events that occurs when a client device connects to an open or pre-shared key (PSK) guest wireless network. Modern operating systems — including Apple iOS/macOS, Google Android, Microsoft Windows, and Linux distributions — do not wait for a user to open a browser to test for internet connectivity. Instead, they execute an automated active probing mechanism immediately upon completing the association and DHCP phases.
The Captive Portal Detection Sequence
The connection and verification process follows a highly structured sequence:
| Step | Action | Technical Description | Expected Success Indicator |
|---|---|---|---|
| 1 | Association | Client associates with the Guest SSID at Layer 2. | Successful 802.11 association frame exchange. |
| 2 | IP Provisioning | DHCP server assigns an IP address, subnet mask, gateway, and local DNS server. | DHCP ACK packet received by the client. |
| 3 | Active Probing | OS background service sends an unencrypted HTTP GET request to a vendor-specific canary URL. | HTTP 200 OK (Apple/Windows) or HTTP 204 No Content (Google). |
| 4 | Interception & Redirect | Wireless gateway/controller intercepts the HTTP probe and returns an HTTP 302/303 redirect pointing to the portal. | HTTP 302 Redirect to the captive portal FQDN. |
| 5 | Portal Rendering | Captive Portal Assistant (CPA) browser engine opens and renders the splash page. | Successful rendering of the login interface. |
+--------+ +------------+ +------------+ +-------------------+
| Client | | AP/Gateway | | DNS Server | | Captive Portal IP |
+--------+ +------------+ +------------+ +-------------------+
| | | |
|--- 1. DHCP Request --->| | |
|<-- 2. DHCP Ack --------| | |
| (IP & DNS Assigned) | | |
|--- 3. DNS Query ------>|------------------------->| |
| (canary URL) | | |
|<-- 4. DNS Response ----|<-------------------------| |
| (Resolved IP) | | |
|--- 5. HTTP GET ------->| | |
| (canary URL) | | |
|<-- 6. HTTP 302 --------| | |
| (Redirect to Portal)| | |
|--- 7. DNS Query ------>|------------------------->| |
| (Portal FQDN) | | |
|<-- 8. DNS Response ----|<-------------------------| |
| (Portal IP) | | |
|--- 9. HTTP/S GET ------>-------------------------------------------------------->|
| (Render Splash Page)| | |
|<-- 10. Render Page <-------------------------------------------------------------||
Each operating system utilizes a distinct set of canary URLs and expected responses to determine network status. Apple (iOS/macOS) probes http://captive.apple.com/hotspot-detect.html expecting an HTML document containing only the word Success in both the title and body. Google (Android/ChromeOS) probes http://connectivitycheck.gstatic.com/generate_204 expecting an HTTP status code 204 No Content with an empty body. Microsoft (Windows 10/11) probes http://www.msftconnecttest.com/connecttest.txt expecting a plain text response of Microsoft Connect Test.
If the device receives the expected response, it concludes that the network has direct, unhindered internet access. If the response is modified — such as receiving an HTTP 302 redirect — the operating system's Captive Portal Assistant (CPA) immediately launches a dedicated, sandboxed browser window to display the redirect target: the captive portal login page.
The HSTS and HTTPS Redirection Conflict
The historical method of captive portal redirection relies on DNS hijacking or HTTP interception. When an unauthenticated user attempts to browse to any website, the gateway intercepts the TCP port 80 (HTTP) or port 443 (HTTPS) traffic and responds on behalf of the destination server, injecting an HTTP 302 redirect. While this worked seamlessly in an era of unencrypted HTTP web browsing, it introduces severe security and operational challenges in modern HTTPS-dominated environments.
The primary obstacle is HTTP Strict Transport Security (HSTS), a web security policy mechanism specified in RFC 6797. HSTS forces web browsers to interact with websites using only secure HTTPS connections. When a browser attempts to connect to an HSTS-enabled domain — such as Google, Facebook, or banking portals — it strictly forbids any unencrypted communication and enforces strict SSL/TLS certificate validation.
If a captive portal gateway attempts to intercept an HTTPS request to an HSTS domain, it must present its own SSL certificate or a spoofed certificate to the client. Because the gateway's certificate does not match the requested domain name, the client's browser detects a man-in-the-middle attack and displays a non-bypassable security warning (e.g., NET::ERR_CERT_COMMON_NAME_INVALID or Your connection is not private). The browser blocks the redirect entirely, preventing the captive portal page from loading and leaving the user with a broken connection.
To mitigate this, modern enterprise wireless networks utilize two advanced mechanisms. First, exempting OS probes ensures that the unencrypted HTTP probes sent by operating systems are never subjected to HTTPS interception; the gateway must allow the unencrypted HTTP probe to be redirected using a standard HTTP 302 response to the secure, fully-qualified domain name (FQDN) of the captive portal. Second, RFC 8910 (Captive Portal API) defines a mechanism where DHCP options (Option 114) or IPv6 Router Advertisements inform the client device of the exact URL of the captive portal API endpoint. Instead of relying on brute-force DNS hijacking or HTTP redirection, compatible client devices query this API directly to obtain the portal URL and network status, bypassing the HSTS conflict entirely.
Implementation Guide
Deploying a reliable captive portal requires careful coordination between the physical wireless infrastructure (Access Points, Controllers, Gateways) and the cloud-based portal platform. This section provides a vendor-neutral, step-by-step implementation guide to ensure robust redirection compatibility across enterprise networks, referencing standard configurations found in controllers from Cisco, Aruba, and Ruckus. For related access control architecture, see the guide on How to Implement 802.1X Authentication with Cloud RADIUS .
Step 1: Walled Garden (ACL) Configuration
A Walled Garden or Access Control List (ACL) defines the specific external domains, IP addresses, or subnets that an unauthenticated guest device is permitted to access before logging in. If the walled garden is configured incorrectly, the client device will be unable to resolve or load the captive portal assets, resulting in a blank screen or a timeout error.
To ensure seamless operation with Purple's platform, the walled garden must include the following components. Portal FQDNs are the fully-qualified domain names of the splash page hosting servers (e.g., *.purple.ai or regional variants). Identity Providers (IdPs) must be included if the portal supports social login — the walled garden must include the extensive list of domains used by these providers for OAuth authentication. Content Delivery Networks (CDNs) hosting CSS, JavaScript, fonts, or images used on the splash page must also be included.
Many modern controllers support wildcard domain names (e.g., *.purple.ai) in their walled garden configurations. The controller dynamically snoops DNS queries from unauthenticated clients; when a client queries a domain matching the wildcard, the controller temporarily adds the returned IP address to the client's pre-authentication allowlist. For legacy controllers that only support static IP addresses, administrators must configure a local DNS proxy or regularly update the static IP blocks associated with the cloud portal.
Step 2: DHCP and DNS Optimization
Because captive portal detection relies heavily on the initial network handshake, DHCP and DNS configurations must be optimized for high-density, transient environments. In high-footfall venues such as retail malls, transit hubs, or stadiums, IP address exhaustion is a common cause of captive portal failure. If the DHCP lease time is set too long (e.g., 24 hours), the IP pool will quickly deplete, preventing new guests from obtaining an IP address. For guest networks, the DHCP lease time should be configured between 15 to 30 minutes (900 to 1800 seconds).
Guest clients must be assigned a reliable, fast DNS server capable of resolving both public domains and the local captive portal FQDN. It is highly recommended to use enterprise-grade public DNS resolvers such as Cloudflare 1.1.1.1 or Google 8.8.8.8, or a local high-performance DNS forwarder. Critically, the wireless gateway must allow unauthenticated clients to perform DNS resolution. If a firewall rule blocks port 53 (UDP/TCP) traffic for pre-authenticated users, the client's OS will be unable to resolve the canary URLs, and the captive portal assistant will never launch.
Step 3: SSL/TLS Certificate Management
When a guest device is redirected to the captive portal, the browser establishes a secure HTTPS connection to the portal's FQDN. To prevent certificate warning screens, the captive portal must be secured with a valid, publicly-trusted SSL/TLS certificate. Self-signed certificates will be immediately blocked by modern mobile operating systems, preventing the captive portal assistant from rendering the page. If the redirection mechanism requires the client to communicate with the local gateway IP (e.g., for local MAC-to-IP binding), the gateway must have a valid certificate matching its local FQDN, and this FQDN must be resolvable by the guest DNS.
Best Practices
To maintain a high-performing guest wireless network that minimizes support tickets and maximizes user satisfaction, network operators should adhere to the following industry standards and best practices.
1. Optimize Walled Garden Rules for Social Logins
When utilizing social login options to capture user profiles, the walled garden must be meticulously maintained. Social media platforms frequently update their authentication subdomains and CDN IP ranges. If a single required domain is missing from the walled garden, the social login popup will fail to load or hang indefinitely.
| Provider | Essential Walled Garden Domains |
|---|---|
accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, lh3.googleusercontent.com |
|
facebook.com, *.facebook.com, *.fbcdn.net, m.facebook.com |
|
| Apple | appleid.apple.com, appleid.cdn-apple.com, gsa.apple.com |
2. Transition to Profile-Based Authentication and OpenRoaming
While captive portals are excellent for initial data capture and terms of service acceptance, repeating the login process on every visit introduces user friction. Modern enterprise networks are increasingly transitioning to profile-based authentication and Passpoint (Hotspot 2.0) technologies, such as OpenRoaming.
Under the Purple Connect license, Purple acts as a free identity provider for OpenRoaming services. Passpoint allows a guest to install a secure profile on their device during their first visit. Upon subsequent visits to any participating venue worldwide, the device automatically and securely associates with the network at Layer 2 using WPA3-Enterprise and 802.1X authentication, completely bypassing the captive portal. This delivers a seamless, cellular-like roaming experience while maintaining secure, encrypted data transmission. For a detailed implementation guide, see How to Implement 802.1X Authentication with Cloud RADIUS .
3. Ensure Compliance with Regulatory Frameworks
Guest WiFi deployments must be designed with strict adherence to global data privacy and security standards. For GDPR / CCPA Compliance, the captive portal must present clear, unambiguous terms of service and privacy policies. Consent for marketing communications must be actively opted-in (not pre-checked), and users must have a straightforward mechanism to request data deletion. For PCI DSS Compliance, if the guest network co-exists on the same physical infrastructure as the venue's Point of Sale (POS) systems, strict logical segmentation must be enforced. The guest VLAN must be completely isolated from the production and payment card VLANs using firewall rules and ACLs. For wireless security, implement WPA3-Transition Mode to allow older devices to connect using WPA2-Personal while newer devices benefit from the enhanced security of WPA3, including Protected Management Frames (PMF).
Troubleshooting & Risk Mitigation
When guest wireless issues are reported, venue operations and front-of-house staff require a clear, structured diagnostic sequence to identify and resolve the root cause. Captive portal failures typically fall into two categories: client-side misconfigurations and operator-side infrastructure issues.
Client-Side Diagnostic and Resolution Checklist
For front-of-house staff assisting guests, work through these steps in order.
1. Disable Active VPNs. Virtual Private Networks establish an encrypted tunnel from the client device directly to a remote server. Because the VPN client attempts to encrypt and route all traffic immediately upon network connection, it bypasses the local gateway's DNS hijack and HTTP redirection rules. The guest must temporarily disable their VPN to complete the captive portal login, after which the VPN can be safely re-enabled.
2. Turn Off Private/Randomized MAC Addresses. Modern operating systems (iOS 14+ and Android 10+) enable Private Wi-Fi Address or MAC Randomization by default to prevent tracking. While beneficial for privacy, this feature causes the device to present a different MAC address to the network on subsequent connections or after a short period of inactivity. This breaks MAC-based session persistence, forcing the guest to re-authenticate repeatedly. Instruct the guest to disable Private Address for the venue's SSID in their device's wireless settings.
3. Bypass Secure DNS (DoH/DoT). If the guest has configured a custom DNS server or uses DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) in their browser settings, the browser will refuse to accept the local gateway's hijacked DNS responses. The user must temporarily disable secure DNS in their browser settings or clear their device's DNS cache to allow the local redirect to function.
4. Force an Unencrypted HTTP Connection (NeverSSL). If the captive portal assistant fails to launch automatically, the guest's browser may be stuck trying to load an HTTPS page. Instruct the guest to open a standard browser window and navigate to http://neverssl.com. Because this website is explicitly designed to never use SSL/TLS, the gateway can intercept the HTTP request and successfully inject the HTTP 302 redirect to the guest internet login screen.
5. Forget and Rejoin the Network. If a previous authentication session was terminated abnormally, the client device may hold stale DHCP or ARP cache data. Forgetting the network in the wireless settings and reconnecting forces a clean DHCP handshake and restarts the captive portal detection sequence.
Operator-Side Infrastructure Troubleshooting
For network administrators investigating systemic issues where multiple guests report portal failures, the following checks should be performed. Monitor DHCP Pool Utilization by inspecting the DHCP scope on the local gateway or router; if the pool is 100% utilized, reduce the lease time to 5-10 minutes to rapidly reclaim IP addresses from departed guests. Verify DNS Redirection Rules by performing a packet capture (PCAP) on the gateway interface to confirm that unauthenticated clients are successfully sending DNS queries to port 53 and receiving responses. Audit Walled Garden Latency to ensure that the walled garden is optimized and that DNS resolution for walled garden domains is caching correctly on the controller. Finally, check Certificate Expiration to ensure that the SSL/TLS certificate installed on the wireless controller or gateway is valid, unexpired, and signed by a trusted Certificate Authority (CA).
ROI & Business Impact
Investing in a robust, cloud-managed captive portal platform like Purple yields measurable financial and operational returns for enterprise venues. By systematically resolving captive portal login issues, organizations directly impact both the top and bottom lines.
Reduction in Support Overhead and Guest Friction
For hospitality and retail venues, front-of-house staff frequently spend valuable time troubleshooting guest WiFi connectivity. A high captive portal failure rate leads to increased guest frustration and negative online reviews, a high volume of low-complexity support tickets escalated to the IT team, and operational inefficiencies as front-of-house staff are distracted from their primary duties. By implementing Purple's robust, cross-platform compatible redirection mechanism, venues typically experience a 50% to 70% reduction in WiFi-related support complaints.
Maximizing Data Capture and Marketing ROI
A captive portal is the primary gateway for capturing valuable first-party customer data, including email addresses, phone numbers, and social profiles. When a captive portal fails to load, the venue loses the opportunity to register that guest. With a functional portal, venues can achieve opt-in rates of over 60% for marketing communications, rapidly growing their customer CRM database. By integrating guest authentication with WiFi Analytics , venue operators gain deep insights into visitor behavior, including dwell times, return rates, and footfall patterns across different zones.
Unlocking Retail Media and Monetization Opportunities
For large-scale venues like shopping malls, stadiums, and exhibition centers, the captive portal represents premium digital real estate. By utilizing the splash page and post-login redirect screens, operators can tap into the rapidly growing Retail Media market. Display highly targeted, location-aware advertisements to guests at the exact moment they connect, or sell sponsorship packages to brands, turning a traditional IT cost center into a direct revenue-generating asset.
References
[1] Wikipedia Contributors. "Captive Portal." Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Captive_portal
[2] IETF RFC 6797. "HTTP Strict Transport Security (HSTS)." Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc6797
[3] IETF RFC 8910. "Captive-Portal Identification in DHCP and Router Advertisements." Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc8910
[4] Wireless Broadband Alliance. "OpenRoaming." WBA. https://wballiance.com/openroaming/
[5] NeverSSL. "NeverSSL: Helping you get online." NeverSSL. http://neverssl.com/
Définitions clés
Captive Portal
Une page web présentée aux utilisateurs nouvellement connectés d'un réseau invité avant qu'ils ne bénéficient d'un accès internet plus large. Le portail nécessite généralement une authentification (e-mail, connexion via les réseaux sociaux ou code coupon), l'acceptation des conditions d'utilisation, ou les deux. Il s'agit du principal mécanisme de capture des données des invités dans les déploiements WiFi d'entreprise.
Les équipes informatiques sont confrontées aux portails captifs comme premier point de défaillance lors des réclamations concernant le WiFi invité. Comprendre l'architecture technique du portail est essentiel pour diagnostiquer pourquoi la page de connexion ne s'affiche pas.
Détournement de DNS
Une technique utilisée par les passerelles de Captive Portal où le serveur DNS local renvoie l'adresse IP du serveur du Captive Portal en réponse à toutes les requêtes DNS des clients non authentifiés, quel que soit le domaine réellement interrogé. Cela force le navigateur du client à se connecter au portail plutôt qu'à la destination initialement prévue.
Le détournement de DNS est le mécanisme central de la plupart des implémentations de redirection de Captive Portal. Il est efficace pour le trafic HTTP mais est bloqué par les configurations DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT) sur les appareils clients.
HTTP Strict Transport Security (HSTS)
Un mécanisme de politique de sécurité web (RFC 6797) qui ordonne aux navigateurs de communiquer uniquement avec un site web en utilisant HTTPS, et de refuser toute connexion HTTP ou toute connexion avec des certificats SSL invalides. Une fois qu'un navigateur a reçu un en-tête HSTS d'un domaine, il applique cette politique pendant une durée spécifiée (max-age), même si l'utilisateur saisit manuellement une URL HTTP.
HSTS est la raison principale pour laquelle les redirections de Captive Portal échouent sur les appareils modernes. Lorsqu'une passerelle tente d'intercepter une requête HTTPS vers un domaine compatible HSTS, le navigateur détecte l'incohérence du certificat et bloque la redirection, empêchant ainsi le chargement du portail.
Assistant de Captive Portal (CPA)
Un processus de navigation léger et isolé (sandbox) intégré aux systèmes d'exploitation modernes (CNA d'Apple, CPA d'Android, NCSI de Windows) qui se lance automatiquement lorsque le système d'exploitation détecte qu'il se trouve derrière un Captive Portal. Le CPA affiche la page d'accueil dans un environnement restreint qui empêche le portail d'accéder aux identifiants de l'appareil ou au stockage persistant.
Le CPA est ce qui provoque l'affichage automatique de la page de connexion sur la plupart des appareils. Si le CPA ne parvient pas à se lancer (par exemple, en raison d'un VPN ou de DoH), l'invité doit naviguer manuellement vers l'URL du portail.
Walled Garden
Une liste de contrôle d'accès (ACL) de pré-authentification qui définit les domaines externes, les adresses IP ou les sous-réseaux spécifiques auxquels les appareils invités non authentifiés sont autorisés à accéder avant de finaliser la connexion au Captive Portal. Les ressources situées en dehors du walled garden sont bloquées tant que l'authentification n'est pas terminée.
Un walled garden mal configuré est l'une des causes les plus courantes d'échec des portails captifs, en particulier pour les flux de connexion sociale qui nécessitent l'accès à plusieurs domaines OAuth tiers.
Randomisation des adresses MAC
Une fonctionnalité de confidentialité dans les systèmes d'exploitation mobiles modernes (iOS 14+, Android 10+) qui amène l'appareil à présenter une adresse MAC générée de manière aléatoire à chaque réseau WiFi auquel il se connecte, plutôt que son adresse MAC matérielle d'origine. L'adresse randomisée peut également changer périodiquement en cours de connexion.
La randomisation MAC rompt la persistance de la session du Captive Portal car la passerelle utilise l'adresse MAC pour suivre les clients authentifiés. Lorsque l'adresse MAC change, la passerelle traite l'appareil comme un nouveau client non authentifié, imposant une ré-authentification.
RFC 8910 (API de Captive Portal)
Une norme IETF qui définit un mécanisme permettant aux réseaux d'informer les appareils clients de la présence et de l'URL d'un Captive Portal à l'aide de l'option DHCP 114 (pour IPv4) ou des options d'annonce de routeur IPv6. Les appareils compatibles interrogent directement le point de terminaison de l'API annoncé pour déterminer leur statut réseau et obtenir l'URL du portail, éliminant ainsi le besoin de détournement de DNS.
La RFC 8910 est l'alternative moderne et conforme aux normes au détournement de DNS pour la détection des portails captifs. Elle résout le conflit HSTS en communiquant l'URL du portail au niveau de la couche réseau plutôt qu'en tentant d'intercepter le trafic HTTP/HTTPS.
DNS-over-HTTPS (DoH)
Un protocole qui chiffre les requêtes DNS en les envoyant via une connexion HTTPS à un résolveur de confiance (tel que Cloudflare 1.1.1.1 ou Google 8.8.8.8), plutôt qu'en les envoyant sous forme de paquets UDP en texte clair au serveur DNS attribué par le réseau. Cela empêche la passerelle locale d'intercepter ou de détourner les réponses DNS.
Le DoH est de plus en plus activé par défaut dans les navigateurs modernes (Chrome, Firefox, Edge) et les systèmes d'exploitation. Lorsque le DoH est actif, le mécanisme de détournement de DNS du Captive Portal est contourné, et l'écran de connexion internet invité ne s'affiche pas automatiquement.
NeverSSL
Un site web d'utilité publique (http://neverssl.com) explicitement conçu pour ne jamais utiliser le chiffrement SSL/TLS. Il sert de déclencheur manuel fiable pour les redirections de Captive Portal car la passerelle peut toujours intercepter sa requête HTTP non chiffrée et injecter une redirection 302 vers la page de connexion du portail.
NeverSSL est la solution de contournement manuelle recommandée lorsqu'un appareil invité ne parvient pas à afficher automatiquement la page de connexion du Captive Portal. Le personnel d'accueil doit être formé pour diriger les invités vers cette URL comme première étape de résolution.
OpenRoaming (Passpoint/Hotspot 2.0)
Une norme mondiale d'itinérance WiFi développée par la Wireless Broadband Alliance (WBA) qui permet aux appareils de s'authentifier automatiquement et de manière sécurisée auprès des réseaux WiFi participants à l'aide d'un profil d'identification pré-installé, sans nécessiter d'interaction manuelle avec un Captive Portal. L'authentification utilise les protocoles WPA3-Enterprise et 802.1X.
L'OpenRoaming est l'évolution à long terme au-delà des portails captifs pour le WiFi invité d'entreprise. Sous la licence Connect de Purple, Purple agit en tant que fournisseur d'identité gratuit pour l'OpenRoaming, permettant aux invités récurrents de contourner entièrement le Captive Portal lors de leurs visites ultérieures.
Exemples concrets
Un hôtel de centre-ville de 350 chambres a déployé un réseau WiFi invité optimisé par Purple sur l'ensemble des étages et des espaces publics. La réception reçoit entre 15 et 20 plaintes par jour de la part de clients dont la page de connexion du Captive Portal ne se charge pas. L'hôtel utilise des contrôleurs sans fil Cisco Catalyst 9800 et un routeur Cisco ISR 4331. L'enquête initiale montre que le problème est plus fréquent sur les iPhones exécutant iOS 17 et les appareils Android 13. Comment l'architecte réseau doit-il diagnostiquer et résoudre ce problème ?
Commencez par un diagnostic structuré sur quatre couches. Couche 1 (DHCP) : Connectez-vous au Cisco ISR 4331 et exécutez show ip dhcp pool et show ip dhcp binding. Vérifiez le nombre total de liaisons actives par rapport à la taille du pool. Si l'utilisation dépasse 85 %, le pool est proche de l'épuisement. Réduisez la durée du bail de la valeur par défaut de 1 jour à 1800 secondes (30 minutes) en utilisant ip dhcp pool GUEST_WIFI et lease 0 0 30. Couche 2 (DNS) : Sur le Catalyst 9800, vérifiez que l'ACL de pré-authentification (utilisée pour le SSID du Captive Portal) autorise le trafic des ports UDP et TCP 53 vers les serveurs DNS attribués. Effectuez une capture de paquets sur l'interface VLAN invité pour confirmer que les requêtes DNS reçoivent une réponse. Couche 3 (Walled Garden) : Accédez à l'interface graphique du Catalyst 9800 sous Configuration > Tags & Profiles > Policy. Inspectez la liste des filtres d'URL associée au SSID invité. Confirmez que *.purple.ai, accounts.google.com, *.facebook.com, appleid.apple.com et tous les domaines CDN associés sont inclus. Activez le snooping DNS sur le filtre d'URL pour permettre la résolution de domaines avec caractères génériques. Couche 4 (Spécifique à iOS) : Les appareils iOS 17 utilisent captive.apple.com/hotspot-detect.html comme URL de test. Confirmez que le Catalyst 9800 intercepte cette requête HTTP et renvoie une redirection HTTP 302 vers le FQDN du portail Purple (par exemple, https://portal.purple.ai). Vérifiez que le certificat du portail Purple est valide et n'est pas auto-signé. Si la redirection se fait vers l'IP locale du contrôleur au lieu du FQDN du portail cloud, mettez à jour l'URL de redirection externe dans la configuration du SSID.
Une chaîne nationale de vente au détail comptant 120 magasins a déployé un WiFi invité à l'aide de bornes d'accès Aruba Instant AP gérées via Aruba Central. L'équipe marketing signale que l'option de connexion sociale « Se connecter avec Google » sur le Captive Portal échoue pour environ 30 % des invités. L'option de connexion par simple e-mail fonctionne correctement. Le problème apparaît par intermittence et est plus fréquent dans les magasins qui ont récemment mis à jour le firmware de leurs bornes Aruba. Comment l'équipe réseau et informatique doit-elle enquêter sur ce problème ?
L'échec intermittent de la connexion sociale alors que la connexion par e-mail réussit est un problème classique de couverture de domaine de walled garden, probablement exacerbé par une mise à jour du firmware qui a réinitialisé ou modifié l'ACL de pré-authentification. Procédez comme suit. Étape 1 — Reproduire et capturer : Dans un magasin concerné, connectez un appareil de test au SSID invité et tentez une connexion Google. Ouvrez les outils de développement du navigateur (F12 > onglet Réseau) avant de cliquer sur « Se connecter avec Google ». Notez toutes les requêtes ayant échoué — elles apparaîtront sous forme d'entrées rouges avec des codes d'état tels que ERR_CONNECTION_REFUSED ou ERR_NAME_NOT_RESOLVED. Ces domaines en échec sont les entrées manquantes du walled garden. Étape 2 — Auditer le Walled Garden d'Aruba Central : Connectez-vous à Aruba Central et accédez à la configuration du SSID pour le réseau invité. Examinez les entrées du Walled Garden / Liste blanche. Le flux OAuth de Google nécessite au minimum : accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, www.gstatic.com, lh3.googleusercontent.com et oauth2.googleapis.com. Après une mise à jour du firmware, Aruba Central a pu revenir à une configuration basée sur un modèle qui omettait certaines de ces entrées. Étape 3 — Activer le DNS Snooping : Dans Aruba Central, activez la mise sur liste blanche basée sur le DNS pour le SSID invité. Cela permet à la borne d'accès de résoudre et d'autoriser dynamiquement les adresses IP renvoyées pour les domaines correspondant aux modèles de caractères génériques configurés (par exemple, *.google.com, *.gstatic.com). Cette méthode est plus résiliente que la mise sur liste blanche d'adresses IP statiques, car les adresses IP du CDN de Google changent fréquemment. Étape 4 — Valider et déployer : Testez le correctif dans le magasin pilote, confirmez que le taux de réussite de la connexion Google atteint plus de 95 %, puis déployez la configuration mise à jour dans les 120 magasins via la politique de groupe d'Aruba Central.
Questions d'entraînement
Q1. Un centre de conférence accueillant un événement de 2 000 délégués signale que 40 % des participants ne parviennent pas à afficher la page de connexion du WiFi invité sur leurs appareils. L'événement a commencé il y a 30 minutes. L'infrastructure sans fil utilise des contrôleurs Ruckus SmartZone. Quelle est la cause profonde la plus probable et quelle est la résolution la plus rapide ?
Conseil : Prenez en compte l'envergure de l'événement (2 000 connexions simultanées) et le temps écoulé depuis son début. Réfléchissez à la ressource réseau la plus susceptible d'être épuisée au cours des 30 premières minutes d'un événement à forte densité.
Voir la réponse type
La cause profonde la plus probable est l'épuisement du pool DHCP. Avec 2 000 délégués tentant de se connecter simultanément en l'espace de 30 minutes, le pool d'adresses DHCP pour le VLAN invité a presque certainement été épuisé, en particulier si la durée du bail était définie sur la valeur par défaut de 8 ou 24 heures. Les délégués qui ne peuvent pas obtenir d'adresse IP ne verront aucune page de connexion car la séquence de détection du Captive Portal ne peut pas commencer sans une attribution d'IP valide. La résolution la plus rapide consiste à se connecter au contrôleur Ruckus SmartZone, à accéder à la configuration du serveur DHCP pour le VLAN invité et à réduire la durée du bail à 5-10 minutes pour forcer la récupération rapide des adresses des délégués qui sont déjà partis ou déconnectés. De plus, vérifiez si la taille du pool DHCP est suffisante pour le nombre d'utilisateurs simultanés attendu — un pool de 254 adresses (sous-réseau /24) est insuffisant pour 2 000 délégués. Élargissez le pool à un sous-réseau /22 ou /21 (1 022 ou 2 046 adresses) si possible. En guise de vérification secondaire, vérifiez que l'ACL de pré-authentification sur le SmartZone autorise les requêtes DNS (port 53) provenant de clients non authentifiés, car un trafic DNS à volume élevé peut parfois déclencher des règles de limitation de débit.
Q2. Un responsable informatique d'hôtel reçoit une plainte d'un client séjournant dans la chambre 412. Le client indique que la page de connexion WiFi est apparue brièvement, qu'il a saisi son adresse e-mail et accepté les conditions, mais qu'on lui demande maintenant de se reconnecter toutes les 10 à 15 minutes. Les autres clients du même étage ne signalent pas ce problème. Le client utilise un iPhone 15 sous iOS 17. Quels sont la cause et la résolution les plus probables ?
Conseil : Le problème est spécifique à un seul appareil et implique une ré-authentification répétée à de courts intervalles. Considérez ce que fait iOS 17 par défaut avec les adresses MAC sur les réseaux WiFi, et comment la passerelle sans fil de l'hôtel suit les sessions authentifiées.
Voir la réponse type
La cause la plus probable est la randomisation de l'adresse MAC. iOS 14 et les versions ultérieures activent l'adresse Wi-Fi privée par défaut, ce qui amène l'iPhone à présenter une adresse MAC générée de manière aléatoire à chaque réseau. Dans iOS 17, l'adresse MAC randomisée peut changer périodiquement (environ toutes les 24 heures) ou à chaque nouvelle association réseau. La passerelle sans fil de l'hôtel suit les sessions des clients authentifiés par adresse MAC ; lorsque l'adresse MAC change, la passerelle traite l'appareil comme un nouveau client non authentifié et bloque l'accès à Internet, déclenchant à nouveau le Captive Portal. La résolution pour le client consiste à désactiver l'adresse privée pour l'SSID de l'hôtel : allez dans Réglages > Wi-Fi, appuyez sur l'icône (i) à côté de l'SSID de l'hôtel, et désactivez l'option Adresse Wi-Fi privée. L'appareil se reconnectera avec son adresse MAC matérielle et la session persistera sans ré-authentification répétée. À plus long terme, du côté de l'opérateur, l'hôtel devrait envisager de mettre en œuvre une persistance de session basée sur l'adresse IP (en plus de la MAC) ou de passer à OpenRoaming/Passpoint pour les clients réguliers, ce qui élimine complètement le problème de ré-authentification du Captive Portal.
Q3. L'équipe informatique d'une chaîne de magasins a configuré un nouveau Captive Portal à l'aide de Purple. Le walled garden a été configuré avec le domaine du portail et les principaux domaines des fournisseurs de connexion sociale. Lors des tests, la page du portail se charge correctement et l'option de connexion par e-mail fonctionne, mais lorsqu'un testeur clique sur « Se connecter avec Google », une fenêtre contextuelle de connexion Google apparaît brièvement puis se ferme sans terminer l'authentification. Le testeur utilise un Samsung Galaxy S23 sous Android 13 avec le navigateur Chrome. Que doit examiner l'équipe informatique ?
Conseil : La fenêtre contextuelle Google apparaît mais se ferme sans se terminer — cela signifie que la redirection OAuth initiale vers Google fonctionne, mais que quelque chose échoue lors du rappel d'authentification ou de l'échange de jetons. Considérez quels domaines sont impliqués dans le flux complet Google OAuth 2.0 au-delà de accounts.google.com.
Voir la réponse type
Le symptôme — la fenêtre contextuelle Google qui apparaît puis se ferme sans se terminer — indique que la redirection OAuth initiale vers Google réussit (accounts.google.com est dans le walled garden), mais qu'un ou plusieurs des domaines de rappel OAuth ou d'échange de jetons suivants sont bloqués. Le flux Google OAuth 2.0 pour les applications Web implique plusieurs domaines au-delà de accounts.google.com. L'équipe informatique doit ouvrir Chrome DevTools sur l'appareil de test (ou utiliser un navigateur de bureau pour simuler le flux), cliquer sur Se connecter avec Google, et observer l'onglet Network pour détecter toute requête ayant échoué. Les domaines manquants courants incluent : oauth2.googleapis.com (point de terminaison du jeton), www.googleapis.com (appels API), ssl.gstatic.com et fonts.gstatic.com (CDN de Google pour les ressources de la page de connexion), et lh3.googleusercontent.com (chargement de la photo de profil, ce qui peut bloquer la fenêtre contextuelle). Ajoutez tous les domaines manquants identifiés au walled garden dans la configuration du contrôleur Aruba/Cisco/Ruckus, en utilisant des modèles génériques (*.googleapis.com, *.gstatic.com) si le contrôleur prend en charge le snoopage DNS. Testez à nouveau après chaque ajout pour isoler le domaine bloquant spécifique. Une fois que le flux complet Google OAuth s'est déroulé avec succès, validez le correctif sur les appareils Android et iOS avant de le déployer en production.
Continuer la lecture de cette série
Conception de Captive Portals B2B : Collecter le Nom Enregistré et les Données de l'Entreprise
Ce guide fournit aux responsables informatiques et aux exploitants de sites un cadre technique indépendant des fournisseurs pour concevoir des Captive Portals B2B. Il détaille comment structurer les champs d'inscription pour capturer le nom enregistré et les données de l'entreprise, garantissant des taux de complétion élevés tout en maintenant la conformité GDPR et en développant une intelligence au niveau des comptes.
Architecture de Captive Portal : Sécurité, redirection et bonnes pratiques
Une référence technique définitive sur l'architecture de captive portal d'entreprise. Ce guide détaille l'isolation réseau, la redirection DNS, l'authentification RADIUS et la conformité en matière de sécurité pour les responsables informatiques déployant des réseaux WiFi invités sécurisés et riches en données.
Optimiser les Portails Captifs B2B : Capturer les Noms d'Entreprise et les Données Professionnelles
Ce guide explique comment les responsables informatiques, les architectes réseau et les directeurs d'exploitation de sites peuvent configurer les portails captifs B2B pour capturer des données professionnelles - noms d'entreprise, intitulés de poste et adresses e-mail professionnelles - lors de la connexion au WiFi. Il couvre l'ensemble de l'architecture technique, de l'isolation VLAN et l'authentification RADIUS jusqu'à l'intégration CRM avec Salesforce et HubSpot, avec conformité GDPR et CCPA intégrée. Les sites qui déploient cela correctement transforment leur réseau WiFi invité en un moteur de données de première partie et un système automatisé de génération de leads.