Portail Captif côté WAN

[nemesis34]

Bonjour à tous,

Contexte : dans le cadre d'un projet d'étude

Besoin : dans un premier mettre en place un Portail Captif sur l'interface relié directement à internet pour avoir accès au LAN (afin de créer un "tunnel" seulement a partir d'un navigateur web)

Schéma :
Mon PC –> Internet -->(WAN) Pfsense (LAN) --> un serveur_A

Portail captif sur l'interface WAN, et avec les paramètre par default sans radius

Pour l'instant aucune autre configuration (après viendra du loadbalancing, un radius,des VLANs...

Question :
J'ai configuré le portail captif sur l'interface WAN et du coup je n'arrive pas a le tester car quand je tape l'@IP de l'interface WAN je tombe sur l'interface graphique de Pfsense (totalement logique) du coup je spécifie le numéro du port à la fin :8000 (si je ne me trompe pas) et ca ne fonctionne toujours pas je ne sais plus quoi faire. Auriez-vous des idées?

Merci à tous et bonne continuation.

[chris4916]

ça ne marche pas… pour tout un tas de raisons  8)

D'abord parce que ce que tu décris n'a rien de captif: coté WAN, tu ne vas "capturer" que les flux qui vont pointer vers ton IP publique. Pas captif donc  ;)
Ensuite parce que un portail captif, ça n’établit pas de tunnel  ;) ;)

L'accès au LAN depuis internet se fait habituellement avec un tunnel VPN. Si tu veux limiter ce service, et pourquoi pas, au protocole HTTP, alors la solution s'appelle un reverse proxy:

• tu exposes un proxy avec un certificat sur le web, ce qui permet d'établir un tunnel entre ton client et le reverse proxy (à noter que ce reverse proxy peut très bien demander une authentification
• ce proxy t'autorise ou pas à accéder à un serveur web interne

Peut-être est-il préférable de rediscuter avec la personne qui te donne le cadre du projet d'étude  :D

[ccnet]

En dehors du fait que cela ne peut pas fonctionner, je ne comprend pas l'aspect fonctionnel recherché. Il me semble aussi indispensable de revoir la définition du projet.

[nemesis34]

Vous avez raison je me suis très mal expliqué mais en gros j'ai plein de nomade (PC/smartphone/automate)qui doivent avoir un accès sécurisé sauf que je peut pas me permettre d'installer un client sur chacun d'où mon besoin d'une page d'authentification qui va permettre a certain d'avoir accès seulement à un serveur web, d'autre on accès à d'autre serveur et encore certain on accès à tout les serveur.

Donc j'avoue je sais pas trop comment faire.

[chris4916]

@nemesis34:

Donc j'avoue je sais pas trop comment faire.

Si ces clients n'accèdent qu'à des serveurs web internes, un simple reverse proxy en HTTPS avec authentification rempli cette fonction

[ccnet]

Et si il ne s'agit pas de serveur web, la solution dépendra de l'applicatif pour lequel vous souhaitez une authentification et de la solution reverse proxy choisie. Mais certaines authentifications peuvent ne pas être "proxyfiables". Kemp fait des produits intéressants dans ce domaine.
Pour un accès au niveau réseau ce sera un vpn.

(afin de créer un "tunnel" seulement a partir d'un navigateur web)

C'est ce que fait https.

[chris4916]

@ccnet:

Mais certaines authentifications peuvent ne pas être "proxyfiables". Kemp fait des produits intéressants dans ce domaine.

proxyfier l'authentification est encore un autre niveau de débat  ;)

Est-il souhaitable qu'un mécanisme quelconque soit capable de rejouer l’authentification effectuée au niveau du reverse proxy ?

La plupart du temps non, à mon avis, surtout si il s'agit de vraiment relayer le credential.

Si l'objectif est de limiter le nombre d'authentifications, il est alors préférable de s'orienter vers des solutions de type "web-sso" (CAS ou autre) ou de mettre en place un SSO plus complet à partir de Kerberos ou de fédération. Mais nous sommes bien loin de la question initiale et c'est probablement un peu compliqué à ce niveau  ;)

[ccnet]

Noter les guillemets ajoutés à proxyfiable.
De façon générale une solution de type SSO sera préférable en effet. Nous en sommes d'accord.