[Résolu] Problème de dns je pense

Bonjour,

Après iptables, j’ai bien réfléchi et j’ai collé le serveur de mail sur mon deuxième serveur comme apache. Du coup ma passerelle n’a plus de service, tout est forwarder sur mon deuxième serveur.

Donc dans iptables je colle mes règles pour le routage.
je configure apache, tous le tralàlà, je peut envoyé des mails, en recevoir, je test mon nom de domaine, il ne répond pas. Firefox met environ 5 bonnes minutes avant de me mettre un message d’erreur, disant que le serveur met trop de temps à répondre.

Le serveur ftp c’est pareil. Ssh, sa fonctionne. J’utilise le dynhosts chez ovh. Mon script de mise à jour fait une mise à jour de mon ip à ovh tout les 10 minutes pour l’instant (crontab), je le mettrais une fois que l’interface externe ce reconnectera (à regarder).

En faisant un ping sur mon nom de domaine, j’arrive bien à mon adresse ip. Ce qui est normal, vu ques les mails et le ssh fonctionne.

Donc,
les port 80, 443 ne répond pas
le port 21 ne répond pas
les ports 25 110 143 réponde
le port 22 répond

Sur ma passerelle j’ai mis un serveur dns de cache. Je ne sais pas si sa y joue…
Il a ce lien http://forum.debian-fr.org/viewtopic.php?t=2450 qui est récent, et c’est e gros la même merdouille.

Donc là… je n’y comprend plus rien. Visiblement c’est un problème de résolution de nom… Non?

Non, c’est normal, je penses que tu as routé le port 80 vers ton serveur: regardes ce que cela donne

A=serveur
B=extérieur
C=passerelle (adresse extérieure)
D=intérieur

Quand B se connecte à ton serveur, B voit C:80 comme adresse

B connecte C:80 qui renvoit à A:80 qui voit une requête arriver de B, il y répond et le paquet de retour est envoyé via C qui le «NAT» et l’envoie à B. Le NAT fait que le paquet de retour semble bien venir de C:80 donc tout va bien.

D se connecte à C:80, celui ci renvoie à A:80 qui voit une requête venir de D, il répond donc directement à D. D voit venir un paquet venant de A:80 alors qu’il attend un paquet de C:80, il le laisse passer…

Il faut donc faire du masquerading sur les paquets venant de ton réseau local et s’adressant au port 80:
Exemple:

eth0 = Ethernet intérieur
eth1 = ethernet extérieur

forward intérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth0 -d IP_ext_de_C --to 192.168.1.IP_de_C:80

forward extérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth1 --to 192.168.1.IP_de_C:80

NAT des requêtes intérieures

iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 80 -s 192.168.1.0/24 -j MASQUERADE

Le pbm est indentique pour le port 110, etc bref tous les serveurs délocalisés.

Sa ne fonctionne pas! Sa reste pareil

[code]

forward intérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth2 -d 213.36.26.116 --to 192.168.77.1:80

forward extérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i ppp0 --to 192.168.77.1:80

NAT des requêtes intérieures

iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 80 -s 192.168.77.0/24 -j MASQUERADE[/code]

Et la regle que j’avais avant:

Sachant que:

Interface externe: ppp0
Interface ou ce trouve le serveur: eth2
Adresse ip de la passerelle: 192.168.77.1
Adresse ip ou ce trouve le serveur: 192.168.77.2


J’ai une ip dynamique jusqu’en début mai, je ne me vois pas changer l’adresse ip toutes les 24h!

qu’as tu voulu faire avec ton “forward interieur” ? la règle me parait inutile.
ensuite 2e ligne pourquoi rediriger les accés web sur l’interface interne de ton routeur ? ta régle d’avant, sur le .2, etait correcte:
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to-destination 192.168.77.2:80
(tu fais ensuite la même chose avec les autres ports que tu veux envoyer vers ton serveur interne)

ensuite, le MASQUERADING ne se fait pas sur ce qui sort de ton routeur vers le LAN (eth2), mais vers le NET (ppp0), et pour tous les ports, pas seulement le port 80:
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.77.0/24 -j MASQUERADE

Oui! Ben c’est ce que j’avais avant! J’ai pas tout à fait tout compris ce que frand.b m’a dit, j’ai trouvé des trucs qui me semblais pas logiques, mais ayant du mal avec iptables…

J’ai bien:

iptables -t nat -A POSTROUTING -s 192.168.77.0/24 -o ppp0 -j MASQUERADE 

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 22 -j DNAT --to-destination 192.168.77.2:22
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 25 -j DNAT --to-destination 192.168.77.2:25
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to-destination 192.168.77.2:80
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 443 -j DNAT --to-destination 192.168.77.2:443
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 110 -j DNAT --to-destination 192.168.77.2:110
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 143 -j DNAT --to-destination 192.168.77.2:143
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 993 -j DNAT --to-destination 192.168.77.2:993
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 995 -j DNAT --to-destination 192.168.77.2:995
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 21 -j DNAT --to-destination 192.168.77.2:21
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 20 -j DNAT --to-destination 192.168.77.2:20

Avec les règles comme ceci, j’ai bien accès au ssh via l’extérieur, et au serveur de mail. Je n’ai pas accès au serveur ftp et à apache. Je tape mon nom de domaine sous firefox sur le desktop 192.168.77.3 et firefox tourne en rond. Je ping mon domaine, j’ai bien mon adresse ip. Je tape mon adresse ip sous firefox, j’ai le même problème qu’avec le nom de domaine.

C’est étrange, je ne comprend pas pourqoi le serveur de mail et ssh fonctionne et pas le reste.

Et ce que j’ai quand je regarde mes règles.

[code]Chain INPUT (policy DROP 46 packets, 7820 bytes)
pkts bytes target prot opt in out source destination
11 752 ACCEPT all – any any anywhere anywhere state RELATED,ESTABLISHED
1 60 ACCEPT all – lo any anywhere anywhere
0 0 ACCEPT icmp – any any anywhere anywhere
0 0 ACCEPT igmp – any any anywhere anywhere
0 0 ACCEPT all – any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:domain
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:domain
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:10000

Chain FORWARD (policy ACCEPT 8570 packets, 6172K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 16 packets, 3992 bytes)
pkts bytes target prot opt in out source destination
2 100 ACCEPT all – any lo anywhere anywhere
Chain PREROUTING (policy ACCEPT 118 packets, 12340 bytes)
pkts bytes target prot opt in out source destination
1 60 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:ssh to:192.168.77.2:22
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:smtp to:192.168.77.2:25
2 96 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:www to:192.168.77.2:80
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:https to:192.168.77.2:443
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:pop3 to:192.168.77.2:110
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:imap2 to:192.168.77.2:143
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:imaps to:192.168.77.2:993
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:pop3s to:192.168.77.2:995
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:ftp to:192.168.77.2:21
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:ftp-data to:192.168.77.2:20

Chain POSTROUTING (policy ACCEPT 53 packets, 5840 bytes)
pkts bytes target prot opt in out source destination
33 2176 MASQUERADE all – any ppp0 192.168.77.0/24 anywhere
[/code]

MattOTop:

Voilà les règles iptables que j’utilise pour que le serveur Web soit visible de l’extérieur et des 3 réseaux LAN internes:

IP est l’adresse IP extérieur, celle donnée par le DNS.

Web

extérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth1 --to 192.168.1.1:80

intérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth0 -d $IP --to 192.168.1.1:80
iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 80 -s 192.168.1.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 80 -s 192.168.2.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 80 -s 192.168.0.0/24 -j MASQUERADE

Précisions: la carte eth0 a 3 IP, 1 par réseau (question de sous)
Si j’enlève les 3 règles de masquerading sur le réseau interne, le serveur Web est invisible à partir des LAN pour la raion donnée dans mon message et vérifiée par ethereal.

J’ai fait de même pour les serveur POP décentralisé.

paflechien: fais attention à l’ordre des règles, c’est important.

forward intérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth2 -d 213.36.26.116 --to 192.168.77.1:80

forward extérieur

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i ppp0 --to 192.168.77.1:80

NAT des requêtes intérieures

iptables -t nat -A POSTROUTING -o eth2 -p tcp --dport 80 -s 192.168.77.0/24 -j MASQUERADE

A priori ça devrait être bon, as tu tracé les paquets via tcpdump.

Par contre dans la liste de tes règles, je ne vois pas la dernière…

Chain POSTROUTING (policy ACCEPT 53 packets, 5840 bytes)
pkts bytes target prot opt in out source destination
33 2176 MASQUERADE all – any ppp0 192.168.77.0/24 anywhere

Il n’y a que out ppp0…

Voilà ce que j’ai désormais:

[code]Chain INPUT (policy DROP 1 packets, 328 bytes)
pkts bytes target prot opt in out source destination
10 712 ACCEPT all – any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT all – lo any anywhere anywhere
0 0 ACCEPT icmp – any any anywhere anywhere
0 0 ACCEPT igmp – any any anywhere anywhere
0 0 ACCEPT all – any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:domain
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:domain
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:10000

Chain FORWARD (policy ACCEPT 12 packets, 1010 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 7 packets, 1040 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – any lo anywhere anywhere
Chain PREROUTING (policy ACCEPT 2 packets, 388 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp – eth2 any anywhere dyn-213-36-26-116.ppp.tiscali.fr tcp dpt:www to:192.168.77.1:80
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:www to:192.168.77.1:80
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:ssh to:192.168.77.2:22
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:smtp to:192.168.77.2:25
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:https to:192.168.77.2:443
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:pop3 to:192.168.77.2:110
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:imap2 to:192.168.77.2:143
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:imaps to:192.168.77.2:993
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:pop3s to:192.168.77.2:995
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:ftp to:192.168.77.2:21
0 0 DNAT tcp – ppp0 any anywhere anywhere tcp dpt:ftp-data to:192.168.77.2:20

Chain POSTROUTING (policy ACCEPT 1 packets, 328 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all – any ppp0 localnet/24 anywhere
1 60 MASQUERADE all – any ppp0 192.168.77.0/24 anywhere
0 0 MASQUERADE tcp – any eth2 192.168.77.0/24 anywhere tcp dpt:www
[/code]

Et toujours le même problème! Non je n’ai pas tracé les paquets avec tcpdump je ne connaissais pas. Alors, je l’ai installé sur mes deux serveur, et je l’ai sur mon desktop. Je ne sais pas sur lequel je dois lancé… et la commande doit etre tcpdump -i moninterface je suppose…

Ah une remarque peut être, j’ai supposé que toutes les machines étaient sur eth2, il faut peut être mettre

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth0 -d $IP --to 192.168.77.1:80

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -i eth1 -d $IP --to 192.168.77.1:80

Je regarderais plus attentivement tout à l’heure…

C’est simple, interne vient de ppp0, eth1 doit n’avoir que internet, et eth2, c’est le réseau pour chez moi. Et il y’a un serveur sous eth2, qui gère le ftp, le pop, imap, ssh, et le www.

Et si on me pose la question, ou est eth0? eth0 c’est une interface libre réserver au modem ethernet que j’attend. C’est comme sa, le système a préférer prendre eth2 lors de l’installation!

un petit up! :cry:

fran.b: ton masquerading sur le port 80 est spécifique a ton install et ne concerne pas paflechien, c’est parceque ton serveur web est sur ton routeur que tu en as besoin, mais tu ne fais pas de “masquerading” ip.
Par ailleurs, tu verrouilles avec des spécifications super serrées qui sont une bonne pratique quand ton routage paquets est au point, mais qui obscurcissent les explications que tu donnes: par exemple les -d $IP sont optionnels, mais tu ne l’expliques pas à paflechien, ce qui ne simplifient pas sa compréhension et l’oblige à utiliser tes conseils comme des recettes.
Par ailleurs, dans les règles que tu donnes, la restriction de ton masquerading au port 80 ne concerne que toi, et pas paf le chien qui peut souhaiter que ses clients interne accèdent au ftp ou au ssh.
Bon, je retourne regarder la suite pour voir ou en est arrivé paf.

[quote=“paflechien”]C’est simple, interne vient de ppp0, eth1 doit n’avoir que internet, et eth2, c’est le réseau pour chez moi. Et il y’a un serveur sous eth2, qui gère le ftp, le pop, imap, ssh, et le www.

Et si on me pose la question, ou est eth0? eth0 c’est une interface libre réserver au modem ethernet que j’attend. C’est comme sa, le système a préférer prendre eth2 lors de l’installation![/quote]

Astuce: si tu veux choisir l’ordre de tes interfaces, mets un "alias eth0 ", etc dans un des fichiers de /etc/modprobe.d

Bon, sinon, je ne peux pas, là maintenant, mais je te donnes un script iptables cet AM correspondant à cette description claire de ton pb.

Merci Matt, moi je nage là!

Non l’ordre de mes interfaces je m’en fou! :wink: Sa ne fais pas longtemps que je suis sous linux, mais merci du conseil, tout est bon à savoir :d

ppp0:

  • adresse attribuée par le FAI, sans doutes autour de 213.36.26.116 , je ne l’utiliserais donc pas.

tu as ensuite deux interfaces clientes

eth1:
à priori uniquement internet.
vraiment juste le web, interdiction du ftp, pas de ssh, de telnet, de relève de courrier ni rien ?
Bon, comme je n’avais pas vu cette contrainte avant, je dois faire un [size=200]ENORME MEA CULPA A FRAN.B[/size], car celà justifie qu’il limite le masquerading au port 80…
par contre il doit me manquer un post parceque je ne vois pas non plus l’adresse de cette interface.

eth2:
sur 192.168.77.1
appelons là DMZ, pour simplifier, qui a tous les droits, et dans lequel se trouve 192.168.77.2, qui écoute sur les ports ftp (tcp/20,tcp/21), pop (tcp+udp/110, supposé pop3 mais je te conseilles de passer en pop3s), imap (tcp+udp/220, supposé imap3, pareil pour imaps ), ssh (tcp+udp/22) et www (tcp+udp/80, et tcp+udp/443).

comme j’imagine que tu aura besoin d’accèder de l’exterieur à ton routeur en ssh, je vais donner accés à ton serveur www, plutot sur le port 22220 - les machines suivantes de ta DMZ seront accessible sur les ports 22221, 22222, etc - et comme ça, ton routeur restera accessible par le port 22.
Là, j’envoie déjà ça, c’est juste une description de la situation, mais j’ai eu un appel du boulot: pourquoi les machines cassent elles uniquement quand je ne suis pas là !

Oui, pour le moment ppp0 recois une addresse ip dynamique toutes les 24h.

Eth1 est le lan de mes parnets donc pas de service de ce coté, jsute internet, chose qu’ils ont!

Eth2, mon lan, internet, mais il y’a le serveur 192.168.77.2, et de la passerelle, j’ai routé les ports que je veut.

Mais comme expliqué, dès que je tape mon nom de domaine, je n’ai pas accès. Ping sur mon domaine, le ping me donne bien l’ip.

Oui l’accès ssh de l’extérieur j’en aurais besoin. Mais il fonctionne déjà! comme le serveur de mail.

Je me répère peut être, mais c’est tellement important pour moi! Je ne colle pas mon sujet en URGENCE!

Il n’y a pas de mal mat, le travail avant tou :wink:

[quote=“MattOTop”]fran.b: ton masquerading sur le port 80 est spécifique a ton install et ne concerne pas paflechien, c’est parceque ton serveur web est sur ton routeur que tu en as besoin, mais tu ne fais pas de “masquerading” ip.
Par ailleurs, tu verrouilles avec des spécifications super serrées qui sont une bonne pratique quand ton routage paquets est au point, mais qui obscurcissent les explications que tu donnes: par exemple les -d $IP sont optionnels, mais tu ne l’expliques pas à paflechien, ce qui ne simplifient pas sa compréhension et l’oblige à utiliser tes conseils comme des recettes.
Par ailleurs, dans les règles que tu donnes, la restriction de ton masquerading au port 80 ne concerne que toi, et pas paf le chien qui peut souhaiter que ses clients interne accèdent au ftp ou au ssh.
Bon, je retourne regarder la suite pour voir ou en est arrivé paf.[/quote]

Non mon serveur Web est sur 192.168.1.1, la passerelle routeur sur 192.168.1.2. IP est l’IP extérieure. Par ailleurs, ces lignes t’étaient destinées pour t’expliquer ce que je faisais:

Je répète:

Parsserelle en A
Serveur en B sur LAN
Machine C sur LAN
Machine D extérieur

toto.loin.fr pointe sur IP_ext de A

Quand D fait une requête sur toto.loin.fr:80
cette requête est transmise sans NAT à B, qui reçoit une requête de D et lui répond, La réponse de B transite par A qui la renvoit à D avec du masquerading. D reçoit un paquet semblant venir de A, machine qu’il a interrogé. Tout va bien.

Quand C fait une requête sur toto.loin.fr:80
cette requête est transmise sans NAT à B, qui reçoit une requête de C et lui répond, La réponse de B ne transite pas par A et va directement à C. C reçoit un paquet venant de B alors qu’il a interrogé A. Donc le paquet est ignoré.

Solution faire croire à B que la requête vient de A donc faire du masquerading sur les requêtes venant d’une machine du LAN pour le serveur C lorsqu’elles s’adressent à lui via l’adresse exterieure donc en passant par A.

Je me suis débattu pas mal de temps avant de piger ce problème, je l’ai elucidé avec tcpdump et je suis sûr de moi. Je pense réellement que c’est le pbm de paflechien: Les serveurs TCP qui ne sont pas hébergés par la passerelle semblent inaccessibles si on les interroge du LAN par l’IP extérieure. Peut être me suis je fait mal comprendre. En tout état de cause les règles citées plus haut sont celles que j’ai mises sur plusieurs machines en production pour des serveurs décentralisés et remplissent leur role:

  1. Une règle de forward de port destinnée aux paquets venant de l’extérieur
  2. Une règle de forward de port destinnée aux paquets venant de l’intérieur
  3. Une règle imposant le masquerading pour les paquets concernés par la règle 2 ci-dessus.

Voilà.

paflechien: Ai je bien compris le pbm, Web, mail, ftp fonctionne de l’extérieur mais pas de chez toi c’est ça? J’ai l’impression d’une incompréhension, pour moi ton pbm est d’accéder à tes services de tes machines, services qui marchent bien de l’extérieur. Est ce ça où bien est ce que ça ne marche pas du tout?

Dans ce dernier cas, pour apache, vérifie que tu ne lui as pas précisé une adresse IP spécifique dans le httpd.conf via Listen ou NameVirtualHost.

[houla, il y a eu du post pendant que je tapais mon truc moi, bon je relis le tout mais je vais me faire un café avant…]

J’ai regardé tes règles (cf ci dessous). Je ne comprends pas bien ton réseau, localnet n’est pas 192.168.77.0/24?

Je me demandes si ça n’est pas un problème de route.

Que donnes ifconfig et «route -n» s’il te plait.

[code]hain PREROUTING (policy ACCEPT 2 packets, 388 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp – eth2 any anywhere dyn-213-36-26-116.ppp.tiscali.fr tcp dpt:www to:192.168.77.1:80

Requête LAN vers passerelle:80 orienté vers 77.1:80: OK

0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:www to:192.168.77.1:80
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:ssh to:192.168.77.2:22
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:smtp to:192.168.77.2:25
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:https to:192.168.77.2:443
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:pop3 to:192.168.77.2:110
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:imap2 to:192.168.77.2:143
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:imaps to:192.168.77.2:993
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:pop3s to:192.168.77.2:995
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:ftp to:192.168.77.2:21
0     0 DNAT       tcp  --  ppp0   any     anywhere             anywhere            tcp dpt:ftp-data to:192.168.77.2:20

Requête de l’extérieur vers www,ssh, smtp, https, POP3, 143, 993, 995, ftp, ftp-data vers 77.1 ou 77.2 (le http et https ne sont pas sur la même machine): bon OK)

Chain POSTROUTING (policy ACCEPT 1 packets, 328 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all – any ppp0 localnet/24 anywhere

localnet --> extérieur NATé, mais le localnet n’est-il pas 192.168.77.0/24

1    60 MASQUERADE  all  --  any    ppp0    192.168.77.0/24      anywhere

LAN -> extérieur NATé: OK mais bizarre qu’est le localnet?

0     0 MASQUERADE  tcp  --  any    eth2    192.168.77.0/24      anywhere            tcp dpt:www

Masquerading des requête LAN vers www : OK
[/code]

Pour illustrer ce que je disais:
Si je fais sur 192.168.1.251

iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DN AT -d 82.66.248.156 --to 192.168.1.248:23

puis

tcpdump -n port 2222

Sur 192.168.1.249, je fais telnet 82.66.248.156 2222

le tcpdump donne

[code]
192.168.1.249.33222 > 82.66.248.156.2222: S 623215956:623215956(0)
192.168.1.249.33222 > 192.168.1.248.23: S 623215956:623215956(0)
192.168.1.249.33222 > 82.66.248.156.2222: S 623215956:623215956(0)
192.168.1.249.33222 > 192.168.1.248.23: S 623215956:623215956(0)
192.168.1.249.33222 > 82.66.248.156.2222: S 623215956:623215956(0)
192.168.1.249.33222 > 192.168.1.248.23: S 623215956:623215956(0)

tandis que un tcpdump sur la machine 192.168.1.248 donne

192.168.1.249.33225 > 192.168.1.248.23: S 743291845:743291845(0)
192.168.1.248.23 > 192.168.1.249.33225: S 1485094281:1485094281(0)
192.168.1.249.33225 > 192.168.1.248.23: R 743291846:743291846(0)
192.168.1.249.33225 > 192.168.1.248.23: S 743291845:743291845(0)
192.168.1.248.23 > 192.168.1.249.33225: S 1488090964:1488090964(0)
192.168.1.249.33225 > 192.168.1.248.23: R 743291846:743291846(0)

On voit qu’elle répond directement à 192.168.1.249. Ce dernier attend indéfiniment une réponse de 82.66.248.156.

Je rajoutes la règle

iptables -t nat -A POSTROUTING -p tcp --dport 23 -s 192.168.1.0/24 -j MASQUERADE

le tcpdump sur 192.168.1.251 donne

192.168.1.249.33232 > 82.66.248.156.2222: S 907045902:907045902(0)
192.168.1.251.33232 > 192.168.1.248.23: S 907045902:907045902(0)
192.168.1.248.23 > 192.168.1.251.33232: S 1644341582:1644341582(0)
192.168.1.249.33232: S 1644341582:1644341582(0) ack 907045903
192.168.1.249.33232 > 82.66.248.156.2222: . ack
192.168.1.251.33232 > 192.168.1.248.23: . ack
192.168.1.248.23 > 192.168.1.251.33232: P 1:4(3)
192.168.1.249.33232: P 1:4(3) ack 1
192.168.1.249.33232 > 82.66.248.156.2222: . ack
192.168.1.251.33232 > 192.168.1.248.23: . ack
....[longue suite]

le tcpdump sur 1192.168.1.248 donne

192.168.1.251.33235 > 192.168.1.248.23: S 966696350:966696350(0)
192.168.1.248.23 > 192.168.1.251.33235: S 1717887663:1717887663(0)
192.168.1.251.33235 > 192.168.1.248.23: . ack
192.168.1.248.23 > 192.168.1.251.33235: P 1:4(3)
192.168.1.251.33235 > 192.168.1.248.23: . ack
192.168.1.251.33235 > 192.168.1.248.23: P 1:4(3)
192.168.1.248.23 > 192.168.1.251.33235: . ack

On voit qu’il fait les réponses à la passerelle 192.168.1.251 qui déNATe les paquets et les renvoie à 192.168.1.249. Cette machine reçoit des paquets venant de 82.66.248.156 et la connexion s’établit.

Voilà, c’était juste pour illustrer ce que je voulais dire. Mais peut être que ça n’est pas ça ton pbm…