@jolastreet:

Bonjour à tous ! J'ai enfin régler mon problème et le portail captif marche parfaitement je suis super content !!

Cependant j'ai l'authentification via "users" et j'aimerai dorénavant le faire grâce au FreeRadius de Pfsense cependant après l'avoir installé il m'est impossible de lancer le service "FreeRadius".

Après de multiples recherches sur Internet je ne trouve toujours pas vous savez d'ou cela peut venir ?

Bonjour, je pense que j'ai le même problème que vous, est-ce que vous pouvez me dire la solution de votre problème que vous avez résolu du portail captif qui ne fonctionnait pas au début svp.

Merci de me répondre rapidement.

Très probablement.
Et dans tous les cas, c'est très simple à tester…
Attention cependant, côté serveur Squid, il me semble avoir lu quelque part, mais peut être était ce pour une vieille version du package, que le fait de revenir en mode explicite (par opposition à transparent) ne remettait pas correctement en mode explicite. À vérifier dans le fichier de conf donc

J'avoue avoir un peu du mal avec la terminologie et le design.
Un contrôleur de domaine, ce n'est pas un serveur LDAP, loin s'en même si un serveur LDAP fait partie de la solution. Ce qui veut dire d'autres ports ouverts en plus de 636.

Par ailleurs, si ce contrôleur de domaine est côté WAN​, peut être dispose t il de son propre FW.

Dans tous les cas, si pfsense bloque les accès, tu dois avoir des traces dans le log de ce qui est bloqué ( ça peut nécessiter d'activer le log pour quelques règles)

Très fort.
Publier une question en VO-FR sur un forum 'US-GB', or, le forum Français.

I've some questions also :
Why are you using multiple statements ?
You should not hard code https://www.google.fr/
You should not hard code https://ggd095fw726501:8003/index.php?zone=webggd95

And, finally, the answer : html background image (justement, on le trouve avec google.fr ;) )
Sache qu'un réponse n'est pas vraiment simple, car il s'agit de l'html , c'est un sorte de langage script pour fabriquer des 'truc' que nos navigateurs peuvent afficher. C'est tout simple, tout con, est hyper bien documenté - mais il faut l'apprendre, il n'y pas d'échappatoire  possible.

Merci à tous pour vos réponses  :)

Je vais regarder l'ensemble des règles.

D'où l'intérêt d'utiliser une présentation de forme standard, cf A LIRE EN PREMIER (où il est indiqué de mentionner les packages installés …)

La question sur la ram ne depend pas de la quantité de machine mais de ce que va faire pfsense.
Si tu ne fais que du pf par exemple, je fais tourne une openbsd avec seulement 512Mo de Ram pour 100 machines environ.
Par contre la je n ai pas d interface web.

Si tu veux utiliser des packages comme pfblocker ou autres alors evidemment ta consommation de ram et CPU va grandement augmenter.
Mais pour 5 machine a mon humble avis 2go de RAM devrait etre suffisant

Pour ce qui est du disque tout depend de ce que tu comptes logger. Je te deconseille sur du SSD d ecrire tes logs pour préserver sa durée de vie.

si tu lis l anglais tu as ce tutorial qui peut peut etre t aider

http://itpro.outsidesys.com/2015/02/19/home-lab-with-pfsense-workstation/

https://forum.pfsense.org/index.php?topic=55580.0

Bonjour chris4916,

il s'agit de la "FWA-7010" d'osnet.

@DyHuger:

Si vous avez des idées je suis preneur s'il vous plait :)

Oui au moins une : regarder dans les logs de pfSense ce qui se passe, sachant bien sûr que dans ton cas, il peut s'agir d'un problème au niveau de VMware.

Comme tu ne décris rien à ce propos, on va supposer que c'est un accès "direct" à internet, c'est à dire pas de proxy.
Est-ce que le poste client est capable de résoudre les noms (comme c'est pfSense qui est DNS) ?

oh pas vu jdh
ca date longtemps
désolé
okay  2 nic + 1 switch + 2 pont accès wi fi AC ?

Mais une question me vient à l'esprit. J'avais vu qu'avec le portail captif on pouvait voir dans les logs quel IP avaient été attribuée à tel utilisateur à telle date/heure.
Du coup en combinant ces informations avec celles de lightsquid (qui "filtre" par IP), je pourrais être en mesure de savoir qui a fait quoi…

Rappelons, encore une fois, à tous les amateurs de portails captifs et autres proxy (notamment transparents) que ni l'adresse mac, ni l'adresse ip ne sont des éléments d'authentification fiables de quoi que ce soit. Ces éléments ont une raison d'être qui n'a rien à voir avec les questions d'authentification. Dans le domaine judiciaire, qui est susceptible de concerner n'importe quelle structure n'importe quand, il n'est pas possible d'imputer une action à un utilisateur sur la base d'une adresse ip ou mac. Au mieux on peut établir une présomption, mais pas une preuve.
Si l'on parle d'authentification utilisateur de manière sérieuse tout cela ne tient pas la route.
Si l'on souhaite authentifier une machine ce n'est pas vraiment mieux.

Je me suis donné la peine de créer un fil précis, avec les bons liens, et certains ont apporté une bonne contribution (Juve - autoprox.exe).
Je conseille de se référer à ce que j'ai écrit (inutile à certains de re-citer les url que j'ai indiqué …)
L'url indiqué (nguvu) fournit les mêmes renseignements : en anglais, moins structuré, pfsense-dépendant, ...

Je répète, cela fonctionne bien et efficacement ... en respectant chaque étape.
Je ne cache pas que je recommande d'appliquer cela à un proxy dédié, en particulier parce que tout ce qui sera nécessaire sera DANS ce proxy dédié.

Il est notable qu'il faut,

un réglage pour le serveur DHCP, un réglage pour le serveur DNS (avec la précision indiquée pour les serveurs DNS microsoft), un serveur web, dument configuré, pour fournir le script (sous les 3 noms),

Chaque élément doit être, dument et méthodiquement, testé !

Si vous butez sur le serveur web,

avez vous ajusté la configuration du serveur web ? avez vous regardé les logs du serveur web : code 200 ou autre ?

'Ca ne fonctionne pas' ne sert à rien : qu'avez vous fait, qu'avez vous regardé, comment testez vous ?

autoprox.exe a de l'intérêt, surtout sur le script, mais seulement si DHCP, DNS et web fonctionnent ...

Ca tourne largement en rond ...

pfsense192.168.1.0 ovh =>openvpn serveur(pfsense) 192.168.2.0 => freebox en mode bridge => asus ac68u 192.168.3.0
openvpn serveur se trouve sur le pfsense hebergé par ovh, je redirige le traffic de tout mon lan chez moi sur asus ac68u, configurer en client sur le pfsense et c'est ok.
Il n'y a pas de pare feux sur le asus.
J'essaye d'installer un docker lets encrypt(serveur web) sur mon nas, mais il me dit que le port 443 est bloqué.
Le seul firewall est sur le pfsense. que dois je faire?
Pour le certificat let's encrypt j'ai pointé mon domaine sur l'ip public du serveur ovh.
desolé si je m'exprime mal j'ai pas l'habitude de me renseigner sur les forums, mais la je sèche.

@chris4916:

les exceptions au fonctionnement de pfBlockerNG ne se gèrent pas au niveau du FW mais au niveau de pfBlockerNG, dans la construction des listes.

Merci pour ce retour intéressant. J'avais fait un essai de cette façon, mais après update du package la conf a disparu… Qu'ai-je loupé?

A première vue, un problème de filtrage ? A vérifier en priorité. Le routage semble fonctionnel.

Le fichier J s'appelle access.log, le fichier j-1 s'appelle access.log.1 ainsi de suite…

Il suffit de faire un ls -l pour bien voir la liste des fichiers et de regarder la date du fichier dont nous avons besoins. Ensuite on envoie le fichier par FTP 😎

Et c'est fini! C'est tout ce dont je demandé...