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.

Depuis l'interface il sort une erreur pour la mise à jours automatique,

Quelle et erreur et que reportent les logs lors d'une tentative ?

J'ai un don pour me prendre la tête pour rien :-
le plugin check_icmp convient:

pour l'adsl en bridge >>  -s pppoe0

[2.1.4-RELEASE][root@pfsense]/usr/pbi/nrpe-i386/libexec/nagios(41): ./check_icmp -H 8.8.8.8 -s pppoe0 OK - 8.8.8.8: rta 30.930ms, lost 0%|rta=30.930ms;200.000;500.000;0; pl=0%;40;80;; rtmax=31.136ms;;;; rtmin=30.291ms;;;;

pour le sdsl en ipfixe >> -s vr0

[2.1.4-RELEASE][root@pfsense]/usr/pbi/nrpe-i386/libexec/nagios(42): ./check_icmp -H 8.8.8.8 -s vr0 OK - 8.8.8.8: rta 13.408ms, lost 0%|rta=13.408ms;200.000;500.000;0; pl=0%;40;80;; rtmax=22.817ms;;;; rtmin=9.667ms;;;;

Merci à toi ccnet pour les informations je vais voir pour le support en mode pont

grand Merci

@zozo:

je ne trouve pas le moyen d'accèder au bios afin de modifier la date et l'heure sur un Netboard A10 Rack Appliance avec pfsense. Vous n'auriez pas une idée?

De plus ce problème n'a rien à voir avec Pfsense. C'est un problème spécifique à votre hardware !

bonsoir et..

mille excuse ….

charge processeur en fait c etait update cpu et je passe d u onglet a l autre etc...

bon trêve d excuses j ai merdouille , pas de perte cpu mauvaise lecture .

desole :-[

a+

Le problème a été (au moins partiellement) résolu. Peut-être minato6 fera t-il un petit feedback plus détaillé ici.
Pour résumer:

faire fonctionner le portail captif avec LDAP (ce qui est cahier des charges initial) nécessite d'empiler, avec des configurations cohérentes, pfSense, le portail captif, un serveur Radius et un serveur LDAP (qui en l’occurrence n'est pas AD  ;)) il y avait des soucis dans le fonctionnement du serveur LDAP (avec comme je l'ai signalé, des messages de type bad checksum) il fallait, dans le cadre de cette configuration de lab, apprendre un minimum de choses sur le fonctionnement de LDAP. Bien que le protocole soit simple, en partant de zéro ça peut paraître compliqué  :-\

Une fois ces différents points adressés, ça fonctionne suffisamment pour démontrer la faisabilité et les conditions de réalisation, encore une fois "pour un exercice de labo". Avant une mise en production éventuelle, il reste plein de points à adresser. Par exemple le déploiement d'un serveur LDAP est un projet à part entière qui est au coeur d'une problématique de type "gestion des identité" (mais pas uniquement).

Pour compléter, d'un point de vue LDAP, le point soulevé par Florian22:

le login LDAP peut être n'importe quel attribut de l'entré, pour autant que celui-ci est unique dans la branche recherché. Avec un serveur LDAP classique, on utilise très généralement l'attribut UID qui est également souvent le RDN de l'entrée. Microsoft, comme à son habitude, a un peu perverti les choses en
  => utilisant CN comme RDN  :o :o :o
  => n'utilisant pas UID mais SamAccoutnName comme attribut contenant le login équivalent à l'UID

par ailleurs, la généralisation de la notion de domaine (au sens Windows du terme) avec, et ce point est dans le principe très positif, la généralisation de l'utilisation de Kerberos fait que le mécanisme d'authentification est souvent basé sur Kerberos qui demande un login dans le cadre d'un contexte (domaine), d'où la confusion, entretenue par le fait qu'il existe un attribut dans AD qui associé CN et domaine et permet donc de s'authentifier en s'appuyant sur LDAP mais avec cette notion de domaine "incluse".

Je vous invite à faire attention à ce point lors de la configuration, pour ceux qui l'utiliserait du package FreeRadius dans sa partie LDAP: la section qui décrit le "stripping around @" adresse exactement ce point.

Pour l'utilisateur final, la difficulté est qu'il ne sait pas nécessairement si l’authentification qui lui est demandé est LDAP ou Kerberos (et ce n'est pas son problème  ;D)

@minato6: si le problème est, comme je l'écris, "résolu", je t'invite à éditer ton premier post et à préfixer le titre avec [RESOLU]  ;)

Salut salut

Je pense que manifestement c'est un soucis de compréhension nous en sommes tous et toutes d'accord.

Les manques sont multiple ;

sur  la virtualisation en général et particulièrement esxi précisément en premier. sur les pare feux et particulièrement pfsense en deuxième. sur les concepts théorique et pratique liées à la notion de haute disponibilité informatique.

Je vous conseillerais ;

en premier lieu (si vous le pouvez) en physique,
C'est a dire sur une machine avec 3 cartes (2 wan 1 lan) en vous référant à des tuto pour traitant du concept du FO/LB sur les liens wan1/2 en deuxième lieu de rajouter une deuxième machine pour faire du cluster pf (dans votres cas c'est avec 4 cartes sur chaque machine. en troisième et ou en parallèle de vous servir de votre esxi distant avec la documentation qui n'est pas inexistante de monter votre projet.

Il est important de noter que vous n'etes pas le/la seul(e) à vous casser la tête avec ce type de projet de virtualisation et plus précisément d'un cluster pf mais pas que.

j'Up ce topic.

J'ai posé la question sur le forum anglais avant de me faire supprimer les messages.

même problème en 2.2 pour du FTP sortant avec le client ftp.exe (aucun problème avec les autres).
Sauf que je n'ai pas la main sur le produit ftp qui est livré par une éditeur logiciel et qui ne propose une autre solution que si on paye lourdement.

j'ai installé le package FTP Client Proxy mais la réponse obtenu sur le support c'est qu'il ne sert pas à régler mon problème.

Quand on gère 2 sites (ou +), c'est encore plus simple.

Attention, je répète, une fois la règle configurée, une fois la règle testée, elle fonctionne !
C'est comme un robinet : le robinet peut-être ouvert mais la qualité de l'eau qui y passe n'est pas dépendant de l'ouverture !

Vous ne savez pas poser un problème correctement, ce qui rend sa résolution difficile. Tout ce que je peux vous dire, de ce que je comprend : mettez une règle sur Lan pour interdire la destination 72.32.32.10.