@chris4916: @Tatave: …/... à laquelle je rajouterais un proxy du coté de ton lan et bien évidement les clients paramétrés pour passer par le proxy lan qui lui va interroger le revers. j'avoue ne pas bien comprendre la finalité  :-[  si tu pouvais développer un peu  ;)  il y a peut-être quelque chose que j'ai raté.[/quote] J'espérais avoir un peu plus d'information à propos de ce design mais ce n'est pour le moment pas le cas. Ce design est intrigant et même en y réfléchissant plus en détail, je ne vois pas quelle est la finalité si on considère que l'objectif initial est de mettre à disposition l'accès à des serveurs web hébergés localement à des utilisateurs distants accédant via internet. Un reverse proxy peut cependant servir à des utilisateurs internes si celui-ci est placé en frontal de serveurs web(1). C'est un moyen efficace de fournir de la haute disponibilité ou de la répartition de charge. Dans ce cas, le positionnement du reverse proxy en DMZ, comme je le montre sur mon schéma, n'est probablement pas le meilleur choix. En cas d'utilisation d'un reverse proxy à usage (également) interne, si les utilisateurs locaux utilisent un proxy, le flux sur le LAN pourrait devenir: browser => proxy => reverse proxy => web server mais le proxy n'apporte pas grand chose, si ce n'est la gestion du cache, AMHA A noter que pour un utilisateur distant, si un proxy est déployé de son coté, le flux sera exactement le même  :)  sauf qu'entre le proxy et le reverse proxy, il y a le WAN  ;) Tatave, n'hésite donc pas si tu as une vue différente. (1): c'est assez courant dans les data-centre

Cette distinction se fait, le cas échéant, au niveau du portail captif pour lequel tu peux configurer un serveur Radius local ou distant. Il n’y a pas de vraie différence dans la logique de fonctionnement mais peut-être des différences dans ce que le Radius de pfSense permet (expose) en terme de configuration par rapport à un Freeradius "standalone"

il y a un malentendu j'ai l'impression Nous faisons avec ce que vous voulez bien donner comme information. Nous n’arrêtons pas d'expliquer qu'il faut donner des descriptions complètes. Même si le lien ne vous semble pas évident. Oui en effet, le problème venait du mode espion sur les vswitch Je n'ai jamais douté de l'origine du problème … L'essentiel étant que cela soit réglé et fonctionnel.

Évidement oui. La description de l'objet du package est pourtant très claire : Allows a pre-configured OpenVPN Windows Client or Mac OSX's Viscosity configuration bundle to be exported directly from pfSense. Finalement je ne sais plus de quoi on parle. Ced56 : un schéma et des explications claires seraient bienvenus.

Merci à tous de vos réponses et de votre aide.J'ai réussi à créer une connexion vpn,je vais maintenant en discuter avec mon tuteur pour améliorer la sécurité de l'entreprise. Mon erreur au niveau des vpn a était un manque de lecture poussée de la doc de pfsense vpn mais aussi des différents paramètres sur le serveur vpn. Merci à tous et à la prochaine

@Endast: Me reste maintenant à mettre en place le serveur radius pour l'authentification secure et puis à pouvoir gérer plusieurs points d'accès. et à marquer ce sujet comme [RESOLU] une fois que ça fonctionne  :P

bonsoir, merci pour vos éclaircissements. Aux vus de vos informations je vais m'accorder un délai de réflexion supplémentaire pour murir mon projet.

Pour mon premier problème,pour la mise en place du pare-feu et la configuration basique de pfsense,le problème était matériel. Mon disque dur et une carte réseau était disfonctionnelle.Merci de vos réponses

Ah oui, effectivement, si ton WRT était en mode passerelle…  ::) Comme quoi une description précise de ton environnement aurait fait gagner pas mal de temps. Une compréhension basique de ce qui différencie passerelle et routeur aussi  ;) Mais bon, si c'est tombé en marche  ;D ;D ;D

authentification des clients avec freeradius2(freeradius2 System 2.2.6_3 pkg v1.6.11)+captiveportal

Nous sommes bien d'accord sur ces définitions  :)

Dans phase 1, Advanced, avez vous essayer de ne pas activer l'option "Responder only" ? Des éléments de réponse dans les logs peut être ?

Je n'ai pas souvenir d'avoir eu à l'utiliser donc franchement je ne sais pas. Les logs de Pfsense contiennent peut être des informations sur la valeur effectivement utilisée ?

Hello, Je viens vous faire un feedback concernant mon problème de ping dans un sens et pas dans l'autre. Après de longue recherche en compagnie de notre amis Chris49 que je remercie énormément pour l'aide apportée. Celui-ci a mis le doigts sur la source de mon problème qui étais en fait le fais que je devais définir mon client dans le tab "Client Override" J'ai simplement définis dans cet onglet le remote network en laissant les champs tunnel et local vide. Si vous les remplissez vous avez peut être de soucis lors du lancement du client celui-ci recevra les routes en double. (Je pense qu'il les envois en double car que les ai définis coté serveur puis côté client Override, et il faut le faire sur l'un des deux seulement.) A la suite de quoi mon client c'est connecté, il étais biensure toujours capable de joindre mon Lan côté PfSense mais mon Lan pfSense étais lui aussi capable de joindre mon client. Le traffic fonctionne donc dans les deux sens ce n'étais pas un problème d'iptables au final. Merci au personne qui m'on aidé sur mon topic précédent comme celui-ci.

Mon objectif est d'inventorier l'ensemble des équipements (serveurs, switch, routeur et pare-feu) d'un projet fictif (je suis étudiant en informatique). En tout cas j'ai réussi à inventorier pfSense sur GLPI après avoir installé l'agent.

En écho à ton PM, je colle ici ma réponse qui peut servir à d'autre ou être une base de discussion publique. C'est fou le nombre d'étudiants qui ont un projet "pfSense" :-) ça va faire de l'ombre aux sociétés de service  :-X Désolé, la suite est longue  8) Je connais assez peu pfSense que j'utilise depuis peu. Il faut donc prendre ma réponse avec des pincettes pour ce qui est de cet aspect. En revanche, l'IAM est mon métier :-) Je ne comprends pas bien si le résultat de ton projet est une étude théorique ou une mise en œuvre pratique mais, dans tous les cas, je considère que gérer des comptes (utilisateurs) sur la machine qui fait office de firewall est un non sens d'un point de vue sécurité. Ce peut être en revanche un bon compromis dans un petit environnement (PME) qui va privilégier l'aspect "all-in-one" et simplicité d'administration mais compromis veut dire également concessions. Bref…. Ce qu'il faut bien comprendre, d'une manière générale, c'est que le serveur VPN est configuré pour s'appuyer sur un service d'authentification "à définir", lequel peut être le serveur pfSense lui même, LDAP ou Radius (et pas nécessairement un package Radius sur pfSense) Un autre paramètre de OpenVPN, potentiellement indépendant de la base de compte utilisée pour l'authentification, c'est l'aspect "cryptographique" de la connexion, lequel va s'appuyer sur un certificat coté utilisateur qui va être validé (ou pas) par le serveur VPN car celui-ci embarque, dans ce cas, son propre certificat. A ce moment, c'est du strict X509: si les certificats client et serveur sont issu d'un CA commun ou si il y a une cross-certification (qui correspond grosso-modo au trust du monde Microsoft), alors le certificat présenté par le client est validé. Si au niveau du serveur VPN tu actives la fonction de matching de l'utilisateur, le serveur VPN va en plus s'assurer que le CN du certificat présenté correspond au login de l'utilisateur. De la section ci-dessus découle 2 points importants: 1 - si tu veux gérer des PKI différentes pour différents type d'utilisateurs (par exemple des utilisateur permanents et des utilisateurs temporaires) alors il faut soit 2 serveurs VPN différents présentant chacun son propre certificat soit mettre en œuvre au niveau des CA de ces 2 PKI une cross-certification pour que le certificat serveur (VPN) unique valide (et soit validé dans un double hand-check X509) par des certificats utilisateurs issus de PKI distinctes. 2 - l'indépendance entre l'authentification utilisateur et le certificat présenté est toute relative si le serveur VPN force le matching  ;D ;D Qu'est-ce que ça signifie dans la pratique ? Tu évoques dans ton PM une idée genre "génération de certificat par script" pour une catégorie de la population. S'agissant d'un certificat utilisateur, ça me laisse perplexe  ???  la difficulté n'est pas là de générer le certificat mais de le transmettre de manière sécurisée à l'utilisateur avec tout ce que ça implique en terme de process et de vérification. Dans l'absolu, cette simple partie est un projet à part entière. En effet, il s'agit de mettre en œuvre l'infrastructure qui va permettre, à un utilisateur authentifié (et ce point est potentiellement critique)  de générer, depuis son poste de travail, un CSR qui sera ensuite envoyé au serveur pour signature et donc génération du certificat. C'est un peu plus qu'un simple script mais une application à part entière, avec quelques aspects tricky. Ne pas oublier que dès lors qu'il y a des certificats qui se promènent dans la nature, il faut gérer une CRL (révocations !) Tu trouveras sur le web quelques applications qui vont dans ce sens mais compte tenu de l'impact de ce genre de fonctionnalité, je pense qu'il est toujours souhaitable de se poser la question de "développement maison" vs. "application externe" vs. "PKI qui embarque cette fonctionnalité". Pour répondre à ta question sur le "bypass du CA de pfSense": 1 - ça montre que en parcourant tous les  tutos du web, tu as sauté quelques lignes (et tu as du mal lire la doc pfSense également :p) 2 - il suffit d'importer un certificat (dans la section CA de pfSense) signer par une CA externe et de l'utiliser au niveau de ton serveur VPN Et voila, la partie théorique de ton étude est finie, ou presque  8) Ou en tous cas, voila les grandes lignes, il te faut ensuite travailler sur les détails (par exemple apprendre un peu de X509 pour ne pas que ma description soit juste un truc creux ou incompréhensible)

@rjulie95: Je pense que c'est faisable, je vais donc continuer à chercher et si je trouve une solution, je viendrais l'exposer ici N'hésite surtout pas. Je suis très intéressé par la réponse  ;)  et je ne suis certainement pas le seul. En fait, je suis plus intéressé par "comment est-ce que ça pourrait marcher ?" que la mise en œuvre proprement dite.

Je n'ai pas accès a t'es screen donc difficile de bien comprend ton problème. Selon moi tu peux pas avoir deux sous réseau avec le même adressage. Si t'es en /24 sur du 192.168.0.x Ton second sous réseau sera 192.168.1.x Tout dépends de la longeur de ton masque. Ni non CCnet a raison je pense que pour éviter les problème il serais préférable que tu n'ai pas le même réseaux sur t'es pattes pfsense. Je regarderais les screen a l'occas historie de mieux comprendre ta problématique d'adressage.

Effectivement pousser une route pour chaque site distant est une solution. Il faut peut-être également vérifier ce qui se passe en terme de règle de FW  ;)

Merci Chris pour l'aide que tu m'as apporté sur Skype/Mail. Mon problème n'es pas résolus mais je vais reposer les choses dans un nouveau topic avec un titre explicite et une présentation concrète des routes règles FW. J'ai tellement manipulé tout ça que vous serez perdu et perdrais du temps avec des shéma plus à jour ou mal décris.