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.

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é

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.

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.

Ces décisions sont importantes en production :

• Laisser Use insecure HTTP instead of HTTPS désactivé. HTTP transmet les identifiants sans chiffrement et ne fonctionne pas avec Entra ID SSO.
• 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 convient mieux si la session doit prendre fin après une durée d’inactivité définie.
• Never exige une déconnexion manuelle et peut conserver plus longtemps des associations utilisateur-IP obsolètes.

Il n’existe pas de timeout universel. Des sessions courtes sont plus importantes sur les appareils partagés et lorsque les utilisateurs changent ; sur les appareils personnels, l’authentification peut être moins intrusive. Tester chaque choix avec la veille, un changement de Wi-Fi et la déconnexion manuelle. Ces options locales ne s’appliquent pas à Entra ID SSO.

Enregistrer avec Apply.

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. Utiliser l’URL FQDN pour valider le nom du certificat et la chaîne de confiance.

Les paramètres se trouvent sous Administration > Admin and user settings > Admin console and end-user interaction. Sous Redirect users, choisir Firewall’s configured hostname ou A different hostname ; pour l’exemple, saisir login.example.com. Sous Certificate, sélectionner le certificat couvrant ce nom. Cette sélection affecte aussi les autres portails locaux. Vérifier donc WebAdmin, User Portal et VPN Portal avant de la modifier.

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 ; 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, la fenêtre du portail ouverte, la veille, les changements de réseau et l’inactivité. 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