Chapitre 1111 minIntermédiaire
Portail captif pfSense et Wi-Fi invité
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- concevoir l'architecture d'un Wi-Fi invité isolé ;
- expliquer comment un portail captif intercepte la première requête ;
- créer une zone de portail, générer des tickets et écrire les règles ;
- limiter le débit des invités et dépanner un portail qui ne s'affiche pas.
3 exercices corrigés
Un portail captif est une page web que le pare-feu impose à tout appareil qui se connecte à un réseau, avant de lui ouvrir l'accès à Internet : acceptation des conditions d'utilisation, code d'accès (voucher) ou identifiant. Sur pfSense, il s'active par zone, sur une ou plusieurs interfaces. Ce chapitre construit le Wi-Fi invité de Sorbier de bout en bout : borne, VLAN, adressage, portail, tickets, règles, limites de débit et points de vigilance.
L'architecture du Wi-Fi invité
| Élément | Chez Sorbier | Pourquoi |
|---|---|---|
| SSID | Sorbier-Invites, distinct du SSID des salariés | Les invités ne se connectent jamais au réseau interne |
| VLAN | 40 VISITEURS, étiqueté par les bornes sur leur port trunk | Le trafic invité est séparé dès la borne |
| Isolation des clients | Activée sur les bornes | Deux invités ne peuvent pas se joindre (ni s'attaquer) |
| Passerelle | pfSense, 192.168.10.62 | Tout le trafic invité est filtré et journalisé par le pare-feu ; aucun équipement interne ne le route |
| DHCP | Étendue VLAN40-VISITEURS de l'annuaire, relayée par pfSense, bail de 4 heures | Chapitre 8 |
| DNS | Le résolveur de pfSense | Les invités ne connaissent pas les noms internes |
| Accès à Internet | Après passage par le portail captif, aux heures d'ouverture | Traçabilité, conditions d'utilisation, durée limitée |
La sécurité du Wi-Fi d'entreprise (WPA3, 802.1X, RADIUS) et les obligations légales liées à un accès offert au public sont traitées dans le cours Cybersécurité des infrastructures ; le contrôle d'accès au réseau dans le chapitre 802.1X, RADIUS et portail captif du cours Authentification.
Comment fonctionne un portail captif
- Le téléphone d'un visiteur rejoint
Sorbier-Invites, obtient une adresse par DHCP et le DNS du pare-feu. - pfSense laisse passer le DNS (règle de l'onglet VISITEURS) mais bloque tout le reste tant que l'appareil n'est pas authentifié.
- Les systèmes récents testent la connectivité dès la connexion, en demandant une page HTTP connue (Windows, Android et iOS ont chacun leur adresse de test). pfSense intercepte cette requête HTTP et répond par une redirection vers la page du portail : le système ouvre alors la page automatiquement.
- Le visiteur saisit son ticket ou accepte les conditions. pfSense enregistre l'appareil (adresse IP et adresse MAC) comme authentifié, pour une durée limitée.
- L'appareil navigue, dans la limite des règles de l'onglet VISITEURS. À l'expiration, il est déconnecté et repasse par le portail.
La redirection ne fonctionne proprement qu'en HTTP : intercepter une connexion HTTPS provoquerait une erreur de certificat, puisque le pare-feu n'a pas le certificat du site demandé. C'est pourquoi les systèmes utilisent une adresse de test en HTTP, et pourquoi un navigateur ouvert directement sur un site en HTTPS n'affiche pas le portail : il faut attendre la fenêtre du système ou visiter une page en HTTP.
Créer la zone
Services > Captive Portal > Add, Zone name visiteurs, une description, Save & Continue. Puis, dans l'onglet Configuration de la zone :
| Champ | Valeur chez Sorbier | Remarque |
|---|---|---|
| Enable | Coché | |
| Interface | VISITEURS | Jamais le WAN |
| Maximum concurrent connections | 4 (défaut) | Par adresse IP |
| Idle timeout (Minutes) | 30 | Un appareil inactif depuis 30 minutes est déconnecté |
| Hard timeout (Minutes) | 240 | Déconnexion au bout de 4 heures, quoi qu'il arrive ; aligné sur la durée du bail DHCP |
| Pre-authentication redirect URL | Vide | |
| After authentication Redirection URL | https://www.sorbier.example/bienvenue | Sinon, le visiteur est renvoyé vers la page qu'il demandait |
| Concurrent user logins | Disabled | Un ticket ne sert qu'à un appareil à la fois |
| Per-user bandwidth restriction | 10 000 Kbit/s en réception, 2 000 en émission | Un visiteur ne sature pas la connexion du siège |
| Use custom captive portal page | Oui | Une page aux couleurs de Sorbier, avec la charte d'utilisation (onglet File Manager pour les images) |
| Authentication Method | Use an Authentication backend, base locale | Avec les tickets activés (voir plus bas) |
| HTTPS Options | Login coché, nom portail.sorbier.example, certificat de ce nom | La saisie du ticket se fait en HTTPS |
Trois méthodes d'authentification existent :
| Méthode | Ce que fait le visiteur | Quand la choisir |
|---|---|---|
| None, don't authenticate users | Clique sur « J'accepte » | Un accès libre où l'on veut seulement faire accepter des conditions |
| Use an Authentication backend | Saisit un identifiant et un mot de passe (base locale, LDAP, RADIUS), ou un ticket | Le cas général ; avec tickets pour des visiteurs ponctuels |
| Use RADIUS MAC Authentication | Rien : son adresse MAC est envoyée comme identifiant à un serveur RADIUS | Des appareils connus à l'avance, sans écran |
Les tickets
Les tickets (vouchers) sont des codes à usage unique, valables pour une durée fixée, imprimés à l'avance et remis par l'accueil. Ils évitent de créer un compte par visiteur et de communiquer un mot de passe partagé.
Dans l'onglet Vouchers de la zone : coche Enable the creation, generation and activation of rolls with vouchers, garde la paire de clés générée (elle signe les tickets), puis crée un rouleau (roll) : un numéro, une durée par ticket en minutes, un nombre de tickets, un commentaire. Le rouleau s'exporte en fichier CSV, que l'accueil imprime. La page du portail affiche alors un champ pour le code.
Status > Captive Portal liste les appareils connectés (adresse IP, adresse MAC, utilisateur ou ticket, heure de connexion), permet d'en déconnecter un, et son onglet Test Vouchers vérifie la validité d'un code.
Les règles de l'onglet VISITEURS
Reprises du chapitre 5, avec leur raison d'être :
| N° | Action | Proto | Source | Destination | Port | Rôle |
|---|---|---|---|---|---|---|
| auto | Pass | UDP | any | 255.255.255.255 | 67 | Demandes DHCP vers le relais (règle du relais) |
| auto | Pass, redirection, Block | Règles du portail captif | ||||
| 1 | Pass | TCP/UDP | VISITEURS subnets | VISITEURS address | 53 | DNS, nécessaire avant l'authentification |
| 2 | Reject | Any | VISITEURS subnets | This Firewall (self) | Ni interface web, ni autre service du pare-feu | |
| 3 | Reject | Any | VISITEURS subnets | RESEAUX_INTERNES | Isolation complète du réseau interne | |
| 4 | Pass | TCP | VISITEURS subnets | any | PORTS_WEB | Navigation des appareils authentifiés, horaire « Ouverture » |
| 5 | Block | Any | any | any | Tout le reste, journalisé |
La règle 3 vient avant la règle 4 : sans elle, « 443 vers any » donnerait accès aux serveurs web internes. La règle 2 protège l'interface d'administration, joignable sinon par l'adresse publique du pare-feu.
Limiter la bande passante de tout le réseau invité
La limite par utilisateur du portail ne suffit pas si trente visiteurs se connectent pendant une formation. Firewall > Traffic Shaper > Limiters crée des limiteurs : une paire (réception, émission) à 50 Mbit/s, par exemple, que l'on choisit dans les options avancées de la règle 4 (champs In / Out pipe). Tout le trafic invité qui passe par cette règle partage alors 50 Mbit/s, et les salariés gardent leur débit.
Exercices
Exercice 1 sur 3 Le portail ne s'affiche pas Réussi À revoir
Après la mise en service, les visiteurs se connectent au Wi-Fi, obtiennent une adresse, mais aucune page de portail ne s'ouvre et aucun site ne fonctionne. Le journal du pare-feu montre en rafale des lignes « Refus final VISITEURS » de 192.168.10.x vers 192.168.10.62, port 53.
- Explique le lien entre ce blocage et l'absence de portail.
- Corrige.
Voir la réponseMasquer la réponse de l'exercice 1
- Les appareils ne peuvent pas résoudre de nom : la requête DNS vers le pare-feu est bloquée par le refus final. Sans résolution, le système ne peut pas joindre son adresse de test de connectivité (qui est un nom), aucune requête HTTP n'est émise, donc rien à intercepter : le portail ne s'affiche jamais.
- Ajouter, en tête de l'onglet VISITEURS, la règle Pass, TCP/UDP, source VISITEURS subnets, destination VISITEURS address, port 53. Puis tester avec un téléphone : la fenêtre du portail doit s'ouvrir dès la connexion.
Tu avais trouvé ?
Exercice 2 sur 3 Combien de tickets Réussi À revoir
L'accueil de Sorbier reçoit en moyenne 12 visiteurs par jour ouvré, 22 jours par mois, et veut des tickets d'une demi-journée (4 heures). Les tickets non distribués restent valables. Le responsable veut imprimer un rouleau tous les trois mois, avec une marge de 25 %.
- Combien de tickets doit compter le rouleau ?
- Quels réglages de la zone dois-tu accorder avec cette durée ?
Voir la réponseMasquer la réponse de l'exercice 2
- 12 × 22 = 264 tickets par mois ; × 3 = 792 pour trois mois ; avec 25 % de marge : 792 × 1,25 = 990 tickets. Rouleau de 990 tickets de 240 minutes.
- Le Hard timeout de la zone (240 minutes), qui ne doit pas être plus court que la durée du ticket, et la durée du bail DHCP de l'étendue des visiteurs (4 heures), pour que les adresses se libèrent au rythme des visites. L'Idle timeout (30 minutes) déconnecte plus tôt un appareil parti sans se déconnecter, et le ticket peut être réutilisé jusqu'à la fin de sa durée par le même visiteur.
Tu avais trouvé ?
Exercice 3 sur 3 Le visiteur qui joint l'interne Réussi À revoir
Un auditeur, branché sur le Wi-Fi invité et authentifié par un ticket, ouvre https://192.168.10.179 et voit la page de connexion de l'application de gestion. Voici l'onglet VISITEURS :
| N° | Action | Proto | Source | Destination | Port |
|---|---|---|---|---|---|
| 1 | Pass | TCP/UDP | VISITEURS subnets | VISITEURS address | 53 |
| 2 | Pass | TCP | VISITEURS subnets | any | 80, 443 |
| 3 | Reject | Any | VISITEURS subnets | RESEAUX_INTERNES | * |
| 4 | Block | Any | any | any | * |
Explique, corrige, et dis quel autre accès dangereux cette erreur ouvrait.
Voir la réponseMasquer la réponse de l'exercice 3
La règle 2, « 443 vers any », est lue avant la règle d'isolation : elle autorise tout serveur HTTPS, y compris les serveurs internes. Correction : placer le refus vers RESEAUX_INTERNES au-dessus de la règle de navigation, et ajouter avant lui un refus vers This Firewall (self). L'erreur ouvrait aussi l'interface d'administration du pare-feu (port 443 de ses adresses internes et de son adresse publique) et toute interface web interne (switchs, bornes, hyperviseur), à quiconque obtenait un ticket.
Tu avais trouvé ?