@Tatave:

Effectivement, je n'avais pas penser au dédoublage des câbles réseaux ^^.
N'ayant pas de soucis sur le nombre de câbles à tirer je n'y avais pas un moment regardé de ce coté là.

En faisant l'impasse sur le gigabit, ça marche ;-)

Bonjour,

Peux tu nous indiquer comment tu as fait pour t'authentifier via clef ssh et non password. Ça pourra certainement servir à d'autre.

Sinon, je vois dans le post précédent, qu'il fallait également modifier le prompt. A tu essayé ?

J'ai lu ceci :

Sur le Pfense, il faut modifier le prompt depuis le fichier .tcshrc , commenter la ligne set prompt d'origine et la remplacer par :
set prompt="# "

Cordialement,
Soulearth

c est à se demander si vous avez véritablement cherché quelques choses et si vous n'avez pas passé votre temps le bec ouvert que la solution tombe toute.

Aider oui.
Assisté non.

La nuance est importante et énorme.
Pour le cout j'ai plus l'impression avoir assisté qu'aidé :(

@Axion:

une idée ?

Oui : https://forum.pfsense.org/index.php?topic=79600.0

Que tout cela est poussif … On est dans le basic du basic ...

Schéma :
Internet <-> Box (en bridge) <-> (WAN) pfSense (LAN) <-> switch <-> PC

Que doit-on vérifier au niveau de pfSense ?
Dans Status > Interfaces, il faut que

WAN obtienne une ip (publique), un masque (subnet mask), une passerelle (gateway), un dns (ISP Dns).
On peut faire le test des 3 ping : ping de la passerelle, ping 8.8.8.8, ping google.fr

Que doit on vérifier au niveau d'un PC ?
Soit il est en statique, et on a bien configuré une adresse ip, un masque, la passerelle = LAN de pfSense, un dns = LAN de pfSense.
Soit il est configuré en DHCP, et on vérifie qu'il obtient bien une adresse ip, un masque, la passerelle et un dns.
Ensuite on fait le test des 3 ping ...

Il est clair qu'initialement le premier PC est souvent configuré à la main, puis attaque pfSense et configure ce qu'il faut : DNS Server et DNS Forwarder.
Ensuite on configure les règles de l'onglet LAN à ce qui convient : la conf initiale est 'default allow', donc ne pose que peu de problème.

Tout cela ne doit JAMAIS poser le moindre problème à un administrateur de firewall !
Ou, à l'envers, si on rencontre des problèmes sur ces étapes très simples, c'est peut-être qu'on n'a pas les connaissances nécessaires à configurer un firewall ...

Merci de noter qu'il y a un modèle de formulaire à utiliser pour présenter un problème (cf fil 'A LIRE EN PREMIER') : merci de l'utiliser !

Bonjour,

Je suis sur la même problématique avec un U70 cependant je ne pense pas que l'on puisse faire grand chose en l'état avec ce type de boitier.

L'interface em0 est inutilisable tant qu'on ne peut pas piloter le contrôleur "vitesse vsc7398xyu", c'est lui qui permet d'utiliser les 6 ports du boitier.

Lors du démarrage de NS-BSD on peut apercevoir qu'il y a un daemon switch qui test ces ports.

C'est tout ce que j'en sais pour le moment…

Cordialement

Coté log firewall, il me dit que cela passe mais quand j'actualise après le plantage du téléchargement, je n'ai aucun log supplémentaire :

Apr 25 15:00:57 pf: 192.168.55.50.59548 > 192.168.1.30.80: Flags ~~, cksum 0x6278 (correct), seq 3742788345, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0

J'ai regardé dans Status/System logs/Firewall.
En espérant que je sois au bon endroit ?~~

@sab33:

Il y a une technique bien particulière pour le https ?

Technique particulière… oui et non  ;D

En mode proxy transparent, le flux http et redirigé (de manière transparente) vers le proxy mais pas le flux https qui lui passe tout droit au travers du firewall.

Pour faire court, il y a 2 modes de fonctionnements

1 - pas de proxy

2 - si proxy transparent :
        pas de SSL bump => seul HTTP passe par le proxy
        SSL bump => tout passe par le proxy mais il faut utiliser un certificat reconnu (trust du CA) par les navigateurs

3 - proxy explicite (tout passe par le proxy) :
        si pas de SSL bump, filtrage d'URL pour tout, filtrage de contenu pour HTTP
        avec SSL bump, filtrage de contenu pour tout

et pour avoir du proxy explicite (donc pas transparent) sans avoir à gérer les navigateurs, il faut mettre en œuvre WPAD  ;)

Je ne sais pas bien quoi vous dire tant la réponse est évidente. Il s'agit d'ajouter une entrée Arp statique sur Pfsense. Connaissez vous le rôle et le fonctionnement de Arp? Si ce n'est pas le cas commencez par apprendre celà. Les choses seront beaucoup plus claires ensuite.

@Yarglo:

Pourtant il me semblait que cette règle d'interdiction totale était implicite  : "ce qui n'est pas autorisé est interdit" du coup, j'ai l'impression que ça fait doublon.

oui elle est implicite et la gestion du log pour cette règle se fait, de la même manière que pour l'affichage des paquets acceptés, dans les settings du log

Log packets matched from the default block rules put in the ruleset
Hint: packets that are blocked by the implicit default block rule will not be logged if you uncheck this option. Per-rule logging options are still respected.

Bonjour,

Merci beaucoup pour tous vos retours.

Je sais maintenant ce qui à posé problème et comment ce dernier aurait pu être évité, à savoir :

si une gateway est définie sur une interface, elle a "priorité" sur les routes statiques. Un paquet qui sort par cette interface va à la gateway sélectionnée, quelques soit les routes statiques. pour bénéficier de 2 accès internet différents, il est préférable de mettre en place 2 WAN différents coté pfSense, avec 2 interfaces

Cordialement,
Soulearth

Oui absolument. Il peut être utile d'ajouter la règle de blocage pour tout ou partie des paquets rejetés afin d'activer les logs. Selon besoin bien sûr.

Merci beaucoup pour ces éclaircissement. je vois que j'ai beaucoup de choses a apprendre encore.
Je vais réorienter mes recherches vers les protocoles pour en apprendre d'avantage.
Cordialement

M'ouai je vais en virtualiser un je pense ;) après on a pas beaucoup de poste donc pas besoin d'ocs ou de supervision :)

@jeremyb:

Je suis vraiment désolé mais je ne vois pas comment faire une description du besoin fonctionnel…

Je veux bien essayer de reexpliquer, si cela ne marche pas faites le moi savoir !

L'authentification à mes points d'accès sont gérés par un portail captif puis un radius qui discute avec un LDAP.
J'ai donc deux portails captifs car j'ai deux types d'utilisateurs :

- le portail "privé" pour les utilisateurs qui appartiennent au groupe LDAP "PRIVE"

-Le portail "public" où tous les utilisateurs présent dans le LDAP peuvent s'y connecter.

J'ai donc besoin du portail captif car quand celui-ci émet une requête au Radius il possède et NAS et le traitement des groupes en fonction du portail captif est réalisé grâce à celui ci.
Autrement dit, les utilisateurs qui se connecteront à la WIFI privé mais qui ne sont pas dans le groupes LDAP PRIVE ne pourront pas se connecter.

Tout cela décrit des solutions techniques.

C'est donc cette option qui m'ai très interressante grâce au portail captif. Je peux donc gérer l'accès à un point d'accès wifi en fonction du groupe LDAP des utilisateurs. Bien sur , il n'y a pas la même bande passante pour les utilisateurs du WIFI privé et les utilisateurs du WIFI public. Il y aura également des restrictions horaires pour le Wifi public.

Là c'est un mélange.

Maintenant , sur mes deux points d'accès WIFI , un Squid ( le package de pfSense) est en écoute afin d'assurer la reuperation des logs. Il fonctionne en mode transparent car je ne voudrai pas obliger mes utilisateurs à s'authentifier plusieurs fois etc… Associé à Squid , j'ai également SquidGuard qui permet la restriction à des sites grâce à une blacklist.

Mon soucis apparaît maintenant :

Vu que mon Squid écoute sur mes deux points d'accès wifi , le port 3128 ( port par défaut ) est donc ouvert. N'importe quel utilisateur peut donc configurer son navigateur de façon à utiliser un proxy sur l'adresse de passerelle et sur le port 3128. À partir de là , le portail captif n'apparaitra donc plus car les requêtes seraient directement redirigees au Proxy et n'importe quel utilisateur pourrait donc accéder à Internet par la WIFI privé car il n'y aurait pas d'authentification... N'importe quel utilisateur pourrait donc bénéficier des privilèges de la Wifi prive ( Meme un utilisateur externe ( non renseigné dans le Ldap) vu qu'il n'y a pas d'authentification ).

Pour pallier à cette problématique , je pensait pouvoir autoriser l'accès au Squid seulement pour les utilisateurs connectés au portail captif. Je pensait donc que l'authentification au Squid par portail captif serait ma solution mais apparement pas.

Mon but est donc de bloquer l'accès au Squid aux utilisateurs qui ne sont pas connectés au portail captif ( tout en gardant le proxy en mode transparent si cela est possible... ).

Désolé, mais c'est encore de la description de solution technique.

J'espere que je me suis exprimé de manière un peu plus convenable et que j'ai su exprimer mon besoin.

Merci encore et merci beaucoup pour vos réponses , j'espere pouvoir avancer … !

Le problème n'est pas que ce soit convenable ou pas. Il faut poser le problème correctement.  Un exemple de ce qui pourrait être une début de description fonctionnelle. Sans préjugé de votre situation réelle que je ne connais pas.
L'entreprise est confrontée à deux populations différentes d’utilisateurs pour lesquels elle souhaite mettre à disposition certaines ressources et en protéger d'autres dans des conditions conforme à la PSSI.  Elle possède possède un réseau wifi assurant le transport des données.

C'est un exemple de début de descriptif qui n'induit aucune solution technique et qui prend acte d' une situation (Wifi). Je ne sais pas si cela correspond à votre situation. Probablement pas puisque vous avez du mal a expliciter les choses.
Je rédige cette réponse dans l'espoir que quelques uns comprennent de quoi il s'agit lorsque l'on parle d'approche fonctionnelle pour en déduire des solutions techniques adaptées à des contraintes et à un existant. Pour le moment vous êtes "tourné à l'envers", vous ne parlez que de solutions techniques.
Comme dit le faux proverbe chinois : Si tu ne sais pas où tu vas, tu pourrais bien te retrouver ailleurs.

@Chris4916 :

En dehors d'écrire des choses inutiles, vous avez déjà écrit (à très juste titre, et c'était clair et suffisant)

ce n'est pas très utile pour qu'on puisse t'aider plus.
As-tu un comportement à décrire, un message d'erreur, du log LDAP. Bref, autre chose que "ça ne marche pas"

Inutile de réécrire la même chose (sous une autre forme) : il y a des pistes, qui sont claires et simples, qui sont basées sur les mêmes mécanismes bien connu de PAM (certes pointilleux mais l'art …), il y a un membre qui l'a fait, bref il est largement possible de le faire ... Au lieu de ça ...
(Je ne comprends pas pourquoi cela n'a pas été jugé 'agressif' !)

Je suis en passe de devenir chef d'équipe, et j'ai largement des idées (des solutions) pour aller bien plus loin : permettre à un identifiant de se connecter n'est pas suffisant, encore faut-il savoir ce qu'il a fait ! (parce que c'est bien beau de permettre ...)
Mais je vais me taire puisqu'on m'attribue d'être une truffe ...

personne ne semble être suffisamment compétent

Ah non, alors là, pas d'accord !! Vous êtes très loin d'avoir le niveau pour porter ce type de jugement !

Personne, ici et probablement sur le forum anglais aussi, ne juge cela utile, ce n'est absolument pas pareil !

Terminé pour moi !

On ne voit pas d'où cela pourrait venir pour une première raison : on ne sait rien de votre configuration.
Avez vous regarde le forum anglais ? Il semble qu'il existe pas mal de problèmes avec cette nouvelle version. J'en profite pour rappeler les bonnes pratiques au moins pour le monde professionnel.
1. On ne se jette pas sur une mise à jour sans avoir validé qu'elle est nécessaire surtout si l'on a une configuration stable par ailleurs.
2. Si l'on doit faire la mise à jour (ce qui suppose que l'on a identifié une bonne raison) on commence par un environnement de test identique si possible à celui de production.
3. Si ce test se passe bien on s'assure de la viabilité des procédures de retour arrière. Sinon on attend par exemple la version suivant qui corrige les problème sidentifiés. Puis on reprend au début.
4. Alors seulement on migre l'environnement de production.

En ce qui me concerne et pour les différents clients chez qui la version de production est 2.2.6 il n'est pas question de migrer pour le moment. Le mco est prioritaire même si les mises à niveau en font partie.

Quel que soit le forum, il y a un minimum de règles sur chacun.

Ici un certain nombre d'habitués ont souhaité qu'il y ait utilisation d'un formulaire simple d'emploi qui soit systématiquement utilisé.
L'intérêt évident est que le demandeur mette dès le départ des infos et le lecteur les trouve.
Ce formulaire peut prendre 10' et fait gagner un temps précieux à tous les lecteurs en évitant le fil qui multiplie les demandes de précision.
Cela s'appelle simplement le bon sens.

J'ai toujours noté, que ceux qui ne veulent pas se soumettre à cette simple formalité étaient toujours des emmerdeurs finis, sans compter qu'ils venaient et disparaissaient aussi vite, et qu'aucun n'a jamais partagé avec la communauté la moindre connaissance ! Ce sont juste des petits profiteurs qui ne font que passer …

Beau vocabulaire : flic, facho (et non fascho) : même certains finissant par embrasser un flic ... vous semblez très éloigné de la poésie ...

Oui j'avais désinstallé le paquet du squid, fait la mise à jour puis réinstallé le paquet !!!!

Mais j'ai trouvé le problème !!!

Quand on va dans Services>Squid proxy server puis dans l'onglet Local Cache il y a un bouton Clear disk Cache Now j'ai cliqué dessus puis redémarrer le service !!!

Depuis plus de message d'erreur et ça fonctionne !!!!

Problème résolu

Laurent