Ccnet oublie (ne cite pas) que, pour pfSense, il y a 2 contraintes supplémentaires : pas de serveur PPTP et de client derrière le même firewall (même ip), pas 2 clients vers des serveurs différents via le même firewall (même ip). Ca commence à faire comme défauts …

Concernant OpenVPN, l'option "Redirect Gateway" n'est pas cochée par défaut.
Je pense que c'est préférable (de lapin).
Parce que, passer par le site distant, dans une liaison cryptée, ralenti nettement la navigation, qui n'est pas toujours super "professionnelle" en plus.
Mais c'est vous qui voyez ...
En fait, le seul intérêt est de continuer à filtrer la navigation AMHA.

(Avec Redirect Gateway, pas de NAT à faire : pfSense reçoit du trafic de la range distante VPN et NAT vers le Wan comme le Lan, de la même façon !)

@astonvilla:

apparait un petit disclaimer et un bouton accepter et ensuite c'est parti pour surfer. Est-ce jouable de mettre cela en place avec PFsense ?

C'est possible regarde du côté de "vouchers" dans la partie "captive portal" ;)

@astonvilla:

2 eme question : etant donne qu'il s'agit d'un ligne ADSL, j'aimerai que chaque client qui se connecter n'ait a sa disposition que 128/kos . Meme chose j'imagine que c'est possible mais comment ?

Idem tu peux le fixer, pour ma part ayant une une FO, j'ai limité à 2Mb/s symétrique.
Accessoirement pense à bloquer les ports en entrée pour ne laisser passer que le trafic que tu souhaite :p

Oui une petite confusion de ma part sur ce point :)

sinon pour la règles DNS, il me le fesait pas vraiment seul
j´ai du valider la commande
Do not use the DNS Forwarder as a DNS server for the firewall
et j´ai rentre les dns 8.8.8.8 et 8.8.4.4

Suite a cela la navigation web fonctionne

Bonjour,

C'est parfait avec xca ça a marché.

Merci.

@baalserv:

sur le principe, il serai préférable que pfsense soit le routeur principal et qu'il gère les 2 lan + le ou les Wan (camping/admin et public/wifi)

Ce serait tellement plus simple, plus clair, plus sûr !

Une façon assez élémentaire (et basée sur la réflexion) :

Quand on sait où Squid stocke les url, on regarde le fichier "en temps réel" (=par un "tail -f")

Sous Debian, Squid stocke dans /var/log/squid/access.log.
Sous pfSense, cela est configuré dans l'interface web du package !

@ccnet:

Mais j'aimerais savoir quels sites mes utilisateurs visites.

Je comprend bien la nature de votre préoccupation. Vous devez savoir que ceci est totalement en infraction avec la législation française relative à la protection des données à caractère personnel. Si l'entreprise est tenue de stocker les logs en question (accès des utilisateurs authentifiés), elle est aussi tenue d'en assurer la sécurité, c'est à dire l'intégrité et la non divulgation sauf dans des cas bien précis comme la demande de l'utilisateur concerné, exclusivement pour ses accès, ou encore la requête d'une autorité judiciaire. La seule chose que vous puissiez consulter sont des statistiques en volume.
Par ailleurs la collecte de ces données implique que préalablement vous ayez formellement porter à la connaissance des utilisateurs l'existence de ce dispositif. Je vous encourage à vous enseigner plus avant pour éviter de sevère déconvenues avec un utilisateur qui se montrerait chatouilleux sur ses droits.

Merci , mais j'ai bien pris conscience de cela , avant de commencer le projet.

Dans LightSquid, existe t'il un moyen de connaitre le nom des utilisateurs, et non qu'uniquement leurs adresses IP ?

Presque tout est dit par baalserv …

Périmètre : un siège et 20 écoles (=sites distants)
Sujet : filtrer la navigation sur chaque école (avec blacklists)
(Supposition : chaque école est équipé d'une ligne ADSL)

2 possibilités :

chaque école est équipée d'un proxy (et d'un firewall) chaque école est équipée d'un firewall qui fait vpn avec le site central sur lequel il y a un proxy (et le flux navigation passe toujours par le proxy central)

Le boitier indiqué est parfait comme firewall/vpn pour chaque école (cas 2) mais ne convient pas du tout pour le cas 1 (n'a pas la mémoire et le disque nécessaire à un proxy).
Le cas 2 sera forcément limitant en performance sauf à disposer d'une (très) grosse ligne en central (une SDSL 4M au minimum par exemple).
Le cas 1 nécessite autant de PC puissants que d'écoles ! Mais le trafic sera écoulé localement (sans trop d'impact sur le vpn siège <-> écoles).

Le meilleur équipement, pour le cas 1, est un PC assez puissant (cpu > 2,4 Ghz et mémoire 2 Go) qui utilise pfSense (comme firewall) et les packages Squid+SquidGuard+LightSquid (comme proxy).

La mise au point de ce système nécessite quelques jours de boulot : install et config de 21 machines, ça n'est pas rien ...

NB : normalement on n'installe pas un proxy sur un firewall à partir d'une certaine dimension : là, on peut considérer que l'usage n'est pas intensif ...

Ce qui entre dans la balance :

un siège et 20 écoles (=sites distants)

Bonjour,

Je suis tout à fait d'accord avec toi, concernant la durée de vie avec squid. Nous utilisons Pfsense dans le but de fournir uniquement pour un portail captif client. Squid nous permet justement d'avoir les informations concernant l'IP et les sites visité par cette IP.

Concernant les partitions :

Filesystem              Type      Size    Used  Avail Capacity  Mounted on
/dev/ufs/pfsense1    ufs      443M    238M    169M    58%    /
devfs                    devfs    1.0K    1.0K      0B  100%    /dev
/dev/md0              ufs      38M    72K    35M    0%    /tmp
/dev/md1              ufs      58M    15M    38M    29%    /var
/dev/ufs/cf            ufs      49M    362K    45M    1%    /cf
devfs                  devfs    1.0K    1.0K      0B  100%    /var/dhcpd/dev

Cordialement

Bonjour tout le monde,

J'ai oublié de vous remercier, c'est fait ;)

Je vais regarder cela de plus près dans les jours à venir.

Bonne soirée.

1 heure de recherche dans ce forum (en français ou en anglais) ne serait pas du tout perdue, bien au contraire !

Il n'y a même pas besoin d'aller trouver un blog qui en parle …

Maintenant, il faut se prendre par la main ...

Je suis en ''double Nat'' à la maison avec pf derriere la freebox en mode routeur et pour me simplifier la vie quand au double Nat j'ai juste activé la pseudo dmz de la freebox vers l'ip wan de pf.

De cette façon tout le trafic arrive sur pf et je fait mes règles de Nat seulement sur pf ^^

Pour l'instant pas de nouvelles à ce surjet.

@ccnet:

Je ne vois l'intérêt du vlan intermédiaire. Si on prend l'exemple d'un Cisco, un port est configuré comme "trunk" et achemine les deux vlans de votre choix jusqu’à Pfsense. Les autres ports, en totalité ou en partie, du Cisco sont placés dans l'un ou l'autre Vlan.

exact !
réponse apportée, merci.
Mich.

En effet il y a de sérieux problèmes de compréhension.

le job d'un firewall est de filtrer des flux IP en fonction de règles selon les protocoles et les sources et destination,

on peut ajouter la gestion de vpn, la gestion de "traffic shaping" (de façon brute sur un protocole), …

bien sur, le firewall doit suivre les "sessions" (au sens IP).

un proxy (sous-entendu pour le protocole http) va travailler DANS la session http et filtrer à l'intérieur du protocole,

de plus le proxy établit la session réelle avec le serveur à la place du client,

et le proxy ajoute une fonction "cache"

là où le firewall travaille sur l'entête des paquets IP (et doit répondre dans les temps correspondants), un proxy http travaille sur la session (et a "du temps" pour traiter).

là où le firewall doit disposer de mémoire pour suivre les sessions IP, un proxy doit disposer d'une mémoire folle pour reconstruire les requêtes http, les index de blacklists avec au moins 1 millions d'url

Le discours marketing des firewall UTM consiste à ne surtout pas parler de ces différences essentielles entre les 2 jobs.
Avec une charge faible, cela peut fonctionner (p.e. pour une pme jqa 50 pers.), mais dès que la charge augmente, il y a conflit évident entre les fonctions.
Sans compter qu'il est facile de comprendre qu'avec une seule fonction bien définie, un serveur dédié peut mieux accomplir sa tache : proxy http, relay smtp, ...

Ah votre firewall UTM n'avance pas, quelle surprise ...

@jdh:

Il est bien ce Psylo : il donne un exemple d'utilisation et il confirme une limitation plutôt "unsecure".

Bravo !
[…]

La prochaine fois, je me tairai…

Juste une remarque: la théorie des labos et la pratique des clients est parfois bien bien différente (je me suis sûrement mal exprimé mais c'est ce que je voulais dire avec mon exemple).