Bonjour à tous,

tout d'abord merci de vos conseils,
j'ai résolu mon problème en remplaçant le serveur Radius initialement prévu par une interrogation de mon Active Directory via requête Ldap et tous fonctionne
pour ceux qui serait intéresser voici différentes sources que j'ai amalgamé afin d'arrivé a mes fins
la plus pertinente : http://bzhmarmit.wordpress.com/2012/09/11/pfsense-configuration-dun-acces-vpn-client-sous-pfsense-avec-openvpn-et-authentification-ad/
d'autres bien serviable: http://blog.stefcho.eu/?p=528 ou encore http://blog.stefcho.eu/?p=492
voila en espérant que ce travail aidera certain d'entre vous
a bientôt

Merci c est bien ce que pensais mais j espérais qu il existait une solution pour contourner cela du fait que chaque tête de pont avait une ip publique différente.

Effectivement je pense mettre un boîtier avec pfsense sur chaque site et derrière un serveur de collecte qd cela est nécessaire.

Si l'on prend le mirroir OVH : http://pfsense.mirrors.ovh.net/pfsense.org/downloads/
Si on a un peu lu les documentations disponibles (http://www.freebsd.org/doc/fr/articles/nanobsd/howto.html), on comprend alors que, par exemple : pfSense-2.0.2-RELEASE-4g-i386-nanobsd_vga.img.gz est destiné à un support flash de 4g, quatre Giga Octets sur une machine à processeur Intel.

Le téléchargement d'une machine virtuelle est bien disponible… pour Virtualbox (fichier .ova).

Pfsense sur un esx, toutes versions confondues, nécessite la plus grande prudence, n'est utilisable qu'aux fins de tests et à proscrire en production. Mais attention à la complexité réseau sous-jacente induite par l'hyperviseur et sa gestion réseau. Celle ci fait que l'on en a vu plus d'un se casser le nez faute de maitriser les aspects réseau de Vmware. Ne parlons même pas de la folie furieuse qu'il y a à vouloir faire fonctionner tout cela avec une seule interface physique sur l'esx !

Non. Le reverse est bon.

Question "difficile"! il faut au moins drux clics depuis le forum dédié pour y accéder.

@krominet:

CCNET , JDH, pourquoi vous préférez donner votre (docte) avis  au lieu de répondre à la question ?

il y a une grosse différence entre essayer de comprendre pourquoi ça marche, ou pas et faire tourner un réseau en production en respectant les "bonnes" pratiques de sécurité…

Sans connaitre physiquement ccnet, je suis assez proche de lui dans la compréhension des problématiques réseaux et dans la pratique professionnelle dans diverses entreprises. Je n'ai pas mémoire d'avoir été en conflit sur un point de vue.

Je crois pouvoir dire que nous sommes 2 professionnels aguerris et nous avons une certaine expérience due aux nombres d'années et à la diversité des situations rencontrées. Nous avons acquis une pratique qui a affiné notre formation initiale.

Je crois que ccnet donne de plus des formations.

Le fait d'avoir fait tourner pas mal de réseaux en production, de firewalls, de serveurs nous rend habitué à l'analyse du pourquoi ça fonctionne ou pas !

Aussi, nos réponses peuvent éclairer celui qui a posé une question parce que, quelque fois, notre vision est différente.
C'est l'intérêt de nos réponses : pratiques, opérationnelles, vécues ou non, mais très souvent dans la bonne pratique !

Personnellement, je trouve très préférable de répondre par la bonne pratique quand on on voit la direction prise.
Je ne comprends pas ceux qui disent "l'autopsie me donnera raison" !

Vous ne donnez aucune information de configuration. Vous n'avez manifestement fait aucune recherche préalable. Très difficile en l'état de vous donner une solution.
La connectivité peut être en cause (nat, routage, filtrage, …). Un problème de certificat est possible aussi. Ou encore un problème de cohérence des paramètres cryptographiques entre les extrémités. Liste non limitative.

Merci jdh!

J'ai pris note de tous ces sites informatifs. reste plus qu'a surfer dessus  :P

Effectivement ccnet, je l'utilise sur mon installation privé (réseau domestique).  :-\

Peut être pas super quand son objectif est de recherche le risque 0.

Je clos!  :P

Merci Messieurs !  :P

Je vais donc utiliser cette solution, qui répond très bien à ma demande.  :D

Seriez-vous me dire pourquoi pfSense ne prend pas en compte la désactivation des logs dans l'option proposé?

Encore merci.  :P

layer7 est basé sur http://l7-filter.sourceforge.net/ C'est possible d'écrire (ou charger) des règles layer7, http://l7-filter.sourceforge.net/protocols
Il semble que http://fr.wikipedia.org/wiki/Dofus n'est pas à la liste.
Je pense qu'il sera plus facile à bloquer le jeu avec les ports qui utilise, http://support.ankama.com/en/faq/1331-problem-while-connecting-internet
Vous ne pouvez pas bloquer le destin TCP 443 (https) mais si les 5555 et 5556.
S'il faut passer pour serveurs de DOFUS vous pouvez étudier aussi si les adresses ip des serveurs sont toujours les mêmes et les bloquer comme destin.

Super!!!

Un grand Merci ccnet !!!

OK pour moi les logs sont maintenant activés!

Post Resolu !

On ferme !

Merci ccnet.  ;)

port forward –-> OK

ping patte WAN ---> OK

petit plus ---> OK

Le post me parait resolu.

Un grand merci à tous pour vos retours aussi rapide!!!  :)

Bonne journée!

En cherchant très peu : http://forum.pfsense.org/index.php/topic,50044.0.html

Le problème c'est que personne ne veut le faire.
Prétextant l'inutilité du français, ou l'inévitabilité de l'anglais.

J'ai commencé à participé à la traduction sur pootle.
J'ai posé des questions qui sont sans réponses. Ah, si. On m'a fait comprendre que que ça servira à rien.

Le wiki en FR. Pourquoi pas?
Je suis prêt à participer, mais il faut quelqu'un pour commencer.
Et il faudra quelqu'un pour vérifier la qualité (vu mes limites (sur l'anglais, et sur pfSense) ce ne sera pas moi).

Une bonne doc en FR reste nécessaire.

JDH propose une soution très intéressante : elle contourne le problème et apporte une autre possibilité :

Remplacer ce genre de règle :

par ça :

Permet de logger seulement les erreurs sans se retrouver avec un journal qui explose à cause des flux autorisés.

Merci JDH  ;)

Toujours aussi peu clair depuis Avril 2012. L'exposé du besoin de sécurité est quasiment incompréhensible. A priori une connexion internet suppose une ip publique.
Et toujours aussi peu de soin dans l'orthographe.

Authentification au près de l'AD et validation de certificats pour autorisé l'acès au réseau ? c'est pas mal non plus :)

Les alias imbriqués, outre que je n'en vois pas l'utilité, je ne suis pas certain que cela soit supporté.
Pour le reste je vais résumer brièvement mon point de vue.

Ou dire, en utilisant deux gateways j'ai 2 fois le range de ports.

Aucune utilité.

Comme j'aurais pu dire, utilisé une gateway pour les workstations et utilisé l'autre gateway pour les serveurs.

Si il y a un vrai besoin, professionnel, et on met les moyens nécessaires en place. Par exemple un abonnement Internet avec un /30 en adresses statiques et une segmentation des réseaux propres et vous utilisez du nat outbound.
Pour le reste vous avez cette "solution" avec un routeur intermédiaire.
Et pour finir, pour ne pas payer les services auxquels vous souhaitez accéder, les proxys anonymisant.
Vous n'arriverez à rien en compliquant de plus en plus les choses. Pfsense fonctionne conformément a ce qui est prévu. Ce qui est prévu correspond à des utilisations normales, saines. Il manque certaines fonctionnalités à la marge. Pour le reste on tombe dans le bizarre avec tous les risques que cela comporte.