Portail captif pfSense avec authentification RADIUS sur Windows Server

Un réseau invité ou Wi-Fi où chacun se connecte avec son compte Active Directory : pfSense affiche la page de connexion, un serveur NPS décide qui passe. Voici le montage complet, de la topologie au premier test.

Par la rédaction de Pixelabs · 12 octobre 2026

Un portail captif (captive portal) oblige les postes d'une interface à s'authentifier avant d'accéder à Internet. D'après la documentation Netgate, pfSense présente une page de connexion où l'utilisateur saisit un identifiant et un mot de passe, un code voucher, ou accepte des conditions d'utilisation. L'usage typique : un Wi-Fi invité.

Avec RADIUS, pas de seconde base de comptes : pfSense transmet les identifiants au rôle NPS (Network Policy Server) de Windows Server, qui les vérifie dans Active Directory. Testez ce montage sur un lab avant de toucher à un réseau de production, et sauvegardez la configuration de pfSense avant de commencer.

La topologie du lab

Le scénario utilise trois réseaux privés RFC 1918 et un domaine de test lab.local. Le portail est activé sur l'interface OPT1, renommée INVITES ; le serveur NPS reste sur le LAN d'administration.

Si pfSense n'est pas encore en place, commencez par installer pfSense dans VirtualBox, puis ajoutez une troisième carte réseau pour INVITES.

Prérequis à réunir :

• un pfSense CE ou Plus à jour, avec l'interface INVITES configurée et un serveur DHCP actif dessus ;
• un Windows Server joint au domaine (contrôleur de domaine ou serveur membre) ;
• un groupe Active Directory, par exemple Invites-WiFi, qui contient les comptes autorisés.

Préparer le serveur RADIUS (NPS)

Netgate rappelle que Microsoft recommande d'installer NPS sur un contrôleur de domaine pour les performances, mais qu'un serveur membre réduit la surface d'attaque des contrôleurs. Les deux fonctionnent.

Installer le rôle et déclarer pfSense comme client

Le rôle s'ajoute par le Gestionnaire de serveur, Ajouter des rôles et fonctionnalités : cochez les services de stratégie et d'accès réseau (NPAS). Dans la console Network Policy Server, dépliez le nœud des clients et serveurs RADIUS, puis, sur RADIUS Clients, créez un nouveau client :

• Friendly name : un nom lisible, par exemple pfsense-lab ;
• Address : l'adresse de l'interface de pfSense la plus proche du serveur NPS, ici 192.168.10.1 (et non l'adresse INVITES) ;
• Shared secret : un secret long, généré par Windows ou par vous, que vous recopierez à l'identique côté pfSense.

Créer la stratégie réseau

Sous Policies, Network Policies, créez une stratégie qui accorde l'accès (Access granted) aux membres du groupe Invites-WiFi, condition Windows Groups. La recette Netgate coche les méthodes d'authentification CHAP et PAP, SPAP ; choisissez celle qui correspond au protocole que vous réglerez dans pfSense.

Le port 1812/UDP est le port attribué officiellement à RADIUS par la RFC 2865 ; la comptabilité (accounting) utilise 1813/UDP selon la RFC 2866. Un NPS installé de longue date peut écouter sur d'autres ports : vérifiez l'onglet Ports des propriétés de NPS.

Déclarer le serveur RADIUS dans pfSense

Dans System > User Manager, onglet Authentication Servers, cliquez sur Add et choisissez le type RADIUS. Les champs à remplir :

• Descriptive name : NPS lab ;
• Protocol : PAP, MD5-CHAP, MS-CHAPv1 ou MS-CHAPv2. Netgate déconseille PAP, qui transmet le mot de passe en clair ; MS-CHAPv2 a aussi des faiblesses connues ;
• Hostname or IP address : 192.168.10.20 ;
• Shared Secret : le secret saisi dans NPS ;
• Services offered : Authentication ;
• Authentication port : 1812, la valeur par défaut documentée.

Le lien entre pfSense et le serveur RADIUS doit rester sur un réseau d'administration de confiance, ou passer par un VPN si le serveur est distant : Netgate précise que certains éléments du protocole circulent sans chiffrement.

Testez immédiatement dans Diagnostics > Authentication : choisissez le serveur NPS lab, saisissez un compte membre du groupe et cliquez sur Test. Tant que ce test échoue, inutile d'aller plus loin.

Créer la zone de portail captif

Le portail se configure sous Services > Captive Portal. Ajoutez une zone, puis :

1. cochez Enable et sélectionnez l'interface INVITES (jamais le WAN, que la documentation exclut) ;
2. réglez un Idle timeout et un Hard timeout en minutes, inférieurs à la durée du bail DHCP de l'interface, pour qu'une session ne survive pas sur une adresse réattribuée à un autre appareil ;
3. dans Authentication Method, choisissez Use an Authentication backend et sélectionnez NPS lab comme Authentication Server ;
4. enregistrez, puis ouvrez une page HTTP depuis un poste invité.

Si vous utilisez une page de connexion personnalisée, elle doit poster les champs attendus par pfSense pour la source d'authentification principale :

<input name="auth_user" type="text">
<input name="auth_pass" type="password">

Côté pare-feu, l'interface INVITES n'a aucune règle autorisant le trafic tant que vous ne l'avez pas créée ; la page sur les règles firewall pfSense détaille comment autoriser le DNS et le HTTP de cette interface sans ouvrir le LAN.

Ce que RADIUS peut renvoyer au portail

Le serveur peut aussi renvoyer des attributs que pfSense applique, si les options correspondantes sont activées dans la zone :

L'option Reauthentication interroge le serveur chaque minute pour chaque utilisateur connecté ; un refus coupe la session aussitôt.

Le portail captif ne s'affiche pas : les causes documentées

C'est la panne la plus fréquente. Netgate la ramène à quatre causes :

• le DNS ne répond pas : sans résolution, le navigateur n'envoie jamais la requête HTTP que le portail doit intercepter. Les clients doivent utiliser le résolveur DNS de pfSense sur l'interface INVITES ;
• les règles bloquent la requête HTTP initiale : le trafic à rediriger doit être autorisé sur l'interface du portail ;
• la page d'accueil du navigateur est en HTTPS : la redirection fonctionne sur une requête HTTP ; avec HTTPS, tout dépend de la détection de portail du système ;
• le client passe par IPv6 : le portail n'est pas compatible IPv6.

Pour un échec d'authentification, regardez côté Windows : NPS journalise chaque requête dans le journal Sécurité, avec une ligne Reason qui explique le refus. Si NPS indique un succès alors que le portail refuse, le secret partagé diffère entre les deux côtés.

Pour un autre pare-feu, voyez OPNsense vs pfSense ; les autres tutoriels sont dans la rubrique réseau et pare-feu.

Questions fréquentes