Accès LAN à DMZ

someferdi

bonjour,
j'ai installé pfsense comme firewall sur un reseau comprend:
LAN: 10.200.1.0/24
DMZ: 10.200.2.0/24
WAN: x.y.z.0/26

L'adressage sur pfsense est:
interface LAN: 10.200.1.249/24
interface DMZ: 10.200.2.249
interface WAN: 212.y.z.2/26 (adresse IP publique)

Dans la DMZ j'ai deux serveurs: mail (mail+web) et dns:
mail: adresse IP 10.200.2.3
dns: adresse IP 10.200.2.4

Problèmes:

du LAN j'arrive à aller sur Internet;
du LAN je n'accède pas à mes serveurs situé dans la DMZ
d'Internet mes serveurs sont inaccessibles

Mes règles sont:
Aliases

virtual IP

Nat port forward

Nat outbound

Règles LAN

Règles WAN

Règles DMZ

ccnet

Sont ?

A tout hasard il faut aussi des régles de nat pour accéder depuis internet à vos serveurs.

Pour le reste attendons la fin de votre message.

jdh

beh euh ? mes règles sont … absentes !

Au fait, à quoi sert un serveur dns en dmz ? Pour moi, à rien, mais ...

NB : accéder de l'extérieur à des serveurs en dmz demande une règle (rules) ET un ligne NAT

someferdi

Bonjour,
les règles sont à présent disponibles

jdh

Je crois qu'il y a de sérieux problèmes de compréhension :

un serveur dns (en DMZ) est ABSOLUMENT inutile : il serait TRES TRES étonnant que vous soyez hébergeur de dns public
héberger un serveur de mail + un serveur web (+ …) ne nécessite ABSOLUMENT pas de multiples adresses ip public : une seule suffit ! Et donc il n'y a pas plus besoin d'adresses ip virtuelles
les règles DMZ sont inutiles (et la dernière dangereuse !)
la dernière règle de WAN est inutile : pas de service DNS vers Internet
dans les règles, il FAUT utiliser les alias (et pas à moitié)
NAT outbound est inutile en utilisant une seule ip publique (et ça simplifie bien !)
Pour les alias, utiliser une règle de dénomination genre srvxxxx pour les serveurs, portxxx pour les ports, ...

someferdi

Merci pour vos réponses.
1- J'ai mis le serveur DNS dans la DMZ car j'ai des sous domaines que je gère (genre subdomain.mondomain.bf)
2- le mail et le web sont sur la même machine: donc ils utilisent la même adresse IP

Si les règles DMZ sont inutiles comment accéder au serveur (mail) qui est dans la DMZ à aprtir du LAN et d'Internet?

J'ai activé le DNS forwarder avec l'adresse IP privée de mon serveur de mail: 10.200.2.3

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 ?

someferdi

Bonjour,
j'ai appliqué les règles que vous avez decrites et supprimé le outbound. Mes nouvelles règles sont:

virtual

aliases

NAT: Port Forward

NAT: Outbound

règles LAN

règles DMZ:

règle WAN

Les règles sur le outbound ont été supprimées.
J'ai mis les règles concernant le NAT dans les règles du WAN, je sais pas si c'est le lieu indiqué.

J'arrive à aller sur Internet, j'accède au serveur web à travers un navigateur mais je n'arrive pas à récupérer le courrier avec un client de messagerie en pop.
J'ai mis le serveur DNS dans le LAN.
Merci une fois de plus

ccnet

Je vous suggère, l'espace d'un instant, de mettre sur lan, en premier, une règle autorisant tout de lan vers any pour protocole any afin de voir si vous pouvez relever, dans ces conditions, le courrier via pop3.
Si oui désactiver la règle "passe tout" et vérifiez vos règles sur l'interface lan, activer les logs sur l'ensemble des règles de l'interface Lan pour identifier la raison du rejet.
Si non, vous avez un problème autre et là aussi les logs de Pfsense pourraient vous aider. Des captures de paquets pourraient s'avérer utiles si vous ne voyez rien.

jdh

(Il serait TRES utile de compresser les images avec un outil type RIOT parce le temps de chargement des images est horrible !!)

Nicolas BOILEAU : "Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément."

Prendre le temps de bien posez les problèmes, qu'est ce qui est nécessaire, que veut-on, …

someferdi

bonsoir,
j'ai mis la règle autorisant tout de lan vers any pour protocole any mais je n'arrive toujours pas en pop à recuperer le courrier.
Parcontre la recuperation du courrier en pop march quand je mets l'adresse IP du serveur de mail dans la configuration du client de messagerie

ccnet

Vous avez donc un problème de résolution de nom et Pfsense n'y est pour rien. Avez vous mis à jour correctement votre dns. Pour test vous pouvez aussi utiliser, sur le client, un fichier hosts.

someferdi

bonjour,
En parlant de résolution de nom, j'ai d'autres sous domaines qui marchent correctement (webmail.domain.tld, mysql.domain.tld, etc…). J'arrive à envoyer et recevoir à partir du webmail mais impossible à partir d'un client de messagerie d'envoyer et de recevoir.

Remarque: je suis plutôt familier à IPCOP (tout marche sur IPCOP) mais j'aimerais utiliser PFSENSE

jdh

(Les images ont elles changé de taille ? Cela reste horrible !)

Outbound NAT : évidemment c'est par défaut, mais il serait quand même souhaitable qu'il y une règle Outbound NAT pour CHAQUE réseau (Lan ou Dmz)

Si cela fonctionne avec Ipcop, il n'y a pas de raison que cela ne fonctionne pas avec pfSense.
Sauf que c'est très facile avec pfSense … si on commence par écrire ce que l'on veut et les conséquences de ce qu'on décide.

Je ne suis pas partisan d'ajouter une règle "tout permis" ou alors en dernière position et avec le log de façon à suivre les paquets passant par là.
En analysant ces paquets, on doit pouvoir en déduire qu'une règle n'est pas là ou est incorrecte.

J'aimerais comprendre pourquoi vous pensez qu'une règle WAN comme la ligne 4 peut fonctionner (alors qu'à moi, il me saute au yeux que cela ne peut pas fonctionner !) :

(Je n'ai pas la patience d'attendre l'affichage complet .... remplacer vos images si vous voulez être aidé !)

someferdi

bonsoir,
j'ai reduit la taille des images.
J'ai egalement ajouté une regle Outbound nat pour les réseau LAN et DMZ
Wan 10.200.1.0/24 * * * * * (10.200.1.0/24 est le LAN)
Wan 10.200.2.0/24 * * * * * (10.200.2.0/24 est la DMZ)

someferdi

bonjour,
j'ai toujours du mal avec pfsense, quelle est la signication de "interface" dans les règles? La règle porte sur ce qui entre ou sort par l'interface?

Ceci mes règles qui fonctionnent sur ipcop:
IPCOP: transfert de port

Merci pour l'aide

jdh

J'ai déjà répondu sur la question de l'interface (et c'est une différence capitale avec iptables !).
(D'ailleurs iptables ou pf ont chacun des défauts, c'est pour cela que les alias sont essentiels pour assurer la lisibilité des règles).

Il FAUT arrêter de penser en iptables ! (C'est comme en anglais : on arrête de traduire mot à mot sinon on ne comprend plus rien …)

Attention à ne pas confondre NAT et Rules :
une ligne NAT permet de générer une rule quand on créé, MAIS il faut modifier la rule si on modifie la ligne NAT !

Là l'image est illisible !
=> pour qu'une image soit lisible, il faut qu'elle ait ET des dimensions correctes ET une taille fichier raisonnable :
p.e. wanRule.gif : 510 pixels x 274 pixels et 7 Ko c'est OK, mais des règles ipcop en 106 pixels x 50 pixels c'est pas possible !
Encore une chose confuse pour vous !

someferdi

bonjour,
toutes mes excuses pour la qualité de l'image. L'image a été corrigée

someferdi

bonjour
pas de suite?

jdh

Je ne suis à ta place.

L'outil le plus utile : le crayon : pour décrire les objectifs, pour lister les étapes, pour cocher la progression.

La démarche : itérative ! "step by step" : le ping, la résolutions dns, le dhcp, l'accès à Internet, la réception de mail, l'envoi de mail, …