Ce package fonctionne avec la version 1.2.3 et 2.0B5. L'appliance virtuelle doit normalement les contenir.

Merci pour votre réponse.

Merci pour votre réponse en effet comme cela c'est plus clair :)

Salut, Merci à tous, vous m'avez bien éclairé. A+ Meirick

ok merci

Il reste un problème essentiel : un proxy n'a rien à faire sur un firewall même si c'est commercialement répandu. Le proxy sur le firawall est tolérable pour les toutes petites structures. Nous avons expliqué à maintes reprises pourquoi sur ce forum. les besoins d'optimisation du firewall étant assez différents de ceux d'un proxy. C'est effectivement le cas.

oui nan effectivement je viens de comprendre mon abbération ….cependant actuellement sur une v2 BETA 5, qu'elle carte PCI wifi N est compatible avec le systeme ?

Comme son nom l'indique, il s'agit d'encapsuler. Si le trafic de site à site est de type ip pur, il n'y a guère besoin de GRE …

Merci et bonne soirée

Un petit UP, le prix est bien sur négociable  ;)

dans la config du client mettre deux une lignes: (server pf1SDSL - déjà donné par la config) server pf1Free; - mettre dans la case "Custom options" Si j'interprète bien le fonctionnement d'openvpn, alors c'est openvpn qui se connectera automatiquement sur le deuxième serveur si le premier ne répond pas.

Merci, c'est exactement ce que je suis en train de faire, sans la virtualisation. =)

Oui il faut prendre tout celà avec des pincettes. On est en train de parler de code qui "aurait" été inséré dans le crypto framework d'openBSD au début des années 2000 (bibliothèque de code fournissant les algorithmes de cryptage asymétrique/symétriques, eux meme utilisés par la couche IPSEC d'openBSD). Pfsense utilise une couche IPSEC dérivée (fortement) de cette permière implémentation. La "backdoor" "aurait" pour but d'extirper les informations d'échange de clés afin de pouvoir décrypter une transmission IPSEC entre deux équipements. La communauté s'est lancée depuis 10 jours à la chasse à la backdoor mais il en résulte qu'il n'y a rien de "malicieux" pour l'instant. Ils ont trouvé des bugs, affectant des fonctions obsolètes. Enfin, l'histoire en elle même est assez farfelue, les codeurs n'auraient eut un NDA que de 10 ans…., les personnes citées affirment ne rien avoir inséré, le code a été mainte fois forké sur des produits libres comme payants (n'oubliez pas que darwin, le noyau MacOS, est un fork freeBSD). Il est fort probable que les instances de renseignement de différents pays agissent de la sorte, y compri (et de manière contractuelle, avec un cadre définit) avec des produits éditeurs... Attendons de voir...

C'est encore plus simple quand on lit ce qu'il y a à l'écran … Dans l'onglet "Preprocessors" il faut valider "Enable DCE/RPC2 Detection" ... Facile ! Bon travail à tous.

Tu peux essayer de bloquer les peer 2 peer avec le traffic shaper.

Auriez-vous des logs lorsque le problème se produit?

Une combinaison intéressante à tester avec Pfsense V2. Une plateforme de référence avec un GUI pour Squid + Squidguard ? A suivre.

Bonjour, D'après ce que je lis, je n'ai pas du tout comprendre de l'utilité d'un PFsene… Mon besoin est de faire un portail captif avec prise en charge d'un serveur radius, et prise en charge de VLANs. Dans mon cas, si une personne possède un compte il entre ses identifiants, et se fait contrôlé par le radius, et dans le cas d'un client, il accèpte les règles d'utilisation et se fait "logger" sur un compte générique avec aucun accès au réseau interne de l'entreprise, mais directement relier par une passerelle à notre firewall. Me trouvant presque dans la même situation que shnakeur, est-ce que mon choix de placer un PFsense sur une Appliance entre mon routeur FAI et mon switch/contrôleur Wifi est une bonne solution ou trouvez vous ça inutil aussi? (A savoir que je comptais utiliser le PFsense surtout pour faire la limitation de débit pour les users clients.) Dans le cas de l'inutilité, que conseilleriez vous pour un portail captif de ce type de gestion de hotspot? D'avance merci pour votre réponce.