Dépannage des redirections de Captive Portal : résoudre les échecs de connexion au WiFi invité

Synthèse

La requête « WiFi invité connecté mais pas d'internet » est l'un des tickets de support les plus courants dans les réseaux d'entreprise. Le symptôme est visible pour chaque visiteur ; la cause est invisible pour la plupart des équipes informatiques tant qu'elles ne comprennent pas la chaîne de redirection. Un Captive Portal (également appelé page d'accueil ou passerelle hotspot) intercepte la requête initiale de connectivité HTTP d'un appareil et émet une redirection HTTP 302 vers une page de connexion. Si une étape de cette chaîne échoue - requêtes bloquées, conflits HSTS, lacunes du walled garden, pannes RADIUS ou épuisement DHCP - l'invité ne voit rien d'autre qu'une icône WiFi connectée et aucun accès internet. Ce guide vous présente chaque mode de défaillance, les mécanismes de protocole sous-jacents et les modifications de configuration qui les résolvent. Purple fonctionne sur plus de 80 000 sites actifs, traitant 440 millions de connexions par an (données internes Purple, 2024), et les schémas décrits ici représentent les causes profondes les plus fréquentes que nous observons dans les déploiements de l'hôtellerie, du commerce de détail, des transports et du secteur public.

Analyse technique approfondie

Comment fonctionne réellement la détection de Captive Portal

Chaque système d'exploitation majeur intègre un mécanisme pour détecter si un réseau nécessite une authentification avant d'accorder l'accès à internet. La compréhension de ces mécanismes est la base de tout dépannage de Captive Portal.

Lorsqu'un appareil s'associe à un SSID, l'OS envoie une requête HTTP GET non chiffrée vers une URL prédéfinie. Le tableau ci-dessous répertorie les URL de test par plateforme.

Si la passerelle intercepte l'une de ces requêtes et renvoie une redirection HTTP 302 pointant vers l'URL du Captive Portal, l'OS reconnaît qu'il est derrière un portail et ouvre un pseudo-navigateur (un WebView léger) pour afficher la page d'accueil. Si la requête est entièrement bloquée, l'OS signale « Pas de connexion internet » et ne tente jamais d'ouvrir le portail. C'est la cause la plus fréquente du symptôme « WiFi invité connecté mais pas d'internet ».

Le problème HSTS

HTTP Strict Transport Security (HSTS) est une politique de sécurité web définie dans la RFC 6797. Elle indique aux navigateurs de refuser toutes les connexions HTTP simples vers un domaine et de rejeter tout certificat qui ne correspond pas exactement. Les domaines majeurs, notamment google.com, facebook.com et la plupart des sites bancaires, figurent sur la liste de préchargement HSTS intégrée à Chrome, Firefox, Safari et Edge.

Lorsqu'un visiteur ouvre un navigateur et saisit google.com, le navigateur met à niveau la requête vers HTTPS avant qu'elle ne quitte l'appareil. La passerelle ne peut pas intercepter une requête HTTPS et la rediriger proprement - elle devrait présenter un certificat pour google.com, qu'elle ne possède pas. Le navigateur détecte la non-correspondance du certificat et affiche un avertissement de sécurité strict. Le visiteur ne peut pas accéder à la page de connexion.

La bonne architecture repose entièrement sur les sondes HTTP au niveau de l'OS décrites ci-dessus. Ces sondes utilisent le protocole HTTP simple vers des URL non-HSTS spécifiquement pour que les passerelles puissent les intercepter et les rediriger sans conflits de certificats. Votre passerelle doit intercepter ces sondes HTTP et émettre la redirection 302. N'essayez pas d'intercepter le trafic HTTPS à des fins de Captive Portal.

Le walled garden (environnement protégé)

Un walled garden est l'ensemble des domaines et des adresses IP qu'un appareil peut atteindre avant de s'être authentifié. Si le walled garden est trop étroit, la splash page peut se charger mais l'authentification échouera. Les lacunes courantes comprennent :

• Domaines des fournisseurs d'identité : Si vous utilisez Microsoft Entra ID, Okta ou Google Workspace pour la connexion sociale ou SSO, leurs points de terminaison d'authentification doivent se trouver dans le walled garden.
• Domaines de CDN et d'actifs : Votre splash page peut charger du CSS, du JavaScript ou des polices de caractères à partir d'un réseau de diffusion de contenu (CDN). Si ces domaines de CDN sont bloqués, la page s'affichera de manière incorrecte.
• Domaines des processeurs de paiement : Si vous facturez l'accès via Stripe ou un autre processeur, les domaines de leurs SDK JavaScript doivent être pré-authentifiés.
• Domaines de la plateforme Purple : L'overlay cloud de Purple nécessite que la passerelle puisse joindre les serveurs RADIUS et les points de terminaison du portail de Purple. Ceux-ci sont documentés dans les guides d'intégration matérielle de Purple pour chaque plateforme prise en charge.

RADIUS et le problème d'autorisation

Le protocole RADIUS (Remote Authentication Dial-In User Service) est le protocole qui connecte votre passerelle locale à la plateforme d'authentification. Lorsqu'un visiteur remplit le formulaire de connexion, le Captive Portal envoie les identifiants au serveur RADIUS. Le serveur RADIUS renvoie un message Access-Accept ou Access-Reject. La passerelle agit en fonction de ce message en ouvrant ou en maintenant fermée la règle de pare-feu qui accorde l'accès à internet.

Le problème d'autorisation - lorsqu'un visiteur se connecte avec succès sur la splash page mais n'a toujours pas d'accès internet - signifie presque toujours que la passerelle n'a pas reçu ou traité le message Access-Accept. Les causes courantes incluent un secret partagé incorrect, les ports UDP 1812 et 1813 bloqués par un pare-feu local, ou l'adresse IP du serveur RADIUS configurée de manière incorrecte sur la passerelle.

Épuisement des adresses DHCP dans les environnements à haute densité

Dans les stades, les centres de conférence et les hubs de transport, l'épuisement du DHCP est une cause fréquente d'échecs de connexion qui semble identique à un problème de captive portal. Si le pool DHCP est plein, un nouvel appareil s'associe au point d'accès mais ne reçoit jamais d'adresse IP. Sans adresse IP, l'appareil ne peut pas envoyer la requête de test HTTP et n'atteint jamais le captive portal. L'appareil s'affiche comme connecté au SSID mais n'a pas d'accès internet.

Pour les sites comme Manchester Airports Group (MAG), où les volumes de passagers atteignent des pics soudains, les sous-réseaux doivent être dimensionnés pour le nombre maximal d'appareils simultanés, et non pour la moyenne. Des durées de bail DHCP courtes (15 à 30 minutes pour les réseaux de visiteurs temporaires) permettent de récupérer rapidement les adresses des appareils partis.

Guide de mise en œuvre

Les étapes suivantes s'appliquent à n'importe quelle plateforme matérielle - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks ou Fortinet - lors de l'intégration avec l'overlay cloud de Purple.

Étape 1 : Configurer le SSID pour le captive portal externe. Dans votre contrôleur matériel, configurez le SSID invité pour rediriger les clients non authentifiés vers l'URL du portail externe de Purple. Désactivez toute page d'accueil locale sur le contrôleur lui-même.

Étape 2 : Définir le walled garden. Ajoutez au minimum les domaines suivants : le portail de Purple et les endpoints RADIUS (consultez votre guide d'intégration matérielle), les URL de test de détection d'OS listées ci-dessus, les domaines de votre fournisseur d'identité (Microsoft Entra ID, Okta ou Google Workspace), et tous les domaines CDN utilisés par les ressources de votre page d'accueil.

Étape 3 : Configurer RADIUS. Saisissez les adresses IP du serveur RADIUS de Purple, le secret partagé depuis votre tableau de bord Purple, et définissez le port d'authentification sur 1812 et le port de comptabilité (accounting) sur 1813. Vérifiez que votre pare-feu local autorise le trafic UDP sortant sur ces ports.

Étape 4 : Définir les paramètres de session. Pour le secteur de l'hôtellerie-restauration et du commerce de détail, définissez la durée de la session sur 24 heures avec le cache des adresses MAC activé. Cela évite aux invités d'avoir à se réauthentifier lors d'une même visite. Pour les environnements de haute sécurité, des sessions plus courtes avec réauthentification sont appropriées.

Étape 5 : Dimensionner votre plage DHCP. Calculez le nombre maximal d'appareils simultanés pour votre site aux heures de pointe. Un restaurant de 500 places peut voir 800 appareils lors d'un service chargé. Dimensionnez le pool DHCP à 1 000 adresses avec un temps de bail de 30 minutes.

Étape 6 : Tester sur différents systèmes d'exploitation. Après la configuration, testez le parcours complet sur des appareils iOS, Android et Windows. Chacun utilise une URL de test et une implémentation WebView différentes. Un échec sur une plateforme alors que les autres fonctionnent est presque toujours dû à un manque dans le walled garden.

Bonnes pratiques

Les recommandations suivantes reflètent les normes et les modèles observés sur plus de 80 000 déploiements de sites Purple.

Séparez les réseaux invités et collaborateurs. Diffusez au moins trois SSIDs : un WiFi invité, un WiFi collaborateurs et un réseau IoT. Le trafic invité doit être isolé des systèmes internes. Consultez notre guide sur Trois SSIDs pour régner sur votre réseau : invité, Passpoint et WiFi IoT pour les détails d'architecture.

Utilisez un VLAN invité dédié. Segmentez le trafic invité dans son propre VLAN pour empêcher les mouvements latéraux et simplifier les règles de pare-feu. Il s'agit d'une exigence PCI-DSS si des données de cartes de paiement transitent par le réseau.

Mettez en œuvre des opt-ins à choix conscient. Le GDPR exige que la collecte de données sur le Captive Portal soit basée sur un consentement éclairé et affirmatif. Les opt-ins à choix conscient de Purple présentent clairement les choix de collecte de données, avec des cases à cocher distinctes pour chaque finalité. Ceci est obligatoire pour les établissements opérant au Royaume-Uni ou dans l'UE.

Surveillez la santé du portail de manière proactive. La plateforme WiFi Analytics de Purple offre une visibilité en temps réel sur les taux de réussite des connexions, le nombre de sessions et les échecs d'authentification. Une baisse soudaine des connexions réussies est un signal d'alarme précoce concernant un problème RADIUS ou de walled garden avant que les invités ne commencent à se plaindre.

Appliquez une image de marque cohérente. La splash page est la première interaction personnalisée d'un invité avec votre réseau. Un portail bien conçu augmente les taux d'opt-in et définit les attentes pour l'expérience WiFi. Consultez Comment faire une excellente première impression avec votre WiFi invité pour des conseils de conception.

-

Dépannage et atténuation des risques

Lorsqu'un problème de Captive Portal est signalé, suivez cette séquence de diagnostic avant d'apporter des modifications de configuration.

Isolez le point de défaillance. Demandez à l'invité quel OS et quel navigateur il utilise. Testez vous-même le même parcours sur le même OS. Si le problème est spécifique à un OS, la cause est presque certainement une entrée de walled garden manquante pour l'URL de test de cet OS.

Vérifiez la résolution DNS. Depuis un appareil connecté au VLAN invité, tentez de résoudre le nom d'hôte du Captive Portal. Si la résolution DNS échoue, l'appareil ne peut pas atteindre la splash page même si la redirection est correctement émise. Vérifiez que votre serveur DHCP distribue des adresses DNS fiables et que la passerelle autorise les requêtes DNS dans l'état de pré-authentification.

Capturez la redirection. Utilisez les outils de développement du navigateur (F12) ou une capture de paquets pour observer l'échange HTTP. Vous devriez voir la requête de test de l'OS suivie d'une réponse HTTP 302 contenant l'URL du portail. Si vous voyez la requête de test mais aucune réponse 302, la passerelle n'intercepte pas correctement. Si vous ne voyez aucune requête de test, l'OS a déjà déterminé qu'il dispose d'un accès internet (possiblement à partir d'un état mis en cache) et n'envoie pas le test. Vérifier la communication RADIUS. Sur la passerelle, vérifiez les journaux de comptabilité RADIUS. Une authentification réussie génère un enregistrement Accounting-Start. Si vous ne voyez aucun enregistrement de comptabilité après la connexion d'un invité, la communication RADIUS est interrompue. Vérifiez le secret partagé, l'adresse IP du serveur et les règles de pare-feu.

Vérifier l'utilisation des baux DHCP. Sur le serveur DHCP, examinez le nombre actuel de baux par rapport à la taille du pool. Si l'utilisation dépasse 90 %, vous approchez de l'épuisement. Élargissez le pool ou réduisez immédiatement la durée du bail.

Le tableau suivant associe les symptômes les plus courants à leurs causes profondes et aux correctifs correspondants.

ROI et impact commercial

Chaque échec de Captive Portal est un événement de capture de données manqué. La plateforme Guest WiFi de Purple convertit chaque authentification réussie en un enregistrement de données de première main - nom, e-mail, données démographiques et fréquence des visites - qui alimente directement l'automatisation du marketing et les programmes de fidélité.

Pour un opérateur de l'hôtellerie comme Premier Inn ou Whitbread, une amélioration de 10 % des taux de réussite de l'authentification au portail sur un parc de 700 établissements se traduit directement par des dizaines de milliers d'enregistrements opt-in supplémentaires par mois. Ces enregistrements alimentent des campagnes d'e-mailing personnalisées avec des taux d'ouverture nettement plus élevés que les listes achetées.

Pour les opérateurs du commerce de détail, le Captive Portal est le point d'entrée pour comprendre le temps de séjour des acheteurs, la fréquence des visites répétées et le comportement entre les différents points de vente. Purple a collecté 29 milliards de points de données (données internes de Purple) à travers son réseau de sites. Ces données ne valent que ce que vaut le taux d'authentification qui les génère.

Pour les plateformes de transport comme Manchester Airports Group, un WiFi invité fiable est une mesure de satisfaction des passagers suivie au niveau de la direction. Un portail qui échoue par intermittence pendant les périodes de pointe de départ génère des plaintes et nuit au Net Promoter Score de l'établissement. Pour les environnements de santé, un WiFi visiteurs fiable réduit la pression sur le personnel clinique qui devrait autrement gérer les réclamations de connectivité, et soutient les indicateurs de satisfaction des patients.

La SLA de disponibilité de 99,999 % de Purple garantit que la superposition cloud elle-même n'est pas le point de défaillance. Lorsque des problèmes de portail surviennent, la cause est presque toujours une configuration locale - ce que ce guide vous permet de résoudre sans ouvrir de ticket d'assistance.

Références

[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, Novembre 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409

[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910

[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, Février 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview

[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, Février 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues

[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0