OK merci :)

C'est bien le cas.. je me charge de ça !  ;D

Si on commence par regarder la documentation de pfSense, on arrive à un doc de configuration pour MonoWall qui indique bien 3 possibilités :

pas d'authentification, authentification locale, authentification Radius.

j'ai la version avec un disque dur, c'est pour ça que je pensais pouvoir installer squid dessus,
en faite j'ai la possibilité d'installer squid , car il est dans la liste des packages
c'est le package lightsquid qui n'est pas présent, ce qui m'intriguait

je vais voir pour déplacer le proxy,..il s'agit justement d'un installation pour moins de 10 pers.

merci

Plusieurs clés Huawei sont référencées dans http://doc.pfsense.org/index.php/Known_Working_3G-4G_Modems

Une piste, pour la compilation du module, est donnée par http://osdir.com/ml/ubuntu-bugs/2011-09/msg05176.html (s'inspirer de).
(Il semble qu'il suffise d'ajouter le PID de la clé au driver connu.)

Ce n'est pas une solution simple …

Alternative : il existe des routeurs 3G économiques (~70€) mais ils fournissent en général un signal Wifi.

Bon apparemment j'ai réussi à trouver, c'était une erreur de config, je n'avais pas configuré correctement les DNS dans le DHCP Server pour ces interfaces là.

Je n'ai pas le nom de l'utilisateur qui s'est connecté (disponible dans portal auth), ni les sites qu'ils a visité

Job d'un proxy.

Je comprend bien la raison. Un proxy Squid serait aussi en mesure de gerer votre problème. J'explore sans a priori les solutions possibles.

<mode blague="">Evidemment, on perd toute configuration !
Et c'est fait exprès pour faire peur à tous les débutants, "grands gourous BSD only !"
<mode blague="">Bien sûr, la config reste opérationnelle (même si la présence de package peut éventuellement poser problème).

Perso, je sauvegarde la config (sans les infos RRD), j'obtiens un fichier .xml que je stocke précieusement, et je note la liste des packages installés.
Puis je lance la mise à jour.
Au cas, très peu probable, où le système ne redémarrerait pas, il suffit d'installer un pfSense neuf puis de restaurer le fichier .xml.</mode></mode>

@jdh:

Je reformule ce que j'ai compris :

un firewall pfSense qui doit gérer les tunnels IPSEC avec les différents sites de l'entreprise, pour chaque client, on doit créer aussi un tunnel IPSEC qui doit aboutir non au LAN du site central mais à un VLAN dédié au client, le VLAN "client" arrive à un switch d'un hôte VMware ESX lequel sera connecté à 1 ou plus VM dédiées au "client". le firewall doit assurer l'étanchéité entre les réseaux de l'entreprise et les VLAN "clients".

Ma perception :

les VLAN constituent des réseaux virtuels mais pas aussi étanches qu'un câblage physique séparé (+ switch dédié + carte réseau dédié). les VM doivent avoir 2 cartes réseaux (virtuelles) : une vers le VLAN "client" + une vers le LAN entreprise. les VM DEVRAIENT avoir un firewall évitant que les VM deviennent des "bridges" entre les 2 interfaces (difficile avec Windows).
Finalement cela me semble une sécurité loin d'être parfaite …

Je dédierai une carte réseau du firewall et une carte réseau de l'hôte VMware pour l'ensemble des VLAN "clients" (avec un câble croisé direct).
L'utilisation d'alias doit permettre de créer sur chaque interface VLAN les règles d'interdiction.

Tout dépend le nombre de client à protéger mais honnêtement, utiliser un câblage physique différent par client uniquement pour des démos, je trouve ça overkill… A contrario, pour de la production, ça devient beaucoup plus important...

Sinon, mokha, ce que vous voulez faire est tout à fait possible. Maintenant, pour ce que est du "comment", je vous conseille de lire beaucoup et de tester sur le côté avant de mettre en prod. Ca vous permettra de bien maîtriser le sujet avant de vous lancer dans le feu de l'action.

My 2 cents.

Il existe 2 types de VPN SSL sur Cisco ASA:

le mode "Clientless": ce mode permer au travers d'une page web de "rediriger" des ports dans un tunnel SSL. Par "rediriger", j'entends encapsuler certains flux (RDP par exemple) dans le tunnel SSL monté avec le firewall. Un peu à la manière du port forwarding au travers d'une connexion SSH (http://www.linux-france.org/prj/edu/archinet/systeme/ch13s04.html). Ce mode a le grand avantage de n'avoir rien à installer sur la machine cliente et a le gros désavantage de ne pas bénéficier d'alogrithme de chiffrement très poussé ni de renégociation de clé… le mode "Full Tunnel": qui permet d'installer un client au travers du même portail HTTPS que le mode précédent. A ce moment-là, le client monte un tunnel sécurisé avec le firewall. Gros avantage par rapport à un tunnel IPSec: le client utilise uniquement le port 443 (HTTPS) et donc, la plupart des proxies ou des firewalls laisse passer le trafic. Inconvénient: pas de renégociation de clé si je ne m'abuse.

Juniper fait aussi ce genre de chose et en ce qui concerne le débat: est-ce que cette fonction doit être gérer pas un firewall? Vu que c'est du tunnel VPN, je pense que oui. Maintenant, on peut toujours utiliser un appliance sur le côté pour ça si on veut.

My 2 cents.

trouvé!

en fait le problème venait de squid, sous lequel j'avais paramétré dans les "allowed subnet" mon autre réseau. Du coup il laissait passer sans regarder mes règles de firewall…

Voila le portail captif marche avec l'authentification sur le pc portable, seul souci c'est qu'il faut lui dire de rediriger vers la page d'authentification (nous n'arrivons pas à y accéder par la redirection). Apparemment il faudrait créer une règle dans le firewall ?

Pour le moment pfsense ne prend pas en charge le failover de liens pour tunnels IPSEC, il faut se contenter d'une bascule manuelle (on créer les deux tunnels mais on en désactive un).

Effectivement, essayez avec des machines physiques, ce sera plus simple pour vous.
J'anime de temps à autres des cours systèmes & réseau pour des étudiants Bac+3/4/5, et je ne peux que rejoindre l'avis de CCNET ou JDH. La plupart du temps je travail avec ESXi par manque de matériel en nombre et je dois avouer que les étudiants se perdent complétement par manque de connaissance de la couche VMWare.

@Nachtfalke:

If you find a way to "edit" the db then please tell me.

No problem ;)

–

Bon ajouter du temps directement, çà ne marche pas, j'aurai du m'en douter, trop simple  :P

Je souligne que, seul, un proxy (comme Squid) sait analyser l'intérieur du flux http pour en extraire dans un log date, heure, adresse ip, url, (+ identifiant).

Un portail captif n'est là que pour "ouvrir" la traversée d'un firewall selon une authentification (la plus souvent avec Radius).

Sans proxy, il n'y a pas de fichier d'url.
Sans authentification dans le proxy, il faut "synchroniser à la main" le log radius et le log du proxy.

(Je n'ai jamais testé un portail captif ni radius, je ne donne qu'une réflexion générale …)

All configuration files of freeradius2 are located in:

/usr/local/etc/raddb/

Après réglage du BIOS (comme je l'ai mentionné ici et sur un autre fil), on arrive à lancer normalement pfSense.
Il est indispensable ensuite de l'installer sur disque (de mémoire il faut taper I à un certain moment).
Ensuite, on peut se lancer dans la configuration …

Le mode "Live-CD" n'est pas satisfaisant, bien sûr.

Enfin, c'est comme ça que j'y suis arrivé et que j'en rends compte ... puisque c'est le principe d'un forum !

C'est de très loin le débit disponible sur votre lien qui est le facteur déterminant. Ensuite selon le type de trafic le temps de latence peut avoir, on non, une importance. Ensuite il n'est pas possible, dans ce cas précis, de maitriser le débit sur la totalité de la liaison. Des mauvaises surprises sont possibles côté utilisateur VPN.
Il est certain que ni le changement de la longueur de clé DH, ni d'un autre paramètre cryptographique par exemple ne seront une aide pour améliorer le débit "ressenti".