[RESOLU] Acces orange -> green (dmz pinholes), pb tordu ?

[kna]

Salut à tous

Je voudrais que depuis un futur serveur web en zone orange, un petit outil de maintenance puisse m'envoyer des mails, donc vers serveur mail interne en zone verte.

J'ai donc défini une règle dans Pare-feu / Accès à la dmz comme suit :

Proto : TCP
réseau source : orange
source : IP du serveur web dans orange
réseau dest. : vert
destination : IP du serveur mail interne dans vert, port 25

Ca ne fontionne pas !
Impossible depuis le serveur en orange d'envoyer un mail vers le serveur interne, même chose pour un telnet port 25 (alors que bien sur ça marche depuis une machine en green)

Dans la config IP du serveur web, j'ai l'IP orange de l'IPCOP comme passerelle.
Ajouté l'IP green de l'IPCOP comme 2ème passerelle, idem.
Appliqué la maj 1.4.5 sur la v1.4.4, idem
Rien vu dans le forum sur ce genre de pb, je sèche

Merci de vos lumières.

[m2nis]

Pas d'idée comme ça tout de suite, mais une chose me sert beaucoup dans ce genre de cas: le journal du pare-feu.

Juste après une tentative, allez y jeter un oeil. Réponse presque garantie !

--
Michaël.

[kna]

Pas d'idée comme ça tout de suite, mais une chose me sert beaucoup dans ce genre de cas: le journal du pare-feu.
Juste après une tentative, allez y jeter un oeil. Réponse presque garantie !

J'y ai bien pensé, mais hélas...
Ce matin je suis reparti de zéro : effacer les règles en place, tester un telnet port 25.
Dans le journal, je trouve bien ceci :
Chaîne Interface Proto Source Port source Adresse MAC Destination Port destination
OUTPUT eth1 TCP 192.168.0.2 1121 ::::: 192.168.1.202 25(SMTP)

Ca c'est bon. Je rajoute donc une règle qui autorise 192.168.0.2 (orange) vers 192.168.1.202:25 (green).
Nouvel essai, et... rien !
Plus d'entrée dans le journal du pare-feu, mais toujours "impossible de se connecter à l'hôte port 25".

[tomtom]

Es-tu sur que ton serveur mail dans le green autorise les accès depuis un réseau non local ?

t.

[kna]

Es-tu sur que ton serveur mail dans le green autorise les accès depuis un réseau non local ?

Salut Tomtom

La bourde de débutant : je n'avais pas vérifié, car de mémoire ok de ce côté.
Hélas... rien de mieux.

Le serveur mail en question est un vieux Quickmail sur MacOS, rien vu de restrictif, si ce n'est qu'on peut spécifier l'IP qu'est censée avoir un client. Désactivé, modifié, toujours pareil.

J'ai donc essayé vers une autre machine du green qui fait office de passerelle mail antispam et antivirus. Vérif d'une éventuelle restricition d'accés, ok, problème identique.

Nouvel essai d'un telnet classique port 23 vers un routeur dans green, après avoir rajouté le pinhole qui va bien dans l'IPCOP. Toujours le même problème, connexion impossible.

"Quelque chose" semble empêcher de sortir de la dmz vers le green, mais quoi ??

J'ai bien essayé sur l'IPCOP de scruter /etc/rc.d/rc.firewall avec VI, mais à mon niveau, autant essayer de décrypter les manuscrits de la Mer Noire...

Si qqu'un pouvait me donner un exemple de lignes que je *devrais* y trouver, je pourrais vérifier et au besoin les ajouter ?

Je désespère
Merci de votre aide.

[tomtom]

Est-ce que ton serveur en zone organge (DMZ) possède la bonne route par defaut (ie vers l'adresse orange d'ipcop..) ?

As-u à ta disposition un sniffer dans le green ?

t.

[kna]

Est-ce que ton serveur en zone organge (DMZ) possède la bonne route par defaut (ie vers l'adresse orange d'ipcop..) ?

Oui.
En allant vérifier la table de routage, je n'avais rien d'explicite concernant 192.168.1.0. J'ai donc fait un "route add", voici ce que ça donne :
===========================================================================
Itineraires actifs :
Destination reseau Masque reseau Adr. passerelle Adr. interface Metrique
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.2 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.2 192.168.0.2 1
192.168.0.2 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.0.255 255.255.255.255 192.168.0.2 192.168.0.2 1
192.168.1.0 255.255.255.0 192.168.0.1 192.168.0.2 1
224.0.0.0 224.0.0.0 192.168.0.2 192.168.0.2 1
255.255.255.255 255.255.255.255 192.168.0.2 192.168.0.2 1
Passerelle par defaut : 192.168.0.1
Itineraires persistants :
Aucun
===========================================================================

As-u à ta disposition un sniffer dans le green ?

Hum, non.. et là je me sens un peu perdu.
Le green est sous Win98/2000, quel outil simple à maitriser pourrais-je trouver ?

Merci de ton aide

[m2nis]

Le serveur mail en question est un vieux Quickmail sur MacOS, rien vu de restrictif, si ce n'est qu'on peut spécifier l'IP qu'est censée avoir un client. Désactivé, modifié, toujours pareil.

Si cela vous est possible, j'essayerais:
1- de mettre le serveur en question dans green et de voir s'il peut envoyer un mail
2- de mettre un autre pc dans orange et de voir s'il peut envoyer un mail

"Quelque chose" semble empêcher de sortir de la dmz vers le green, mais quoi ??

Par défaut, dmz -> green = impossible. Mais avec un pinhole, il n'y a normalement pas de soucis.

J'ai bien essayé sur l'IPCOP de scruter /etc/rc.d/rc.firewall avec VI, mais à mon niveau, autant essayer de décrypter les manuscrits de la Mer Noire...

Marche plutôt bien pour les choses simples (si je n'ai pas fait de c***eries, hein? ). Par exemple, pour interdire par défaut toute sortie de green -> red sans interdire green -> orange:

Dans la rubrique "# localhost and ethernet", mettre en commentaire (ajout d'un #):
#/sbin/iptables -A FORWARD -i $GREEN_DEV -m state --state NEW -j ACCEPT
et ajouter
/sbin/iptables -A FORWARD -i $GREEN_DEV -o $ORANGE_DEV -m state --state NEW -j ACCEPT

Enfin, ajouter dans /etc/rc.d/rc.firewall.local toutes les règles d'acceptation green -> red et orange -> green. Pour ce dernier, par exemple pour accepter qu'un serveur en orange accède au serveur de temps:
/sbin/iptables -A INPUT -i eth1 -s 192.168.0.xx/32 -p udp --dport 123 -m state --state NEW -j ACCEPT

L'intérêt d'utiliser /etc/rc.d/rc.firewall.local est qu'il ne bouge pas lors des mises à jour, contrairement à /etc/rc.d/rc.firewall.

Si qqu'un pouvait me donner un exemple de lignes que je *devrais* y trouver, je pourrais vérifier et au besoin les ajouter ?

J'espère que cela vous aidera... Sinon, il y a aussi le très bon site d'Antolien qui m'a permis de bien avancer : <http://ipcop.hn.org/>.

--
Michaël.

[tomtom]

Le green est sous Win98/2000, quel outil simple à maitriser pourrais-je trouver ?

Ethereal

t.

[kna]

Merci à vous deux
Je n'aurai pas le temps de creuser plus la question cet aprèm, je donnerai des news début semaine prochaine

[kna]

Salut Michaël

Si cela vous est possible, j'essayerais:
1- de mettre le serveur en question dans green et de voir s'il peut envoyer un mail

Une fois reconfiguré dans la plage d'IP green, ça fonctionne immédiatement.

2- de mettre un autre pc dans orange et de voir s'il peut envoyer un mail

Une fois reconfig en IP orange, mêmes problèmes, telnet port 25 vers le serveur mail green impossible.

La source du pb semble donc bien être IPCOP.

[kna]

Enfin, ajouter dans /etc/rc.d/rc.firewall.local toutes les règles d'acceptation green -> red et orange -> green. Pour ce dernier, par exemple pour accepter qu'un serveur en orange accède au serveur de temps:
/sbin/iptables -A INPUT -i eth1 -s 192.168.0.xx/32 -p udp --dport 123 -m state --state NEW -j ACCEPT

J'ai essayé d'ajouter ceci à /etc/rc.d/rc.firwall.local, entre les lignes "## add your 'start' rules here" et ";;" :
/sbin/iptables -A INPUT -i eth1 -s 192.168.0.2/32 -p tcp --dport 25 -m state --state NEW -j ACCEPT

eth1 désigne bien l'interface orange et 192.168.0.2 est l'IP du serveur que je veux faire sortir de orange vers green.

J'ai essayé de modifier un peu, en supprimant le /32 après 192.168.1.202, en ajoutant "-d 192.168.1.202" qui est l'IP du serveur mail en green, en ajoutant "-o etho" qui est l'interface green...

Essayé des "/etc/rc.d/rc.firewall restart" ou des "reboot" après les modifs..

Dans tous les cas, même chose, CA NE FONCTIONNE PAS.

J'ai été voir dans /var/ipcop/dmzholes/config, les lignes concernant les pinholes établis sous l'interface web d'IPCOP y sont bien..

Ayant lu un post sur un pb de routage qui ne fonctionnait plus après upgrade vers la 1.4.5, j'ai fait la manip de re-éditer les règles pinholes et valider, rien de mieux

Là, je ne sais plus quoi faire

[kna]

Si je fais un ping depuis le serveur orange vers 192.168.1.202 en green, je vois bien les icmp bloqués dans le journal du pare-feu

Si je fais un envoyer-recevoir du client mail depuis le serveur orange, rien dans le journal du pare-feu.
Et échec de connexion.

Je vais devenir chèvre !

[m2nis]

/sbin/iptables -A INPUT -i eth1 -s 192.168.0.2/32 -p tcp --dport 25 -m state --state NEW -j ACCEPT

Ca paraît bien...

J'ai essayé de modifier un peu, en supprimant le /32 après 192.168.1.202

On peut même supprimer "-s 192.168.0.2/32", mais ce n'est pas la peine d'ouvrir plus que nécessaire. Tout du moins quand ça marche...

en ajoutant "-o etho" qui est l'interface green...

eth0 (zero), je pense.

Essayé des "/etc/rc.d/rc.firewall restart" ou des "reboot"

Pas besoin de "reboot". "Restart" fonctionne très bien et... très vite.

Dans tous les cas, même chose, CA NE FONCTIONNE PAS.

N'y a-t-il plus aucunes traces de blocage dans le log du firewall???

Avez-vous essayé avec une autre machine? Ne serait-ce pas le fait d'appartenir à deux réseaux différents qui entraine le blocage??? Le ping passe-t-il correctement? Avez-vous essayé avec ssh (au demeurant plus conseillé que telnet)?

Je sèche un peu...

--
Michaël.

[m2nis]

Si je fais un ping depuis le serveur orange vers 192.168.1.202 en green, je vois bien les icmp bloqués dans le journal du pare-feu

J'avais raté ça (ping du message précédent).

Autre idée: le serveur smtp de votre serveur de mail ne comporterait-il pas des restrictions (sur ip, sur réseau, ...)?