Configurer et tester Captive Portal sur Sophos Firewall

Le Captive Portal authentifie les utilisateurs déjà connectés à un réseau LAN ou Wi-Fi. Sophos Firewall peut ensuite associer leur trafic à une identité et appliquer des règles à certains utilisateurs ou groupes.

L’interaction des composants est importante : le portail crée l’association avec l’utilisateur, mais n’autorise pas lui-même l’accès à Internet. Une règle de pare-feu adaptée est également nécessaire. DNS, routage, NAT et segmentation du réseau doivent fonctionner indépendamment.

La procédure complète se résume en six étapes :

1. Vérifier la source d’authentification et le groupe autorisé.
2. Autoriser Captive Portal pour la zone client sous Administration > Device access.
3. Avec un serveur DNS externe, créer une règle DNS restreinte sans condition utilisateur.
4. Créer une règle utilisateur avec Match known users et Use web authentication for unknown users.
5. Définir HTTPS, la page de destination et la déconnexion sous Authentication > Web authentication.
6. Contrôler la connexion sur le port 8090, l’utilisateur sous Live users et la Rule ID dans Log Viewer.

Ce que fait Captive Portal – et ce qu’il ne fait pas

Captive Portal convient aux appareils BYOD, aux clients non administrés ou aux réseaux sans détection transparente des utilisateurs. L’utilisateur ouvre une page Web, est redirigé vers la connexion, puis est associé à son adresse IP source sur le pare-feu. Celui-ci peut utiliser cette identité comme critère de correspondance.

Les autres portails et méthodes d’authentification répondent à d’autres besoins :

• Un Wireless Hotspot est destiné aux accès invités avec vouchers, mot de passe quotidien ou conditions d’utilisation. La procédure complète figure dans Configurer Sophos Firewall Hotspot.
• Un Guest user est un compte local temporaire pour le Captive Portal. Créer et exploiter en toute sécurité des utilisateurs invités explique le groupe, la validité, la remise des identifiants, l’inscription autonome et la purge.
• Le VPN Portal appartient à Remote Access. Captive Portal n’établit aucun tunnel VPN et ne doit pas servir de portail de connexion public.
• STAS, AD SSO ou SATC identifient si possible les utilisateurs sans connexion dans le navigateur. Captive Portal peut servir de solution de repli pour les appareils que la détection transparente ne reconnaît pas.
• Pour une connexion Microsoft, suivre la procédure distincte Captive Portal avec Microsoft Entra ID SSO.

L’aperçu des portails Sophos aide à distinguer User Portal, VPN Portal, WebAdmin et Captive Portal.

⚠️ Captive Portal ne remplace pas la segmentation. Un réseau BYOD ou invité reste dans une zone ou un VLAN distinct et n’accède qu’aux destinations et services nécessaires. La connexion améliore l’attribution des utilisateurs, mais ne sécurise pas automatiquement un réseau trop permissif.

Conditions requises et exemple

Les points suivants doivent être établis avant la configuration :

• Une source d’authentification locale ou externe fonctionne. Pour Active Directory, la connexion au serveur et le groupe ont déjà été testés ; Connecter Active Directory à Sophos Firewall explique la configuration.
• La zone client, le réseau source et le groupe d’utilisateurs autorisé sont connus.
• Le client reçoit une adresse IP, une passerelle et des serveurs DNS corrects.
• Un enregistrement DNS et un certificat accepté par les clients existent pour le nom de portail de production.
• Une règle MASQ/SNAT existante et le routage couvrent le trafic Internet qui sera ensuite autorisé.
• Un utilisateur autorisé et un utilisateur non autorisé sont disponibles pour la recette.

L’exemple utilise :

• Zone client : LAN
• Réseau client : 10.30.40.0/24
• Objet réseau : BYOD_10.30.40.0_24
• IP du pare-feu dans la zone client : 10.30.40.1
• Groupe d’utilisateurs : BYOD_Internet
• Nom de règle : LAN-BYOD-to-WAN-Captive
• Serveur DNS interne : 10.20.0.53
• Nom du portail : login.example.com

Ne pas reprendre ces valeurs sans les vérifier. La zone et le réseau doivent correspondre à l’interface client réelle, 10.30.40.1 doit être remplacée par son IP de pare-feu et le groupe doit provenir de la source d’authentification utilisée. Depuis le réseau client, le nom du portail doit pointer exactement vers cette adresse accessible du pare-feu.

Configurer Captive Portal étape par étape

1. Sélectionner la méthode d’authentification

Sous Authentication > Services, Firewall authentication methods définit les sources interrogées par le pare-feu lors de la connexion. Il peut s’agir de la base locale ou d’un serveur AD, LDAP ou RADIUS déjà configuré. Créer et tester des utilisateurs locaux normaux décrit le groupe, le mot de passe, Local, Sign-in Restriction et le cycle de vie de ce modèle. L’ordre est important : avec plusieurs serveurs, SFOS les vérifie de haut en bas.

Dans l’exemple, le groupe BYOD_Internet doit exister sur le pare-feu. Avec Active Directory, l’importer au préalable. Il peut alors être sélectionné dans la règle utilisateur et attribué sans ambiguïté pendant le test.

Une connexion réussie au serveur ne suffit pas. Une véritable connexion au portail vérifiera ensuite que mot de passe, groupe et règle utilisateur fonctionnent ensemble.

2. Autoriser Captive Portal pour la zone source

Sous Administration > Device access, dans la ligne Captive portal, n’activer que les zones depuis lesquelles les utilisateurs doivent réellement se connecter. Dans l’exemple, il s’agit de LAN. Enregistrer avec Apply.

Device Access contrôle l’accès à un service local du pare-feu. Une règle LAN-to-WAN normale ne remplace pas cette autorisation. Inversement, Captive Portal ne doit pas être activé par précaution pour WAN ou pour des zones internes non concernées. Device Access et Local Service ACL explique aussi l’exception du Web Proxy qui peut rendre les portails locaux accessibles malgré une table de zones plus restrictive.

Si les clients utilisent le pare-feu comme résolveur DNS, DNS doit aussi être autorisé pour leur zone dans la même matrice. Avec un serveur DNS distinct, la règle de transit suivante est nécessaire.

3. Autoriser DNS avant la connexion

Le navigateur ne peut ouvrir login.example.com ou le site demandé que si DNS fonctionne avant l’authentification. Si le serveur DNS n’est pas sur le pare-feu, créer une règle sous Rules and policies > Firewall rules > Add firewall rule > New firewall rule :

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: zone du serveur DNS
• Destination networks: objet hôte pour 10.20.0.53
• Services: DNS
• Log firewall traffic: activer pour la recette

Cette règle n’a aucune condition utilisateur, car le client n’est pas encore authentifié. Elle autorise uniquement DNS vers le résolveur prévu, et non un trafic arbitraire avant la connexion. Si plusieurs serveurs DNS sont utilisés, ajouter explicitement leurs objets hôtes.

Positionner la règle DNS de manière à atteindre le résolveur avant la connexion. Dans l’exemple, elle se trouve juste avant la règle utilisateur et au-dessus de toute règle plus générale qui rejetterait ou traiterait autrement le DNS de ce réseau. Enregistrer avec Save.

Au-dessus de la table des règles, sélectionner le protocole concerné, IPv4 ou IPv6. Si les clients joignent le résolveur uniquement en IPv4, la règle DNS IPv4 suffit. Si DNS est également utilisé en IPv6, créer une règle IPv6 tout aussi restrictive avec les objets réseau et hôte IPv6 appropriés.

4. Créer la règle utilisateur

Créer maintenant la règle d’accès proprement dite :

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: les destinations Internet nécessaires ou Any
• Services: uniquement les services nécessaires
• Match known users: activé
• Use web authentication for unknown users: activé
• Users or groups: BYOD_Internet
• Log firewall traffic: activé

Ici aussi, sélectionner IPv4 ou IPv6 au-dessus de la table des règles. Dans un réseau dual stack, créer une règle utilisateur distincte, avec les objets réseau adaptés, pour chaque famille de protocoles réellement autorisée ; une règle IPv4 ne couvre pas IPv6.

Match known users transforme l’identité en critère de correspondance. Use web authentication for unknown users redirige vers la connexion une requête Web correspondante dont l’utilisateur n’est pas encore authentifié. Le groupe détermine qui peut utiliser la règle après la connexion.

Dans SFOS 22 et 23, Use web authentication for unknown users n’est pas le seul déclencheur d’une connexion. Si cette option est activée, une requête Web correspondante dont l’utilisateur n’est pas encore authentifié déclenche l’authentification. Si elle est désactivée, ce paramètre autorise d’abord la requête sans connexion ; une Web Policy attribuée peut toutefois encore la bloquer et ainsi déclencher l’authentification Web. Le point déterminant est de savoir si une Web Policy pour les utilisateurs ou groupes inconnus est définie sur Block. La suite dépend d’AD SSO :

• Avec AD SSO, aussi bien lorsque la règle déclenche l’authentification qu’en cas de Block par la Web Policy des utilisateurs inconnus : SFOS tente d’abord une connexion transparente. Si elle échoue, une redirection vers Captive Portal suit. Après une connexion réussie, la page est rechargée et la Web Policy de l’utilisateur est réévaluée.
• Sans AD SSO, avec déclenchement par la règle : la requête Web correspondante dont l’utilisateur n’est pas encore authentifié est directement redirigée vers Captive Portal.
• Sans AD SSO, avec uniquement un blocage par la Web Policy : une page de blocage s’affiche. Un lien vers Captive Portal peut y apparaître ; il ne faut pas s’attendre ici à une redirection automatique comme lors du déclenchement par la règle.

En cas de connexion inattendue ou de page de blocage, vérifier donc d’abord conjointement la règle qui traite réellement le trafic dans Log Viewer, le paramètre de cette règle, la Web Policy pour les utilisateurs ou groupes inconnus et l’état d’AD SSO sous Authentication > Web authentication. Avant toute modification, consigner les valeurs actuelles. Effectuer la vérification avec un client pilote sans session existante et uniquement pour l’accès prévu pour ce client : ne pas supprimer globalement Block, assouplir les règles utilisateur ou modifier AD SSO globalement dans le seul but de forcer une redirection. Après la connexion, contrôler Current activities > Live users, l’utilisateur et la Rule ID dans Log Viewer, ainsi qu’une destination autorisée et une destination qui doit rester bloquée. En cas de comportement inattendu, rétablir les valeurs modifiées et répéter les mêmes vérifications.

Pour Services, Any n’est pertinent que si le groupe doit réellement obtenir un accès Internet complet. Pour un accès plus étroit, sélectionner explicitement HTTP, HTTPS et les autres protocoles nécessaires. Un trafic non Web ne peut pas afficher de page de connexion ; l’utilisateur doit d’abord s’authentifier dans un navigateur ou via l’URL directe du portail.

La règle doit se trouver au-dessus d’une règle Allow générale basée sur IP. Sinon, cette règle antérieure traite déjà le trafic et la règle utilisateur n’est jamais atteinte. Après avoir vérifié sa position, enregistrer avec Save. Planifier correctement les règles de pare-feu explique l’évaluation de base.

5. Définir HTTPS, la redirection et la déconnexion

Authentication > Web authentication n’active pas l’accessibilité du portail, mais configure son comportement.

Captive Portal accepte au maximum 50 caractères pour le nom d’utilisateur et 50 pour le mot de passe. Cette limite doit être testée avec un compte réel avant le déploiement, surtout avec des annuaires externes et des noms d’utilisateur générés automatiquement.

Ces décisions sont importantes en production :

• Show user portal link affiche sur la page Captive Portal un lien vers User Portal. Ne l’activer que si les utilisateurs ont réellement besoin de ce portail et s’il doit être accessible depuis leur zone.
• Use insecure HTTP instead of HTTPS reste désactivé. HTTP transmettrait les identifiants sans chiffrement. SFOS 22 ne prend pas en charge Microsoft Entra ID SSO avec cette option ; dans SFOS 23, cette restriction s’applique à OpenID Connect SSO dans son ensemble.
• Show web page after sign-in peut rediriger l’utilisateur vers la page initialement demandée ou vers une page interne définie.
• Open web page: In new browser window laisse la page Captive Portal ouverte pour le logout et les keepalives. Si le même onglet est remplacé, la déconnexion est moins visible.
• When captive portal page is closed or redirected déconnecte l’utilisateur quand le pare-feu ne reçoit plus de keepalives. Cela peut aussi se produire après une veille ou un changement de réseau.
• When user is inactive évalue une période et le volume de données transféré pendant celle-ci. SFOS déconnecte un utilisateur dont le trafic reste sous le seuil configuré. Choisir la période et le volume de sorte que le trafic normal en arrière-plan ne maintienne pas indéfiniment toutes les sessions obsolètes.
• Never exige une déconnexion manuelle et peut conserver plus longtemps des associations utilisateur-IP obsolètes.

Il n’existe pas de timeout universellement adapté. Des sessions plus courtes sont plus importantes sur les appareils partagés et lorsque les utilisateurs changent ; sur les appareils attribués personnellement, la connexion peut être moins intrusive. Tester chaque choix avec la veille, un changement de Wi-Fi et la déconnexion manuelle. Ces options locales de déconnexion ne s’appliquent pas à Microsoft Entra ID SSO dans SFOS 22, ni à OpenID Connect SSO dans son ensemble dans SFOS 23.

Avant la recette, consigner la version de SFOS déployée et la méthode de connexion. Pour ces connexions SSO, les options locales de déconnexion mentionnées ne constituent pas un levier adapté pour remédier aux déconnexions inattendues ; cette exception ne permet de déduire ni une session illimitée ni un timeout particulier de l’IdP. Le test SSO reste en HTTPS avec un certificat valide et approuvé. Ne pas activer HTTP, même pour le diagnostic. Vérifier la connexion, l’association visible avec l’utilisateur et la déconnexion avec un compte pilote dans le parcours SSO réellement utilisé, plutôt que de présumer l’effet des paramètres locaux de déconnexion.

En outre, Authentication > Services > Global settings > Maximum session timeout limite la durée totale des utilisateurs connectés. SFOS vérifie l’autorisation toutes les trois minutes ; Access Policies, Surfing Quota et la limite de transfert de données peuvent également mettre fin à une session. Cette valeur globale ne concerne pas uniquement Captive Portal : vérifier les autres méthodes d’authentification avant de la modifier.

Enregistrer avec Apply.

La Device Console contient aussi des valeurs globales pour les versions TLS minimales de Captive Portal, X-Frame-Options et une chaîne de chiffrement partagée avec Web Proxy. Vérifier les paramètres HTTP Proxy en toute sécurité explique pourquoi ces valeurs ne constituent pas une liste d’optimisation et comment tester puis annuler une modification sur le portail et le proxy.

Sous Captive portal appearance, il est possible de personnaliser le logo, les textes et les couleurs. Si Custom HTML remplace la mise en page par défaut, le marqueur <div id="__loginbox"></div> ainsi que le bloc request-url imposé par Sophos et son script de redirection doivent rester fonctionnels. Le code HTML, CSS ou JavaScript personnalisé est donc testé d’abord avec Preview, puis avec un compte pilote. Un portail visuellement correct ne constitue pas un succès si le modèle empêche la connexion, la redirection ou la déconnexion ; Reset to default permet d’annuler la personnalisation.

<div id="__loginbox"></div>
<div id="request-url" style="display:none;">{url}</div>
<script>
var redirect_url = document.getElementById("request-url").innerHTML;
</script>

La partie script doit être placée immédiatement avant </body>.

6. Vérifier le nom et le certificat du portail

L’URL directe de diagnostic est :

https://<Firewall-IP>:8090

Dans l’exemple, ouvrir d’abord https://10.30.40.1:8090. En production, https://login.example.com:8090 est plus compréhensible si le nom pointe vers le pare-feu et figure dans le certificat.

L’ouverture de l’URL avec l’IP prouve que le portail est accessible. Toutefois, si le certificat sélectionné couvre uniquement login.example.com, le navigateur affiche normalement un avertissement de non-concordance du nom pour https://10.30.40.1:8090. Ne saisir aucun identifiant après avoir contourné cet avertissement. Utiliser l’URL FQDN pour valider le nom du certificat et la chaîne de confiance.

Accéder à Administration > Admin and user settings. Avant toute modification, noter la valeur actuelle de Redirect users et le Certificate sélectionné. Dans Admin console and end-user interaction, choisir ensuite Firewall’s configured hostname ou A different hostname sous Redirect users ; pour l’exemple, saisir login.example.com. Sous Certificate, sélectionner le certificat couvrant ce nom. Utiliser Check settings pour tester la redirection avant le déploiement. Cette sélection affecte aussi les autres portails locaux. Vérifier donc WebAdmin, User Portal et VPN Portal après la modification.

Si l’un de ces tests échoue, sélectionner de nouveau la valeur de redirection notée et le certificat précédent, puis enregistrer avec Apply. Tester ensuite à nouveau la redirection et les portails.

Un certificat publiquement approuvé évite les avertissements sur les appareils non administrés. Avec une CA interne ou signée par le pare-feu, la CA doit être installée comme fiable sur tous les clients. Gérer les certificats sur Sophos Firewall explique le nom, la chaîne complète et l’attribution sécurisée.

Tester complètement la connexion et la règle utilisateur

La recette commence avec un client sans session existante. Sous Current activities > Live users, une ancienne session de test peut être déconnectée.

1. Vérifier que le client possède une adresse de 10.30.40.0/24, la passerelle prévue et le bon serveur DNS.
2. Ouvrir directement https://10.30.40.1:8090 ou l’URL FQDN préparée. L’URL avec l’IP teste l’accessibilité du portail indépendamment de la redirection automatique, mais peut provoquer un avertissement de non-concordance si le certificat couvre uniquement login.example.com. Utiliser l’URL FQDN pour valider le certificat.
3. Sans session, ouvrir une page HTTP ordinaire et vérifier la redirection vers Captive Portal. Une page HTTPS avec un comportement HSTS mémorisé ne constitue pas un test fiable.
4. Se connecter avec un utilisateur autorisé. Si Sophos MFA local est activé, le jeton OTP doit d’abord être enregistré dans User Portal. Activer MFA pour Sophos Firewall explique la configuration.
5. Sous Current activities > Live users, vérifier le nom d’utilisateur, l’IP client et le type d’authentification.
6. Tester un site autorisé, puis volontairement une destination ou un service non autorisé.
7. Dans Log Viewer, filtrer par l’IP client. L’entrée doit afficher l’utilisateur attendu et la Rule ID de LAN-BYOD-to-WAN-Captive.
8. Avec un utilisateur hors de BYOD_Internet, vérifier que la connexion ne donne aucun accès via cette règle.
9. Déclencher la déconnexion, la veille ou un changement de réseau, puis vérifier quand l’utilisateur disparaît de Live users.

Dans un réseau dual stack, effectuer le test séparément pour IPv4 et IPv6. SFOS conserve les deux associations utilisateur séparément et les deux variantes exigent des règles de pare-feu adaptées ; un test IPv4 réussi ne prouve donc pas le fonctionnement d’IPv6.

Cerner les erreurs courantes

Le portail n’apparaît pas

Ouvrir d’abord l’URL directe sur le port 8090. Si elle est inaccessible, vérifier la zone source et Captive portal sous Device Access, l’IP client, l’affectation des zones, DNS et le FQDN du portail.

Si l’URL directe fonctionne mais pas la connexion automatique, une règle plus générale traite souvent le trafic en premier ou Use web authentication for unknown users manque. De plus, seule une requête Web correspondante peut déclencher la connexion ; les applications non Web n’affichent aucune page Captive Portal.

La connexion est refusée

Sous Authentication > Services, vérifier la source d’authentification et l’ordre. Contrôler ensuite la connexion au serveur, le mot de passe, le groupe, le quota et, avec MFA local, l’enregistrement OTP terminé. Les plages d’accès récurrentes autorisées ou bloquées sont vérifiées séparément avec Access Time pour les utilisateurs et les groupes. La procédure de Surfing Quota et Network Traffic Quota montre si le temps Internet ou le volume de données consommé est plutôt épuisé.

Si l’erreur ne se situe pas clairement au niveau du portail, Résoudre méthodiquement les erreurs d’authentification sur Sophos Firewall sépare l’accessibilité, la sélection du service, Live Users, la Main Group et le chemin de trafic ultérieur.

Pour les connexions classiques, access_server.log est pertinent. oauth_sso_captive.log ne sert qu’à Microsoft Entra ID SSO. Service Logs de Sophos Firewall explique comment lire ces fichiers sans redémarrer les services prématurément.

Connexion réussie, mais aucun accès

Une connexion réussie confirme uniquement l’authentification. Zone client, réseau source, groupe, destinations, services, position de la règle, NAT et routage doivent aussi correspondre. Log Viewer indique quelle Rule ID traite réellement le trafic. Pourquoi une règle Sophos Firewall ne correspond pas propose une vérification systématique.

L’utilisateur est déconnecté de manière inattendue

Vérifier l’option de sign-out et ses seuils de temps et de données, la fenêtre du portail ouverte, la veille, les changements de réseau et l’inactivité. Contrôler aussi Maximum session timeout sous Authentication > Services > Global settings, ainsi qu’Access Time, Surfing Quota et Network Traffic Quota. Avec When captive portal page is closed or redirected, l’association prend fin après l’arrêt des keepalives ; cela peut ne pas être visible au moment de fermer la fenêtre.

La page de connexion n’apparaît qu’après environ deux minutes

Si STAS est utilisé sur le même réseau, sa phase d’apprentissage peut retarder la redirection. Vérifier d’abord l’état de STAS et les clients non authentifiés. La procédure générale ne modifie pas de valeur CLI globale pour cela ; l’article STAS explique la relation.

Plusieurs utilisateurs partagent la même IP source

Captive Portal associe généralement l’identité utilisateur à une IP cliente. Les adresses saisies sous Multi-user hosts pour Per-Connection AD SSO via le Direct Web Proxy ne peuvent donc pas utiliser Captive Portal. Per-Connection AD SSO pour les hôtes multi-utilisateurs explique la procédure appropriée et la règle distincte sans Match known users pour le trafic restant.

Questions fréquentes