@Tatave said in SNORT : aucune action: elle s'intercale entre le point d'entrée et le(s) serveur(s) de mails. il faut également intercaler ce composant à la sortie. Mais il semble que mailcleaner ne supporte pas, par défaut en tous cas, DKIM et DMARC. Ou alors la documentation (de la version commerciale, car il n'y a pas de doc avec la version community) ne le mentionne pas.

De la même façon que Microsoft et bien d'autres poussent le dns encapsulé dans https (dns over https). Dans les deux cas en pratique nous n'y sommes pas.

Merci beaucoup, je n'étais pas sur que le problème venais de la config de squid

A mon avis, c'est une mauvaise idée que de vouloir passer l'intégralité du flux via un VPN. Il est bien préférable que chaque matériel qui télécharge (à donf) ait le vpn actif (puisque tel est le but d'utiliser un VPN). Exemple de choses ennuyeuses : si le VPN est totalement actif, il faut avoir le dns du fournisseur vpn, et il sera lent ... ça peut expliquer des difficultés d'accès. Je ne vois ici que ces 'besoins', je ne vois aucun test, aucune mesure, aucun log : la magie n'est jamais fournie !

"search list" correspond à un deuxième aspect (lié au DNS également j'en conviens) qui consiste à vouloir chercher "serveur.siteA.domain.fr" lorsque tu tapes juste "serveur". Donc oui, si tu utilises des hostnames plutôt que des fqdn, il faut bien renseigner cette option pour étendre la recherche à toutes des zones DNS et donc là tous tes sites.

Nous ne savons toujours pas quel est l'objectif visé. Proxy ou l'ip source sera votre ip publique.

L'aspect physique est possible, mais j'ai essayé (et pas réussi) de vous faire comprendre que l'idée est peu fine. Il est plus intelligent d'avoir un matériel dédié au load-balancing avec les ports adaptés, devant le vrai pfsense, qui devra lui aussi avoir les ports adaptés. Il est illusoire d'obtenir 2 giga en groupant 2 liens giga : on doit pouvoir obtenir 1,5 ou 1,6 giga peut-être mais tous les éléments de la chaine sont ils adaptés ??? Je serais curieux de savoir, dans quel contexte, on peut saturer un lien internet d'1 giga et où on confie le job à un expert qui choisit pfSense.

Il faut toujours écouter ccnet ... (règle n° 1) Dans la pratique, on écrit les 3 règles (d'autorisation) puis la règle d'interdiction totale. Si ce qu'écrit ccnet ne fonctionne pas, c'est que vous avez quelque chose en plus ... que vous n'avez pas décrit, par exemple, le proxy Squid !? Quand on a un problème, il est toujours beaucoup mieux de fournir plus d'informations que pas assez, d'où l'utilisation, que je recommande fortement, du formulaire A LIRE EN PREMIER. NB : en fait vous ne devriez même pas avoir besoin de la règle 1 (53/udp = dns) car les pc internes ont probablement leur adresse en DHCP et reçoivent le pfSense comme serveur DNS.

Bravo, connaitre et reconnaitre ses limites est le début de leur dépassement ! (Qui n'a pas de limites ? Pas moi.) Tatave donne un bon début de réponse : sensé et avec du sens. Un proxy basé sur de la transparence et de l'interception SSL est voué à l'échec. Un proxy transparent est un proxy non explicite : on passe dedans sans le savoir ! C'est très limité parce que cela ne fonctionne qu'avec HTTP, or la majorité des sites sont en HTTPS. L'interception SSL est destiné à faire du transprent en mode HTTPS. Pour ce faire, il faut 'casser' la sécurité SSL, le S du HTTPS, et par conséquent remplacer le certificat initial par un autre qui sera accepté par les micros internes : ceux ci accepteront n'importe quel certificat sans pouvoir vérifier le certificat d'origine, ce qui devrait être toujours fait ! De facto, il est impossible de vérifier la sécurité initiale du site, et bonjour les faux sites ! C'est très dangereux et menteur. De plus les sites HTTPS migrent vers un petit complément (HSTS) qui empêchera la casse ! Je ne reviens pas sur la nécessité de disposer d'un proxy dédié au lieu de surcharger le firewall. Pour 30 utilisateurs, il est probable que vous avez un serveur virtualisé, alors une VM de plus ne devrait pas poser de problème. Réaliser un proxy dédié est instructif (mais exigent et ça rebute certains) : on peut partir d'une simple Debian Buster, installer Squid, SquidGuard, LightSquid, et s'inspirer des fichiers de conf de pfSense.

c'est pas totalement mal, c'est juste risqué quand on ne prend pas en compte les failles de sécurité que l'on ouvre en faisant ca, mais aussi que l'on ne les rebouche pas non plus, autant vider la mer avec un dé a coudre. le mieux serait de mettre le proxy comme le vpn s il y a derrière le pf ou n'importe quel FW. apres libre a vous de faire du tout en une mais dans votre cas je ne m'y amuserais pas, les retour de batons juridique qui en découlent font mal. c'est pas les merdeux qui font avoir a faire un tour a l'ombre pour du hack ou d'autre bétise mais vous si vous ne savez pas ce que vous faites, et le directeur d'établissement aussi, sans parler d'une révocation des rangs du gros pachyderme qu'est cette institution, (c'est du vécu) bref, la baballe est dans votre bas a sable si je puis dire

Merci beaucoup pour vos aides qui ont pu m'aiguiller, j'ai réussi à mettre en place le site-à-site avec d'un côté le pfSense et de l'autre l'OpenVPN en mode ligne de commande. Il manquait juste le paramètre sur le fichier de configuration pour router les paquets vers le réseau distant (l'ajout de la route via le tunnel VPN) et quelques autres paramètres qui devaient être similaires à ceux que j'ai défini sur le pfSense. Je peux correctement accéder en SSH à ce dernier via le poste de management. Merci à vous.

Bonjour à vous, Merci pour ces réponse, je vais étudier ces alternatives ;)

ça m'a l'air plutôt correct. On utilise généralement proxy.pac plutôt que wpad.dat qui est lui utilisé par Microsoft, raison pour laquelle le serveur web qui sert ce fichier utilise également, le plus souvent des alias pour que, quelque soit le nom demandé, le fichier soit bien retourné, mais à ce détail près, ta conf me semble correcte. (il y a même des browser qui cherchent wpad.da)

@jdh

il te faut un portail captif par VLAN puisque le principe du portail captif c'est d'intercepter le flux http du client et faire une redirection vers une page web prédéfinie quel que soit le lien demandé. C'est tout à fait réalisable avec pfSense https://docs.netgate.com/pfsense/en/latest/captiveportal/captive-portal.html sans modifier ton choix de plan d'adressage si celui couvre tes besoins

Ces erreurs proviennent du blocage par defaut de pfsense sur l'interface WAN. Le problème n'est pas résolu, mais cela avance.

@Tatave said in Pfsense et 3CX: !!! Hé les gars vous êtes sur un forum pfsense ok , mais dans une section francophone. !!! Si cela ne vous écorche pas trop merci de rédiger vos réponses dans la langue de Molière ou dans un le cas ou cela vous défrise, faite déplacer le topic dans la section anglophone pour ne pas plus polluer la section. A vous de voir. Bonjour à vous, J'ai posté dans la section Française car je préfère de l'aide en français en effet. Le "Hic" c'est que la seule personne qui a bien voulu répondre à mon post pour m'aider est un anglophone. Soit c'est un manque de chance , soit c'est magique, à vous de voir. Personnellement, quand je cherche de l'aide, je m'adapte à la personne qui est susceptible de m'aider. Si cela pose un problème, je ne doute pas que les modérateur de ce forum agirons en conséquence. Pour autant. j'ai fini par avoir une solution à mon problème. Et je dois dire que je suis bien tenté d'aller la poster dans la section anglophone, suite à votre remarque (que je comprends au demeurant). Mais comme je ne suis pas mauvais joueur, je vais quand même la mettre ici. Le problème venait de l'usage de l'IPV6. Il était activé sur mon réseau local. Depuis que je l'ai faire disparaitre de la configuration du pfsense, mon 3CX fonctionne normalement. Thanks to all who have try to help me. Pat.

Il suffit de faire juste le test : un pc avec le proxy configuré dans Internet Explorer/Edge/Proxy lancer windows update regarder le log de Squid (tail -f) Ou rechercher Squid + Windows Update Le devoir de conseil s'impose vis à vis d'un client : il y a 30, 40, 50 micros, un serveur WSUS s'impose !

La seule option qu'il te reste, est d'utiliser la page "logout" - voir le paramétrage du portal captif. Mais, malheureusement, cette page s'affiche rarement correctement - les plupart des navigateurs n'affichent plus les pages 'popup'. Ce qui fonctionne très bien : demande les utilisateurs de ton portail de 'quitter' l'accès wifi, par sélectionner un autre, voir désactiver le wifi. Ce qui va ramener le trafic vers zéro. Ainsi que le soft-time-out va supprimer le login. T'as qu'à mentionner cette question/manip sur la page login : tout le monde va le voir .... Ici, un peu vers la fin je propose une autre solution.