Problème d'accès DMZ [resolu]

Juve

Schéma +plan d'adressage.
Le problème ressemble à du routage asymétrique.

geronimooo

ça me semble bizarre, mais apparament j'ai résolu le problème en ajoutant une règle à pfsense dans la zone LAN :

Proto Source Port Destination Port Gateway
TCP * * 172.16.254.1 80 (HTTP) *

Ce que je trouve étrange car il y avait déjà une règle comme celle-ci :

* LAN net * * * *

le shema était le suivant :

WEB______PFSENSE_____(192.168.1.0) réseau__________(192.168.1.254)Routeur_____(Multiple réseau)

|___________(172.16.0.0) DMZ

Sur mes postes la gateway étant le routeur (192.168.1.254), qui lui même à pour default gateway PFSENSE

Je sais pas si c très claire pour vous, voili voilou

ccnet

Une erreur de plume ?
Si le routeur est bien un routeur alors il comporte au moins deux interfaces et surtout est il connecté à au moins deux sous réseaux différents. Les postes situés de l'autre côté du routeur ne peuvent ps fonctionner correctement avec la gateway que vous indiquez, celle-ci étant situé côté Pfsense, c'est à dire sur le réseau 192.168.1.0/24. Il manque dans votre schéma les numéros des réseaux résumés sous le vocable réseaux multiples.

geronimooo

oui le routeur à de multiple pattes vers de multiple reseau, on dira 192.168.2.0/24 192.168.3.0/24 …
Mais cela n'a pas trop d'importance dans mon problème présent.

Actuellement, pour que le serveur de messagerie fonctionne correctement, je suis obliger de monter une ip virtuelle dessus, (IP qui se trouve sur la plage de mon LAN)
et de l'attaquer coté lan sur son ip virtuelle ^^

sinon si j'utilise l'ip de la dmz, il me bloque le traffic venant de mon lan :(

ccnet

Mais cela n'a pas trop d'importance dans mon problème présent.

Ha ? Permettez moi d'en douter compte tenu de la solution mise en place.
Cette solution est totalement hasardeuse (le mot est faible) sur le plan de la sécurité. Votre firewall va commencer à ressembler à un cable RJ45 avec à peu près les mêmes capacités de filtrage.
Il vous faut probablement :
1 . Paramétrer correctement vos postes de travail.
2 . Indiquer à Pfsense les bons réseaux sources pour en autoriser le trafic.

Compte tenu de la présence du routeur il est évident que les paquets qui arrivent sur l'interface lan de Pfsense, en provenance des postes, n'ont pas pour source Lan network.

geronimooo

Le problème est que j'ai remplacer un ipcop par un pfsense, car ce bon vieux ipcop ne me convenais plus.
Et que depuis ce remplacement ça ne fonctionne plus.

Question routage sur mon reseau, tout est bien routé, ainsi que sur fpsense, celui connais les chemins pour accerder aux différents reseaux
J'ai bien entendu créer un alias 'Réseau_LAN' avec toutes les adresses réseaux présente derrier la pattte LAN de pfsense

Je reviens un peu plus tard, dois partir en déplacement et je re sur ce problème

geronimooo

en m'inspirant de ce post : http://forum.pfsense.org/index.php/topic,22026.0.html

et surtout de ce message :
@jdh:

Comme il est mentionné, les onglets de la page "Rules" correspondent à l'interface d'arrivée du paquet (initial) de la session.

Exemple avec la ligne 1 : (le serveur DNS est en DMZ)
la règle 1, en DMZ, d'un flux dont la source est le LAN vers ce serveur DMZ n'a aucun sens ! (n'est pas dans le bon sens : elle devrait se situer dans l'onglet LAN !)

Dans l'onglet DMZ, il est logique que l'origine des flux décrits soit soit le DMZ subnet soit un serveur de cette DMZ, mais certainement pas un autre réseau !

La ligne 2 décrit un flux ne passant même pas par pfSense !

Avant de continuer, le NAT outbound est-il supprimé ? Il est essentiel que les flux LAN vers DMZ ne soient pas nattés !
Le NAT n'a ici d'intérêt que vers le WAN : l'outbound standard sera parfaitement suffisant.

LAN : PC + serveur dns interne
DMZ : serveur Web + serveur Mail

Flux venant de LAN :
1. LAN subnet -> any : icmp/8 : ping
2. LAN subnet -> any : tcp/80+tcp/443 : http et https vers WAN et DMZ
3. LAN subnet -> srvWeb : tcp/80+tcp/443 : http + https vers le serveur Web
4. LAN subnet -> srvMail : tcp/25+tcp/143 : smtp et imap vers le serveur Mail (ou pop)
5. srvDns -> any : tcp+udp/53 : accès dns depuis le serveur Dns

Flux venant de DMZ :
1. DMZ subnet -> any : icmp/8 : ping
2. DMZ subnet -> srvDns : tcp+udp/53 : accès au serveur Dns interne
2. SrvMail -> any : tcp/25 : envoi sortant de mail à partir du serveur Mail

Flux venant de WAN :
1. any -> Wan Address : icmp/8 : accepter de répondre au ping
2. any -> srvWeb : tcp/80+tcp/443 : hébergement par le serveur Web
3. any -> srvMail : tcp/25 : réception des mails par le serveur Mail

NAT :
1. Wan address -> srvWeb : tcp/80+tcp/443
2. Wan address -> srvMail : tcp/25

Pourquoi plus de règles ?

je ne comprend pas trop ces 2 règles sur la patte LAN :

2. LAN subnet -> any : tcp/80+tcp/443 : http et https vers WAN et DMZ
3. LAN subnet -> srvWeb : tcp/80+tcp/443 : http + https vers le serveur Web

La dernière ne serait elle pas superflux au vu de celle qui précède ?

Dans mon cas voici ce que j'ai :

geronimooo

et voici ce que me raconte les log du firewall :

voici ce que l'on me répond coté forum du serveur de messagerie :

"Tu n'as pas un firewall applicatif qui filtre les flux web ? Tu as généralement une taille pour le réponse body qui doit être à 512 ko.
Il faut regarder qu'il n'y ai pas d'IDS, IPS, Filtering ou autres …"

Entre temps une autre personne à rencontrer le même problème chez un de ces clients en installant le serveur Zimbra derrière une DMZ.

Si ça parle a quelqu'un ?

jdh

Le choix des adressages n'est pas top car n'est pas mentionné les masques !
Il est important de bien vérifier que les masques de réseaux soit parfaitement corrects.
Aussi, je préconise de rester sur des 192.168.X.0 avec un /24 très naturel, plutôt qu'un 172.16-31.0.0 dont on en sait si c'est un /12, /16 ou /24.

Car, pour ce qui est des règles, il semble qu'il y ait tout puisque des règles très larges sont mises en place.

Perso, j'évite la règle par défaut LAN : je préfère écrire les quelques règles réellement utiles.
Je ne comprends pas la règle 2 de l'onglet DMZ, encore une fois trop laxiste.
Je limiterai à 2 règles NAT + WAN pour stmp entrant et http entrant (avec port modifié OK).
TSE ou ssh serait accessible de préférence après OpenVPN !

Un schéma possible :

NAT : any/WAN Address vers srvmail sur smtp=25/tcp (entrée smtp)
NAT : any/WAN Address vers srvmail sur 8080/tcp local 80/tcp (entrée http modifié)

WAN : any vers WAN Address sur icmp/8 (ping)
WAN : any vers srvmail sur smtp=25/tcp (NAT entrée smtp)
WAN : any vers srvmail sur http=80/tcp (NAT entrée http)
WAN : any vers WAN Address sur vpn=1194/udp (OpenVPN)

LAN : lan subnet vers any sur icmp/8 (ping)
LAN : srvdns vers any sur dns=53/udp+tcp (dns)
LAN : lan subnet vers srvmail sur imap=143/tcp+smtp=25/tcp+http=80/tcp

DMZ : dmz subnet vers any sur icmp/8 (ping)
DMZ : srvmail vers any sur dns=53/udp+tcp, http=80/tcp (dns + maj du srv mail)
DMZ : srvmail vers smtpfai sur smtp=25/tcp (sortie smtp vers fai)

Peut-être quelques ajustements mais pas beaucoup plus …
Je mets systématiquement des icmp/8 pour tester la "connectivité" ip avant toute chose :
le ping fonctionne donc je peux ajouter les protocoles suivants !

geronimooo

Merci bcp pour ces explications, le réseau 172.16.254.1 est en /16 soit 172.16.0.0 ^^
j'ai mis des règle hyper souple devant le problème que je rencontrai, je vais les changer une fois celui-ci résolu ;)

sinon, j'ai enfin trouver la solution ^^ Honte a moi de ne pas l'avoir vu ^^
Dans mon serveur DNS J'avais bien changer un pointeur vers mon serveur de messagerie, mais pas tous ^^ ouh la honte
Une fois corriger, tous c'est mis a fonctionner

c'etait bien un problème de routage asymétrique ou problème de DNS ^^