Bug dans le filtrage ?

ccnet

Quand tcp 80 et 443 sont autorisés depuis le lan via GW_Failover_Web, alors vous pouvez vous connecter à machine Unbuntu situé en dmz sur le port TCP 22 (ssh), c'est bien ce qu'il faut comprendre ?

Deux trois choses pour essayer de dégrossir le problème :
Le port ssh n'a pas été changé sur la machine Unbuntu ?
Que donne un trace route ou un scan avec Nmap depuis le lan vers la machine Ubuntu, avec et sans la gateway ?
Pas de nat qui traine ?

Jey-B

Oui, c'est bien ce qu'il faut comprendre.

Il n'y a que du classique là, SSH sur port 22, pas de port mapping ou NAT.

Un traceroute depuis le LAN ne montre que l'IP pfSense côté LAN.

ccnet

Ok et un scan Nmap avec, puis sans la gateway ?

Jey-B

Je n'ai pas touché Nmap depuis… ptet 10ans.
Je viens de l'installer, mais ça commence mal. Nmap n'arrive pas à pinguer la machine en DMZ alors que j'y arrive depuis mon poste. ?!

Dans les options du scan, j'ai coché ICMP Ping (pensant qu'il n'utilise pas un ping classique pour tester).

Bon, je cherche et te donne le résultat dès que je suis arrivé à quelque chose.

Edit : j'ai bien un prb avec Nmap. Il fonctionne avec les machines du LAN, mais pas du tout avec les machines distantes (IP pfSense des 2 autres sites de la société, que je pingue sans prb depuis mon poste).
Edit2 : prb de multiple interfaces sur ma machine, ça se contourne en utilisant -S et en indiquant notre IP source locale. Prochain message, les résultats.

Jey-B

Le scan NMAP correspond à mes tests précédents :

Avec la règle qui permet le surf (80+443 uniquement) + Gateway forcée (1, ou un groupe pour le failover) :

PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https

Si je vire la gateway de la règle :
PORT STATE SERVICE
80/tcp open http
443/tcp open https
Soit le comportement attendu de cette règle.

Attends-tu + d'infos du scan Nmap ? Si oui, lesquelles ?

Jey-B

Même chose avec un autre réseau de la société (wan d'un autre site).
Si je scan le pfSense de l'autre site (via VPN IPsec), j'ai soit les ports 80 et 443 d'ouverts, soit les 80, 443 et 53 si pour ce dernier test une passerelle est définie dans la règle qui n'autorise que le HTTP et HTTPs vers toute destination.

Jey-B

Ca semble être le cas pour les sous réseaux de la société.

si je tente avec altern.org ou smtp.free.fr, j'ai un comportement normal lors du scan, avec ou sans gateway.

Jey-B

Une capture de paquets sur le pfSense sur l'interface DMZ montre, soit que seules les tentatives vers le 80 et 443 ne passent, soit, les 1000 ports du REGULAR TEST de Nmap sont transmises à la machine en DMZ.

grr, mais c'est quoi ce comportement ?!

Jey-B

J'ai activé le log de la règle qui permet le surf :

Dans les logs firewall :

Si aucune gateway n'est configurée, tout est bloqué sauf les paquets correspondant au 80 et 443.

Si une gateway est configurée, certains paquets sont autorisés (par ex, des broadcasts de machines du LAN).
exemple de destination :
10.10.18.255:8612
10.10.18.255:138

ccnet

Désolé mais peu de temps ces derniers jours pour me pencher sur le problème un peu sérieusement. Où en êtres vous ?

Jey-B

Merci :)

Y a pistes sur mon topic sur le forum anglais.
Je viendrai faire un récap dès que possible.

Le topic Anglais : http://forum.pfsense.org/index.php/topic,58304.0.html

Je ne comprends pas leur notion de "négation" (autre que ce que l'on peut activer manuellement dans les règles).

Jey-B

Problème réglé !

Depuis la mise à jour 2.0.2, une nouvelle option existe :
Disable Negate rule on policy routing rules
With Multi-WAN you generally want to ensure traffic reaches directly connected networks and VPN networks when using policy routing. You can disable this for special purposes but it requires manually creating rules for these networks

Donc j'ai testé, coché cette option. Résultats :

quand aucune gateway n'est configurée dans ma règle de surf (80-443), je peux accéder à ma machine en DMZ uniquement sur ces 2 ports, normal (ils tournent sur cette machine, en plus du SSH).
quand une gateway est configurée dans ma règle de surf (connexion aDSL), plus rien ne va faire ma DMZ ou mes réseaux distants. Ce qui pour moi est un comportement normal. Ca oblige de rajouter plus de règles.

Ce que je ne comprends absolument pas, c'est cette notion de "negate" ajoutée automatiquement (décrit dans mon sujet anglais, dont le lien est dans mon post au dessus).
Pourquoi, dans une règle qui n'autorise que le 80-443, tout devient permis sur les WANs/DMZ de la société quand une passerelle est ajoutée dans cette règle ?!

???