Merci pour cette réponse. C'est bien ce que je craignait, c'est donc un peu plus complexe que prévu. Je vais donc essayer la piste du proxy, vu que je ne souhaite pas faire modifier les paramètres des navigateurs. Je vais tester avec les packages PFsense pour voir.

A partir d'une certaine taille (disons 15 utilisateurs un peu actifs), ce qui est judicieux un firewall pfsense un proxy dédié avec Squid, SquidGuard (filtrage blacklist), et lightSquid (log d'utilisation) le réglage des pc clients par WPAD : fournit le proxy à utiliser pour chaque protocole géré par Squid (http, https, ftp) des règles qui autorise la sortie pour le proxy et l'interdiction pour les autres La contrainte sur les PC clients sera minimale : juste config auto (=détection par WPAD). Les PC clients fonctionneront à la fois dans le réseau de l'entreprise et ailleurs.

Cela s'appelle un model hub and spoke, a opposer au model full mesh ou vous etablissez un tunnel entre chaque point (plus complexe a configurer mais plus efficace en termes de debits/latence) C'est faisable et plutot simple a mettre en oeuvre. Faudrait il encore savoir sur quel protocole vous souhaitez implementer…. Ipsec ? Ssl (openvpn)

Le lien VPN IPsec fonctionne correctement. Seul des tests de débits sont à effectuer ! Je vais faire le test du failover avec un DNS dynamic. Je reviendrai vers vous une fois mes tests effectués.

YAHOOOOU Bon bah installation de la dernière version sur machine physique et ça à l'air de bien fonctionner. Réponse au problème: Virtualisation pas adaptée. Merci d'avoir pris du temps pour m'aider, Cordialement, Risen. [image: ok.jpg] [image: ok.jpg_thumb]

Moi aussi je voir se même message et franchement je suis tres  >:( "Eror sending request : No valid RADIUS responses received"

Bonjour, Pour que les Vlans ne puissent pas communiquer entre eux, dans ce que je connais de PFsense, tu es obligé de passé par des règles. Le moyen idéal serait que Quagga supporte plusieurs instances de routage (VRF ou VPN-MCE chez Cisco/HP) ou encore mieux le MPLS. tu peux bloquer les réseaux intervlans en rajoutant à la bonne position une règle flotante par exemple sur toutes les interfaces concernées. En gros, tu bloques les réseaux de classe A/B/C sur ces interfaces, mais en positionnant correctement le fait que tes serveurs puisse réponde. exemle : ton vlan10 est en 172.16.0.0/16(sur sa patte et tout ses sous réseaux si il y a des routeurs derrières). Ton serveur DHCP est en 10.1.1.1.,  ton dns est en 192.168.1.1 et les autres vlans sont en 172.17.0.0/16, 172.18.0.0/16  et 192.168.2.0/16 Dans la règle du vlan 10, tu auras en gros drop any classeC (un alias du 172.16.0.0/12) permit any 10.1.1.1 udp 67 drop any classeA (un alias du 10.0.0.0/8) permit any 92.168.1.1 udp 53 drop  any classeB (un alias 192.168.0.0/16) et après des règles. Dans ce cas, ton vlan 10 ne pourra pas communiquer avec les autres réseaux mais pourra surfer etc.. selon ce que tu l'autorise. Si besoin, tu rajoutes la ressource entre les règles drop concernées si besoin. La limite de PFsense et de cette solution c'est que tu ne peux pas superposer des réseaux identiques sur tes interfaces à cause de la limite que j'ai énnoncée au début. l'ordre est important car toutes les règles générés par l'interface pfsense sont en "quick" pour plein de raison que je ne résumerai pas ici. Pour la fausse bonne idée. Non, cela dépend de tes besoins, de tes ressources machines etc… Séparer est plus idéal mais si c'est pour un accès avec 8 vlans, très peux de traffic, un pfsense non redondé, c'est peut-être adapté. Difficile de juger une archi sans avoir le détail et les poyens qui sont à ta disposition. Bonne chance

Bonjour, @Tatave: un schéma, les adressages (avec des x pour les ip externes) la config des interfaces, les règles de NAT créés, le type de serveurs web, sa config Voir le fichier joint. Les IP WAN sont sur le même RIPE. L'environnement est complètement virtualisé sous Promox. Les IP Public utilisent les MAC Groupées de Online (IP Public associé à la même MAC addresse). Par contre, comme pour les IP failover d'Online, la passerelle par défaut n'est pas sur le même subnet que le RIPE (D’où l'usage de shellcmd basé sur ce tuto : http://forum.online.net/index.php?/topic/1240-tuto-esxi-pfsense-comme-firewall/) @Tatave: les tests effectués, les résultats @ymolinet: Comment j'ai déterminé que la pfsense était concerné ? tout simplement parce que les services web sur cette IP répondent parfaitement en interne, idem pour le ping. Hors, depuis le shell de la pfsense, le ping ne passe pas. Idem depuis une source VPN (OpenVPN de la pfsense). De plus, un redémarrage de la pfsense résout le problème, puis après plusieurs jours, le problème réapparaît. Aucune log dans le journal du firewall n'indique un rejet ou un drop de paquet sur cette IP. Les autres IP de ce serveur web fonctionne parfaitement, même depuis la pfsense. Autre test réalisé: Un telnet sur le port 80, 21 ou 443, qui n'accroche pas non plus. J'en déduit donc que le module firewall bloque le traffic, mais je n'ai pas trouvé de log indiquant que pfSense à bloquée du traffic. [image: img012-2.jpg] [image: img012-2.jpg_thumb]

Si on "réfléchi" un peu, un proxy qu'est ce que c'est, si ce n'est un "man in the middle" précisément ?

Les gens, soyez gentil ou ne parlent pas. (Je m'excuse pour mon mauvais français.)

Salut salut / Toll on / Le fils rouge sur le bouton rouge. Le fils blanc que le bouton blanc. Ha non c'est pas ça.. Mais ou est passé la 7eme compagnie ? Ok je sors. / troll off / Il est sur que ce genre de petite chose est indispensable d'avoir dans sa boite à malice du mauvais tech/adm sys/net ^^ Arff ou j'ai mis le mien. Cordialement.

Personne d'autre à une réponse ?

Le lien est intéressant (je ne le connaissais mais correspond à des astuces "normales") ! Toutefois, je savais que, pour configurer le modem, je dois utiliser un pc (portable) en direct sur le modem. Néanmoins : le modem NE DOIT PAS être gateway … sinon il y a 2 gateways et ça, ce n'est pas bon !

@baalserv: vous pouvez cocher la petite case dans les config serveur : => Strict User/CN Matching When authenticating users, enforce a match between the common name of the client certificate and the username given at login. Cordialement ah le boulet que je suis, je suis un winner sur ce coup… Merci baalserv (aux autres aussi ;)) et ccnet pour  l'onglet client specific override. Résolu ps: le client export est vraiment simple . sous ubuntu on extrait l'archive,  importe le fichier ovpn, on rentre les user/password et c'est fini (pas testé sous win)

bonjour, je veux bien faire  de la relecture sur l'aspect technique de tuto

Je répète : si vous voulez de l'aide, fournissez 4 paramètres du portable (ip, masque, gateway, dns) (dans le lan de pfSense) résultats du test des 3 pings réglages du pfsense : adressage wan, lan, gateway, firewall > rules > (onglet LAN), packages installés avec leur réglages, …

Salut salut Là je n'ai pas de boule de cristal, et trouver ce soucis au moment d'une deadline c'est coton. Relisez ça elixirr.free.fr/…/reseau/.../pfsense/Tutorial-PfSense-Francais-1v1.0.pdf re refaite votre vérif, sinon votre tuteur ne pourrait il pas vous donner un coup de pousse en lui expliquant. il est aussi la pour vous aider, cela fait partie de ces prérogative. non ? Cordialement.

Avec une règle qui s'applique à N clients et avec un nombre maxi de connections, cela s'applique à TOUS les clients. Il faudrait donc plutôt N règles : une par client ! Lorsque j'ai testé le paramètre  "Maximum new connections / per second(s) (TCP only)" un client qui se connecte de façon raisonnable (toute les 15mn) n'avais pas de problème. Alors qu'un qui tente une connexion toute les 3mn ne pouvait plus du tout se connecter. Ce qui est normal puisque j'ai défini 4mn (valeur max proposé par l'interface de pfsense). L'idée serait pour un temps mini de 15mn entre chaque connexions : l'ip 172.159.86.6 se connecte à 8h, c'est ok. l'ip 172.159.56.6 se connecte à 8h03, connexion refusé car pas respecté le temps mini entre deux connexions l'ip 172.159.56.6 se connecte à 8h06, connexion refusé car pas respecté le temps mini entre deux connexions […] l'ip 92.68.67.8 se connecte à 8h07, c'est ok (c'est ça première connexion) l'ip 172.159.56.6 se connecte à 8h16, c'est ok les 15mn sont passés. l'ip 92.68.67.8 se connecte à 8h28, c'est ok. Perso je suis plus d'avis de faire cela au niveau des droits des user sur l'Os hébergeant le serveur ftp pas sur Pfsense. Cela serait un non sens coté sécurité de le faire sur PF s'il le fait bien évidement. ( coup de coude à jdh pour l'info) :p Je suis d'accord mais vsftp ne le propose pas… Ou alors j'ai pas encore trouvé l'option. NB : avec des fichiers mis à jour tous les 20 minutes, il ne sert à rien de tenter d'aller chercher tout les 3 minutes ! Un enfant peut comprendre cela ! C'est ce que je me dis aussi… Mais je dois être trop adulte ;)

Vous fournissez plus d'infos, c'est bien. (Et vous comprenez, un peu tard, l'utilité de le faire dès le départ) Je suis désolé mais je ne comprends toujours pas tout de votre situation : le failover et le loadbalacing sont des cas de multi-wan, le multi-wan suppose au moins 2 wan distincts, comme cité parfois, pfSense n'aime pas avoir 2 wan avec la même gateway ! Votre schéma comporte 2 wan … qu n'en sont pas puisqu'il n'y a qu'un seul routeur final. Ce n'est pas parce que 2 wan utilisent 2 ip distinctes qu'il sont réellement distincts : je conseille d'avoir 2 wan distinctes au niveau ip (et donc avec 2 gateway distinctes).

donc d'après vous, il faut que je crée, un vswitch pour mes VLANS, un pour mon LAN, WAN et DMZ ? C'est une certitude ! 1 zone logique = 1 switch logique = 1 vswicth en VMware. Ca tombe sous le sens ! (Même si, par sécurité, il faudrait un hyperviseur par zone logique !)