@chris4916 oui effectivement via mode commande

Petit point supplémentaire: c'est triste mais le client LDAP de pfSense est fortement influencé par le fait que la grande majorité des serveurs LDAP est constituée de AD. du coup, ce client fait des suppositions sur le container pour virer la partie "domain component" s'il en trouve une, sans quoi il fait un merge avec le baseDN. Du coup, si to basedDN est "o=exemple" et ton conteneur user est "ou=user,o=exemple", tu devrais configurer celui-ci dans pfSense en tant que "ou=user" uniquement.

Je suis totalement d'accord avec awebster : tout ce qui est écrit est parfaitement exact : les protocoles qui 'mangent' quelques octets à la trame maximum, et donc, réduisent le MTU. (Le 1492 du PPPoE est bien connu.) (Autrefois, on configurait les 'bastions' (=firewall) pour refuser les paquets avec fragmentation !) Ce que je veux dire, c'est de penser au MTU qu'en dernier. Par exemple, puisque c'est l'accès à des NAS et la navigation dans des partages (Windows, donc CIFS/SMB), on aurait pu d'abord penser à des problèmes DNS. On doit modifier le MTU qu'en cas ultime !

Bien évidemment ! Il est notable qu'il n'y a plus guère d'âmes charitables, qui offrent leur connaissance gracieusement, ce qui est, à la fois, la conséquence logique et la marque de ce déclin. Mais je note le silence assourdissant de la modération : à minima, la suppression des fils inutiles, redondants, mal posés ou qui finissent en jérémiades stupides ...

Et on dira que l'on est des vieux cons ... Mais que faut-il penser des jeunes cons ? Non, mais je le crois pas : on s'inscrit, on ne lit rien du minimum requis, on créé un fil avec rien comme infos, on reçoit une mise en garde, et on supprime ce qu'on a écrit et on se désinscrit ! Il y a de toute évidence un manque de maturité, un manque d'éducation ... Un manque de respect des autres : je VEUX une réponse même si je suis incapable de demander normalement c'est à dire en posant un problème avec des infos ... au risque d'avoir une réponse !

J'avance : Deux problèmes : 1- Par défaut pfsense bloques les réseaux 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Voir arcticle de NetGate : ICI Ce doit être surement utile mais bon comme beaucoup de box sont dans ces adresses là il est dommage que ce soit actif de base. ou j'ai pas compris l'utilité du truc ! 2- Problème de config de Box Après cette modification, je recevais bien mes trames depuis le réseau entre Pfsens et ma box (Merci les logs) mais pas depuis internet et là c'est de ma faute (et un peu aussi de la box SFR qui a plantée et que j'ai reconfiguré à l'arrache) -> l'adresse de la DMZ dans la box n'était pas celle de pfsense et donc les demandes issues de l’extérieur n'arrivaient pas. Pas contre je comprends pourquoi le flux internet marchait ! En résumé le port forwarding marche très bien si : on créer les règles dans FireWall -> NAT -> Filter rule association = add associaed rule. Comme ça la règle dans le FW est automatiquement créer et lié au port forwarding. [image: 1572124120282-image-7.png] Si dans le menu Interface -> WAN : on désactive 'Block private networks and loopback addresses' et 'Block bogon networks' ATTENTION CA MODIFIE LA CONFIG DHCP ! du WAN [image: 1572124222540-image-6.png] Si cela peux aider quelqu'un !

D'accord et merci @Tatave ! J'avais mal comprit a cause du schéma... je vais voire pour me procurer un point d’accès wifi !

Thanks for your reply @kiokoman ! I will try that !

@GPR313 said in pfSense en FRONT sur VM ne communique pas avec l'extérieur: IP Desktop : 192.168.0.10 IP PF : 192.168.0.1 Mauvais choix en ce qui concerne le numéro de réseau. Nous avons déjà expliqué pourquoi à plusieurs reprises. Par ailleurs, d'expérience, la doc OVH est inexact en ce qui concerne le fichier de configuration réseau pour Debian / Ubuntu. J'ai résolu le problème il y a quelques années et signalé le point au support. Je ne sais plus ce qui est faux. Je me souviens vaguement d'un problème avec les lignes post-up sont inutiles ou fausses. Le problème s'était posé alors que nous avions un Cisco asa matériel en front sans nat.

Ccnet +1 pour tous sujets (je suis très exceptionnellement en désaccord avec ccnet : ça se compte sur les doigts d'une main et sans doute d'un amputé !) WSUS n'est pas très difficile à mettre en oeuvre. Cela économise de la bande passante puisque c'est la seule machine qui va chercher les mises à jour Windows, et les autres vont chercher dessus. Snort est une fausse bonne idée : cela n'a d'intérêt que quand on a la compétence et le temps pour interpreter les alertes. Le fait de l'implanter sur le firewall, ce qui n'est pas la bonne place, montre une certaine méconnaissance.

@jdh said in Itinérance réseau entre site local et distant: [...] elles devraient être connectées sur un port supplémentaires du firewall dans une zone dédiée Wifi, ... Je suis bien d'accord avec ce point. Mais je suppose qu'a l'époque où cette topologie a été conçue ils n'ont pas souhaité investir dans un pare-feu et donc sécurisé cette exposition "publique" en la limitant au serveur FTP. Chose que aujourd'hui ils souhaites reconsidérer.

mikrotik, j’ai configuré deux vlans (10 et 11) pour le lan. Pfsense est installé dans un serveur xcp-ng, Je ne comprend pas la nécessité de cet empilement, en tout cas pas avec les explications fournis.

Je suis d'accord avec ces précisions sur l'usage d'un splitter. (Je résumais avec '2 canaux' sous entendu distincts et c'est cohérent.) De facto, je ne sais pas si votre besoin est un splitter : cela ne semble pas utile à votre cas. Votre schéma montre que vous avez un pfsense qui réalise 2 choses : il est connecté aux différents WAN et à la fibre en sus du LAN. De mon point de vue, il y a 2 besoins : d'une part, relier les N WAN aux M réseaux internes : un seul pfSense ou un cluster de 2 pfsense), d'autre part, il y a la fibre. Et là on revient à l'interrogation : la fibre est-elle privée ou non.

Bonjour à tous, et merci beaucoup pour vos réponses ! Elle sont très instructive et complète ce que je ne savais qu'à moitié. Merci beaucoup pour votre aide, je vais corriger le problème dès mon retour au travail. Ce problème montre, au delà du sujet initial, que c'est au début qu'il faut bien réfléchir, car c'est bien plus complexe de modifier par la suite ... Oui cette conclusion est totalement vrai, mais je rajouterais que pour cela, il faut bien maîtriser son sujet, et comme l'informatique est un vaste sujet, on en apprend tous les jours et certains projet débute sans grande connaissance.

Dès qu'il y a 3 interfaces, il y a une interface OPT1 (qui est souvent renommée mais qui existe aussi sous le nom initial) Dès qu'on veut faire du 'Traffic Shaper', il faut configurer toutes les interfaces, même pour ne rien faire de particulier sur certaines ! Merci d'éditer le post 1 et changer le titre car il est NUL ! Edit 4/10 : c'est même chiant de lire un titre nul 3 fois par jour ...

Je suis désolé mais je ne comprend pas grand chose à ces explications.

Je te rassure, je n'en suis pas a mon premier essai en terme d'infra réseau et je ne comprends rien non plus même devant mon installation, je vous ai passé des détails encore plus tordus comme le fait que je vois revenir la réponse icmp par le tunnel mais le SNS les bloque car il n'a pas vu passer la requête initiale (c'est pourtant lui qui la route vers tun1)... bref c'est trop compliqué dans l’état pour être résolu ici même avec un schéma. Je pense même changer complètement la topologie car même si c’était fonctionnel comme ça, ça n'est pas propre, le stormshield ne permet pas de faire une route vers ses interfaces vpn depuis l'interface web, j'ai été obligé de la faire en ligne de commande, le problème est peut être tout simplement la. Le sujet peut etre clos. Merci

Avant même d'avoir ma réponse de @jdh j'était parti sur cette optique la. Merci quand même.