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

Résumé exécutif

La requête « WiFi invité connecté mais pas d'internet » est l'un des tickets de support les plus fréquents dans le domaine des réseaux d'entreprise. Le symptôme est visible par chaque visiteur ; la cause reste invisible pour la plupart des équipes informatiques tant qu'elles ne comprennent pas la chaîne de redirection. Un Captive Portal (également appelé page de connexion ou passerelle de point d'accès) 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, failles de 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 pour les résoudre. Purple opère 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 observées 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 du 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. Comprendre 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 à 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 se trouve derrière un portail et ouvre un pseudo-navigateur (un WebView léger) pour afficher la page de connexion. 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

Le protocole HTTP Strict Transport Security (HSTS) est une politique de sécurité web définie dans la RFC 6797. Il 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 tels que 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 l'incohérence 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 du système d'exploitation décrites ci-dessus. Ces sondes utilisent le protocole HTTP simple vers des URL non HSTS précisément pour que les passerelles puissent les intercepter et les rediriger sans conflit de certificat. Votre passerelle doit intercepter ces sondes HTTP et émettre la redirection 302. N'essayez pas d'intercepter le trafic HTTPS pour les besoins du Captive Portal.

Le walled garden (environnement sécurisé)

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 restreint, la page de démarrage 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 page de démarrage peut charger du CSS, du JavaScript ou des polices de caractères à partir d'un réseau de diffusion de contenu. 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 leur 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 applique ce message en ouvrant ou en laissant 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 page de démarrage 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 mal configurée sur la passerelle.

Épuisement du DHCP dans les environnements à haute densité

Dans les stades, les centres de conférence et les hubs de transport, l'épuisement du pool 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 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 des sites comme Manchester Airports Group (MAG), où les volumes de passagers connaissent des pics importants, 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 d'implémentation

Les étapes suivantes s'appliquent à toutes les plateformes matérielles - 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 : les points de terminaison du portail et RADIUS de Purple (consultez votre guide d'intégration matérielle), les URL 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 de CDN utilisés par les ressources de votre page d'accueil.

Étape 3 : Configurer le RADIUS. Saisissez les adresses IP du serveur RADIUS de Purple, le secret partagé de votre tableau de bord Purple, et configurez le port d'authentification sur 1812 et le port de comptabilité 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 l'hôtellerie et le commerce de détail, configurez la durée de la session sur 24 heures avec la mise en cache des adresses MAC activée. Cela évite aux clients d'avoir à se réauthentifier au cours d'une même visite. Pour les environnements à haute sécurité, des sessions plus courtes avec réauthentification sont plus appropriées.

Étape 5 : Dimensionner votre plage DHCP. Calculez le nombre maximal d'appareils simultanés pour votre site à pleine capacité. Un restaurant de 500 places peut voir passer 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 tous les systèmes d'exploitation. Après la configuration, testez l'ensemble du parcours sur des appareils iOS, Android et Windows. Chacun utilise une URL de détection et une implémentation de WebView différentes. Un échec sur une plateforme alors que les autres fonctionnent est presque toujours dû à un oubli dans le walled garden.

-

Bonnes pratiques

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

Séparez les réseaux invités et collaborateurs. Configurez au moins trois SSIDs : Guest WiFi, Staff WiFi et un réseau IoT. Le trafic invité doit être isolé des systèmes internes. Consultez notre guide Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi 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. C'est une exigence PCI-DSS si des données de cartes de paiement transitent par le réseau.

Implémentez des consentements explicites. Le GDPR exige que la collecte de données sur le Captive Portal repose sur un consentement éclairé et affirmatif. Les options de consentement de Purple présentent les choix de collecte de données de manière claire, avec des cases à cocher distinctes pour chaque finalité. Ce n'est pas optionnel 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 avertissement précoce d'un problème RADIUS ou de walled garden avant que les invités ne commencent à se plaindre.

Appliquez une image de marque cohérente. Le portail d'accès est la première interaction de marque qu'un invité a avec votre réseau. Un portail bien conçu augmente les taux de conversion et définit les attentes pour l'expérience WiFi. Consultez How to make a great first impression with your guest WiFi 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 le même parcours vous-même 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 le portail d'accès 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 en phase 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'effectue pas l'interception 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 (probablement via un état mis en cache) et n'envoie pas la requête. Vérifiez la communication RADIUS. Sur la passerelle, vérifiez les journaux de comptabilité RADIUS. Une authentification réussie produit 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'IP du serveur et les règles de pare-feu.

Vérifiez l'utilisation des baux DHCP. Sur le serveur DHCP, examinez le nombre de baux actuels 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 au correctif approprié.

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 partie - 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 sur le portail dans un parc de 700 propriétés se traduit directement par des dizaines de milliers d'enregistrements d'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 de la vente au détail , le Captive Portal est le point d'entrée pour comprendre le temps de présence des acheteurs, la fréquence des visites répétées et le comportement multi-sites. 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 hubs 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 du site. Pour les environnements de santé , un WiFi visiteur fiable réduit la pression sur le personnel clinique qui devrait autrement gérer les plaintes de connectivité, et soutient les indicateurs de satisfaction des patients.

Le 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 guide vous permet de résoudre cela sans ouvrir de ticket de support.

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