@mekano:

Question: Est-ce que j'ai besoin de faite du "nat" entre mes interfaces sur mon pfsense pour assurer la communication entre mon Lan et mon WIFI ?

Ma compréhension est que non mais je veux juste être sur qu'il est bien configuré.

Merci

Non, il n'est pas nécessaire voire même déconseillé de "natter" entre 2 réseaux protégés.

Sinon, vous pouvez aussi faire des captures directement sur le pfSense soit via l'interface graphique (Diagnostics->Packet Capture) soit en console (via une connexion SSH par exemple) avec l'utilitaire tcpdump. Lancez une capture sur l'interface wireless du pfSense pour voir si les ordres passent bien au travers du pfSense.

Hops this helps.

Résolu..

Problème avec l'agent FreeRadius2, désinstallation puis installation et niquel.

Au cas ou quelqu’un aurait le même souci, de mon coté c’est résolu. La première idée était la bonne, ma carte réseau ne supportait pas autant de connexion, ou elle devait être tout simplement défectueuse.

En changeant la carte toutes les connexions ce sont montées.

Bref, j'ai trouver tout seul, juste un problème de route.

(Problème bien présenté : bravo ! Si tous les fils pouvaient démarrer comme ça …)

Tous semble bien configuré et comme il doit l'être.

passer en version normale (et non RC) : mise à jour simple et sans problème, essayer de modifier le DHCP de OPT1 : mettre 192.168.2.254 ... pour voir, écrire des règles explicites (DNS) sur chaque interface plutôt que des règles par défaut, revérifiez chaque élément.

(NB : pour OPT1, aucune règle par défaut n'est créé. Préférerez des règles par interfaces plutôt que "floating".)

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.