Dépannage des redirections de portail captif : Résoudre les échecs de connexion au WiFi invité WiFi

Lorsque le WiFi montre un état connecté mais aucun accès à Internet, l'appareil a rejoint le réseau mais la redirection vers le portail captif s'est interrompue. Les causes habituelles sont le blocage d'un test du système d'exploitation, l'absence d'entrées dans le walled garden ou une défaillance DNS. D'autres causes incluent l'épuisement d'une plage DHCP ou un message Access-Accept RADIUS qui n'atteint jamais la passerelle. Chaque problème peut être résolu dans la configuration.

À quoi ressemble l'état « WiFi connecté mais pas d'Internet » ?

L'appareil rejoint le nom de réseau (SSID) et affiche un signal maximal, mais rien ne se charge. Chaque plateforme le signale différemment :

• iOS indique « Pas de connexion Internet » sous le nom du réseau.
• Android affiche « Connecté, pas d'Internet » ou une invite « Se connecter au réseau » qui ne mène nulle part.
• Windows marque le réseau comme « Pas d'Internet ».

Le visiteur voit une icône de WiFi active et un navigateur inactif, et rejette la faute sur l'établissement.

Un même symptôme peut masquer plusieurs défaillances distinctes. Vous observerez généralement l'un de ces schémas :

• La page de connexion n'apparaît jamais sur aucun appareil.
• La page de connexion apparaît sur les iPhone mais pas sur les smartphones Android, ou inversement.
• Le navigateur affiche un avertissement de certificat ou de confidentialité au lieu de la page de connexion.
• Le visiteur remplit le formulaire, voit un message de réussite, mais n'a toujours pas accès à Internet.
• Tout fonctionne lors des périodes creuses et échoue en période de pointe.

Chaque schéma pointe vers une couche différente du réseau. Commencez par analyser le schéma au lieu de redémarrer les points d'accès.

Comment fonctionne la détection de portail captif

Un portail captif est la page Web qu'une passerelle affiche avant d'accorder l'accès à Internet. La passerelle est votre contrôleur, pare-feu ou point d'accès, selon votre architecture.

Chaque système d'exploitation majeur recherche un portail captif dès qu'il rejoint un réseau. Il envoie une requête HTTP simple vers une adresse connue et compare la réponse à ce qu'il attend. Chaque résultat a une signification précise :

• La réponse correspond. L'appareil suppose qu'il dispose d'un accès Internet ouvert.
• La passerelle renvoie une redirection HTTP 302. L'appareil sait qu'il se trouve derrière un portail. Il ouvre une fenêtre de navigateur allégée, souvent appelée assistant de réseau captif, et charge votre page de connexion.
• La requête ne reçoit aucune réponse. L'appareil indique qu'il n'y a pas d'accès Internet et n'ouvre rien.

Microsoft indique dans sa documentation que son indicateur du statut de la connectivité réseau (NCSI) résout également dns.msftncsi.com lors d'un contrôle DNS. Un ordinateur portable sous Windows peut donc indiquer l'absence d'accès à Internet si le DNS de pré-authentification est défaillant, même si le protocole HTTP fonctionne.

Quelles sont les causes habituelles de l'échec de redirection d'un portail captif ?

Sept causes sont à l'origine de la plupart des cas. Elles se situent à différents niveaux, de l'adressage jusqu'à l'authentification.

La sonde du système d'exploitation est bloquée

La liste de contrôle d'accès (ACL) d'accès de pré-authentification de la passerelle rejette la sonde au lieu de la rediriger. L'appareil ne reçoit aucune réponse et en déduit qu'il n'y a pas d'accès Internet. Il n'ouvre jamais le portail.

Un service de filtrage DNS qui bloque les noms d'hôte des sondes produit le même effet. Il s'agit de la raison la plus courante pour laquelle un portail n'apparaît jamais.

HTTPS et HSTS interrompent l'interception

La fonctionnalité HSTS (HTTP Strict Transport Security), définie dans la norme RFC 6797, indique aux navigateurs d'accéder à un domaine uniquement via HTTPS. Les navigateurs sont livrés avec une liste de préchargement de domaines HSTS, incluant ceux de Google et de la plupart des banques. Lorsqu'un visiteur saisit google.com, le navigateur passe en HTTPS avant que la requête ne quitte l'appareil.

La passerelle ne peut pas rediriger cette requête sans présenter un certificat pour google.com, qu'elle ne possède pas. Le navigateur affiche alors un avertissement de sécurité bloquant sans possibilité de passer outre.

La solution consiste à rediriger uniquement les sondes HTTP en texte clair du tableau ci-dessus, qui existent exactement à cet effet. N'interceptez jamais HTTPS pour la redirection du portail captif.

Le jardin captif est trop restreint

Le jardin captif (« walled garden ») est la liste de domaines et d'adresses IP qu'un appareil peut atteindre avant de s'authentifier. Si une entrée est manquante, la page de connexion se charge partiellement ou l'étape d'identification échoue. Les oublis habituels sont :

• Les points de terminaison des fournisseurs d'identité pour la connexion via les réseaux sociaux ou le SSO, comme Microsoft Entra ID, Okta ou Google Workspace.
• Les domaines des réseaux de diffusion de contenu (CDN) qui hébergent les polices, scripts et feuilles de style de votre page de connexion.
• Les domaines des processeurs de paiement, si l'accès est payant.
• Le portail captif de Purple et les points de terminaison RADIUS, répertoriés dans le guide d'intégration de Purple pour votre matériel.

Le DNS échoue avant l'authentification

L'appareil doit résoudre le nom d'hôte du portail avant de pouvoir charger la page. La redirection ne mène nulle part dans deux cas :

• La passerelle bloque le DNS dans l'état de pré-authentification.
• Le serveur DHCP fournit un serveur DNS que l'appareil ne peut pas atteindre.

Android ajoute une particularité. Si un visiteur a défini un nom d'hôte DNS privé spécifique, Android attend du DNS over TLS sur le port 853. En mode automatique, il bascule sur le DNS classique.

La plage d'adresses DHCP est épuisée

Lorsque la plage d'adresses est épuisée, un nouvel appareil s'associe au point d'accès mais n'obtient aucune adresse IP. Windows s'attribue alors une adresse de liaison locale 169.254.x.x, et d'autres systèmes affichent un état d'auto-attribution similaire.

Sans adresse valide, l'appareil ne peut pas envoyer de sonde. Il semble connecté mais n'a pas accès à Internet. C'est la panne classique en heure de pointe dans les stades, centres de conférence et hubs de transport.

RADIUS ne délivre jamais l'Access-Accept

RADIUS (Remote Authentication Dial-In User Service) transmet la décision de connexion du serveur d'authentification à votre passerelle. Le serveur répond par Access-Accept ou Access-Reject, comme défini dans la norme RFC 2865. La passerelle ouvre alors l'accès ou le maintient fermé.

Un visiteur qui remplit le formulaire mais reste hors ligne signifie presque toujours que la passerelle n'a pas reçu le message Access-Accept. Les trois causes habituelles sont :

• Un secret partagé incorrect.
• Un pare-feu qui bloque le port UDP 1812 (authentification) ou UDP 1813 (comptabilité). Les RFC 2865 et RFC 2866 définissent ces ports.
• Une adresse de serveur incorrecte sur le contrôleur.

Le certificat propre au portail a expiré

Votre page de connexion est desservie via HTTPS. Si son certificat TLS expire, tous les navigateurs modernes bloquent la page avec un avertissement de sécurité. La redirection fonctionne parfaitement, mais le visiteur ne peut toujours pas se connecter.

Comment identifier la cause exacte ?

Examinez la pile dans l'ordre. Chaque vérification permet d'éliminer une couche ; arrêtez-vous donc à la première défaillance.

1. L'appareil possède-t-il une adresse IP valide ? Exécutez ipconfig /all sous Windows, ou vérifiez les détails du réseau sur un téléphone. Une adresse en 169.254.x.x, ou l'absence totale d'adresse, indique un problème DHCP. Vérifiez le taux d'utilisation de la plage d'adresses sur le serveur DHCP. Au-delà de 90 %, vous êtes proche de la saturation.
2. La résolution DNS fonctionne-t-elle ? Depuis un appareil situé sur le LAN virtuel invité (VLAN), un segment de réseau logiquement séparé, recherchez le nom d'hôte du portail. Si la recherche échoue, le DNS de pré-authentification est bloqué ou le serveur DNS attribué par le DHCP est incorrect.
3. La sonde reçoit-elle une réponse 302 ? Effectuez une capture de paquets sur le VLAN invité, ou accédez à l'une des URL de sonde HTTP. Vous devez observer la sonde, puis une réponse HTTP 302 pointant vers le portail. Une sonde sans réponse signifie que l'ACL la rejette. L'absence totale de sonde signifie que l'appareil pense être déjà en ligne, souvent en raison d'un état mis en cache. Oubliez le réseau et reconnectez-vous.
4. La page de connexion s'affiche-t-elle complètement ? Ouvrez les outils de développement du navigateur (F12) et observez l'onglet Réseau. Les requêtes bloquées vers des domaines tiers indiquent des oublis dans le walled garden.
5. La passerelle reçoit-elle un Access-Accept ? Consultez les journaux RADIUS du contrôleur. Une connexion réussie est suivie d'une requête Accounting-Request avec le statut Start. Si aucun enregistrement de comptabilité n'apparaît après la connexion, le chemin RADIUS est interrompu.

Comparez ensuite vos observations avec ce tableau.

Scénario concret : un centre de conférences de 1 500 places aux heures de pointe

Situation. Un centre de conférences exploitait son réseau pour les participants sur un seul sous-réseau /24 avec un bail DHCP de huit heures. Les présentations du matin se sont déroulées sans problème. Après le déjeuner, les participants arrivant pour les sessions de l'après-midi ont vu le message « connecté, pas d'internet ». Le centre d'assistance a considéré qu'il s'agissait d'une panne du portail et a redémarré le contrôleur à deux reprises.

Ce qui a été fait. La première étape du diagnostic a révélé que de nouveaux appareils conservaient des adresses 169.254.x.x. Un sous-réseau /24 offre 254 adresses utilisables, et le bail de huit heures gardait chaque adresse du matin réservée. L'équipe a fait passer le WiFi VLAN des participants sur un sous-réseau /21 et a réduit le bail à 30 minutes.

Résultat. Le nombre d'adresses utilisables est passé de 254 à 2 046, soit environ huit fois la capacité précédente. Une adresse laissée par un participant qui quitte les lieux retourne désormais dans le pool au bout de 30 minutes, et non plus huit heures. La correction n'a nécessité qu'une seule fenêtre d'intervention et aucun nouveau matériel.

Scénario concret : un hôtel de 200 chambres où les clients Android ne pouvaient pas se connecter

Situation. Après la refonte de la page de connexion, un hôtel de 200 chambres a reçu des réclamations à la réception de la part de clients Android. La plupart d'entre eux choisissaient l'option de connexion via Google. Le portail s'affichait, mais le bouton ne fonctionnait pas.

Ce qui a été fait. Le responsable informatique a testé le parcours sur un iPhone, un téléphone Android et un ordinateur portable Windows. Les outils de développement sur l'ordinateur portable ont montré des requêtes bloquées vers un réseau de diffusion de polices et vers les domaines de connexion de Google. La refonte avait ajouté ces deux éléments. L'équipe les a ajoutés au walled garden.

Résultat. La connexion via Google a fonctionné sur les trois appareils de test dès le premier nouveau test. La correction n'a nécessité que deux entrées dans le walled garden et aucun changement matériel.

Scénario concret : un réseau de 40 magasins après le renouvellement du pare-feu

Situation. Un détaillant a remplacé les pare-feux de 40 magasins pendant un week-end. Le lundi, les clients de chaque magasin mis à jour pouvaient remplir le formulaire de connexion, mais restaient hors ligne. Les magasins qui n'avaient pas encore été mis à jour fonctionnaient normalement.

Ce qui a été fait. L'étape 5 n'a trouvé aucun enregistrement de comptabilité provenant des magasins mis à jour. Le nouveau modèle de pare-feu refusait l'UDP sortant par défaut, bloquant les ports 1812 et 1813. L'équipe a ajouté des règles sortantes explicites au modèle et l'a déployé sur les 40 magasins.

Résultat. Les enregistrements de comptabilité sont réapparus dans chaque magasin après le déploiement. Le fait que seuls les magasins mis à jour soient en échec a permis de cibler directement le modèle et de mettre le WiFi WiFi hors de cause.

Comment résoudre le problème sur chaque système d'exploitation et contrôleur ?

La résolution sur le contrôleur suit le même schéma sur toutes les plateformes. Les corrections liées au système d'exploitation consistent principalement à savoir comment chacun d'eux se comporte.

Sur votre contrôleur

Purple s'exécute sous forme de superposition cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Le schéma de résolution est le même sur les huit :

1. Orientez le SSID invité vers l'URL externe du portail captif fournie dans votre guide d'intégration Purple, et désactivez tout portail captif local.
2. Redirigez le trafic HTTP non authentifié, y compris les requêtes de test, vers cette URL. Ne modifiez pas le trafic HTTPS.
3. Autorisez le DNS et le DHCP avant l'authentification.
4. Ajoutez les entrées du walled garden : les points de terminaison Purple, les points de terminaison du fournisseur d'identité et les domaines des ressources de la page de connexion.
5. Saisissez les adresses des serveurs RADIUS et le secret partagé issus de votre tableau de bord Purple. Confirmez ensuite que le pare-feu autorise le flux sortant UDP 1812 et 1813.

Les noms des menus varient selon le fournisseur et la version du micrologiciel, veuillez donc suivre le guide d'intégration Purple correspondant à votre plateforme. La documentation communautaire de Fortinet sur le flux du portail captif FortiGate constitue une référence utile côté fournisseur pour la séquence de redirection.

Sur iOS et macOS

Si l'assistant de réseau captif ne s'ouvre pas, oubliez le réseau dans les Réglages puis reconnectez-vous. Cela force l'envoi d'une nouvelle requête de test.

Les versions récentes d' iOS et macOS prennent également en charge l'API Captive Portal API. Elle permet au réseau d'annoncer son portail via l'option DHCP 114, définie dans la norme RFC 8910, ce qui réduit la dépendance à l'interception. Si l'assistant s'ouvre mais reste vide, vérifiez la présence des domaines de ressources dans le walled garden.

Sur Android

Android affiche une notification "Se connecter au réseau" lorsqu'il détecte un portail. Si la notification n'apparaît jamais, confirmez que la passerelle redirige connectivitycheck.gstatic.com au lieu de le bloquer.

Si un visiteur voit le message "Impossible d'accéder au serveur DNS privé", un nom d'hôte DNS privé strict est configuré sur son téléphone. Vous avez deux options :

• Autoriser le DNS sur TLS sur le port 853 avant l'authentification.
• Demander au visiteur d'éteindre le DNS privé ou de le régler sur automatique.

Sur Windows

Windows s'appuie sur la requête HTTP NCSI et son contrôle DNS. Si le portail ne s'ouvre pas automatiquement, naviguez vers n'importe quel site HTTP non sécurisé pour déclencher manuellement la redirection. Un message persistant "Pas d'accès Internet" après la connexion signifie généralement que la passerelle continue de rediriger la requête de test. Dans ce cas, la passerelle n'a pas appliqué le message Access-Accept.

Dans le navigateur

Formez le personnel d'accueil à orienter les visiteurs vers une adresse HTTP, et jamais vers un domaine HSTS tel que google.com. Firefox exécute sa propre requête de test vers detectportal.firefox.com, incluez donc cet hôte dans vos tests de redirection.

Comment éviter que les échecs de redirection du WiFi invité ne se reproduisent ?

La plupart des incidents récurrents proviennent de modifications et non de la configuration initiale. Une mise à jour du micrologiciel, un nouveau modèle de pare-feu, une refonte de la page de connexion ou un certificat arrivant à expiration échappent aux tests. Intégrez ces contrôles dans votre processus de gestion des changements :

• Testez sur trois plateformes après chaque modification. Utilisez un iPhone, un téléphone Android et un ordinateur portable Windows. Si une plateforme échoue alors que les autres réussissent, recherchez d'abord un oubli dans le walled garden.
• Dimensionnez pour les pics, pas pour la moyenne. Calculez le nombre maximal d'équipements simultanés et ajoutez une marge de sécurité. Les réseaux de visiteurs temporaires utilisent couramment des baux DHCP de 15 à 30 minutes.
• Définissez des sessions adaptées à la visite. Les établissements du secteur de l'hôtellerie et du commerce de détail définissent généralement des sessions de 24 heures, afin qu'un invité ne se connecte qu'une seule fois par séjour ou par visite.
• Suivez quotidiennement les volumes de connexion. WiFi Analytics de Purple répertorie les connexions par site. Une baisse soudaine sur un site vous avertit d'une défaillance du RADIUS ou du jardin clos, souvent avant même que les visiteurs ne se plaignent.
• Soumettez les certificats et les secrets partagés à la gestion des modifications. Notez la date d'expiration du certificat du portail. Stockez le secret partagé RADIUS dans un endroit où les équipes chargées du pare-feu et du contrôleur peuvent toutes deux le vérifier.
• Segmentez le trafic invité. Placez les invités sur leur propre VLAN. Le PCI DSS considère la segmentation comme le moyen de garder un réseau invité hors du périmètre de votre environnement de données de porteurs de cartes.
• Anticipez la randomisation MAC. Les récents systèmes iOS et Android utilisent une adresse MAC aléatoire pour chaque réseau, et certains modes la font pivoter au fil du temps. La mise en cache des sessions basée sur l'adresse MAC demandera alors aux visiteurs récurrents de se reconnecter.
• Recueillez correctement le consentement. Le GDPR exige un consentement éclairé et affirmatif pour les données marketing. Les opt-ins à choix conscient de Purple présentent un choix distinct pour chaque finalité.

Dispensez les visiteurs récurrents du portail captif

La solution la plus durable supprime totalement la redirection pour les visites répétées.

• Passpoint est la certification industrielle basée sur la spécification Hotspot 2.0. Elle permet à un appareil de rejoindre automatiquement un réseau à l'aide d'un profil stocké.
• OpenRoaming, géré par la Wireless Broadband Alliance, fédère les fournisseurs d'identités. Les identifiants existants d'un visiteur fonctionnent alors sur l'ensemble des sites participants.

Les deux utilisent la norme IEEE 802.1X pour le contrôle d'accès au réseau basé sur les ports, de sorte qu'il n'y a pas de portail susceptible de tomber en panne.

Le rôle de Purple

Guest WiFi de Purple fonctionne comme une superposition cloud indépendante du matériel, ce qui vous permet de corriger les erreurs de redirection dans la configuration, sans changer de matériel. Purple équipe plus de 80 000 sites actifs dans plus de 90 pays et gère 500 millions d'utilisateurs et de connexions par an. La plateforme affiche une disponibilité de 99,999 % et bénéficie des certifications ISO 27001, Cyber Essentials et B Corp. Elle est également conforme au GDPR et à la CCPA.

Lorsqu'un portail échoue, la cause est presque toujours locale : une règle de sonde, une entrée de walled garden, une plage DHCP ou une règle de pare-feu.

Les schémas se répètent selon les secteurs d'activité :

• Les hôtels subissent des erreurs de redirection lors des pics d'enregistrement.
• Les réseaux du commerce de détail les subissent après des modifications de pare-feu à l'échelle du réseau.
• Les trains et les gares font face à une forte pression DHCP lorsque les passagers embarquent par vagues.
• Les établissements de santé ont besoin d'un WiFi qui fonctionne sans solliciter le personnel clinique pour des appels d'assistance.

Foire aux questions

La solution Purple fonctionne-t-elle avec les points d'accès dont nous disposons déjà ?

Oui. Purple est indépendante du matériel et s'exécute sous forme de superposition cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Vous conservez vos points d'accès et vos contrôleurs existants. Vous pointez votre SSID invité vers le portail captif de Purple, ajoutez les entrées du walled garden et les détails RADIUS du guide d'intégration de Purple, puis vous testez. Aucun remplacement de matériel n'est nécessaire.

Devons-nous acheter du nouveau matériel pour résoudre le problème de WiFi connecté mais sans Internet ?

Non. Dans la quasi-totalité des cas, le problème provient de la configuration : une sonde bloquée, une lacune dans le walled garden, un DNS de pré-authentification, une plage DHCP épuisée ou une règle de pare-feu RADIUS. Vous corrigez chaque point sur le contrôleur, le pare-feu ou le serveur DHCP que vous utilisez déjà. Le matériel ne devient une cause de problème que lorsque la densité de points d'accès ne permet pas de gérer le nombre maximal d'équipements, ce qu'une étude de site permettra de vérifier.

Que faut-il pour migrer notre WiFi vers Purple ?

Migrer vers Purple est un projet de configuration, pas un projet d'installation. Sur chaque contrôleur, vous configurez le SSID invité vers le portail externe de Purple et vous ajoutez les paramètres du walled garden et de RADIUS. Vous confirmez ensuite les règles de pare-feu pour les ports UDP 1812 et 1813. Ensuite, vous créez votre page de connexion et vos options de consentement dans Purple, puis vous testez sur iOS, Android et Windows. Les réseaux multi-sites peuvent modéliser les paramètres du contrôleur.

Un portail captif est-il conforme au GDPR ?

Oui, à condition que le consentement soit éclairé, spécifique et librement donné. Le GDPR exige un choix affirmatif distinct pour chaque finalité, comme les e-mails marketing, et interdit les cases précochées. Les options d'adhésion par choix conscient de Purple présentent chaque choix séparément. Purple est certifiée ISO 27001, détient Cyber Essentials et est conforme au GDPR et au CCPA. Cela fournit à votre délégué à la protection des données les normes qu'il exigera.

Les visiteurs déjà venus peuvent-ils ignorer la page de connexion ?

Oui. Passpoint et OpenRoaming permettent à un équipement de se connecter automatiquement à l'aide d'un profil stocké ou d'une identité fédérée. Tous deux utilisent l'authentification IEEE 802.1X avec un chiffrement WPA2 ou WPA3-Enterprise, ce qui évite toute redirection de portail captif susceptible d'échouer lors des visites répétées. De nombreux établissements utilisent les deux : un portail captif pour les nouveaux visiteurs et la collecte de données, et OpenRoaming pour les clients réguliers, les passagers et les étudiants.

Comment saurons-nous si les connexions commencent à échouer ?Suivez les volumes de connexion par établissement. Les rapports d'analyse WiFi de Purple indiquent les connexions pour chaque site, de sorte qu'une chute soudaine sur un emplacement se démarque par rapport à son comportement normal et à vos autres sites. Cette baisse signale généralement un problème de RADIUS, de walled garden ou de DHCP introduit par une modification récente. La repérer dans le tableau de bord est plus rapide que d'attendre que les réclamations de l'accueil ne parviennent au service informatique.

Faut-il utiliser un portail captif ou un mot de passe WiFi partagé ?

Utilisez un portail captif si vous souhaitez obtenir des données first-party et le consentement des utilisateurs, et un mot de passe partagé uniquement si vous n'avez besoin ni de l'un ni de l'autre. Une clé prépartagée sécurise le trafic avec WPA2 ou WPA3-Personal. Cependant, elle ne vous donne aucune information sur l'identité des personnes connectées et le mot de passe finit par circuler. Un portail captif collecte des données first-party consenties, tandis que Passpoint ou OpenRoaming ajoute un accès automatique et chiffré pour les visites ultérieures.