NAT/por forwarding question

[Jeronimo Pellegrini <jeronimo@opus-software.com.br>]

Hello.

We have set up a potato box as a firewall here using kernel 2.4
and iptables; this box does NAT and port-forwarding, and there's
only one thing we didn't manage to do:

We want to redirect incoming SMTP to one internal host (the mailserver).
This worked fine, but only connections from outside do reach that host.
Connections from the internal network (from the 10.10.10.x IPs)
don't seem to work.

This is the rule:

    $IPTABLES -t nat -A PREROUTING -d $HOSTIP -p tcp --dport 25 \ 
              -j DNAT --to $MAIL_SERVER

So, trying to telnet on port 25 from the outside (on eth0) works.
The connection is redirected as it should be.

But, when telnetting from inside (say, from 10.10.10.103, connected to
the firewall's eth1), this is what happens:

$ telnet xxx.xxx.xxx.xxx 25
Trying xxx.xxx.xxx.xxx...

And it stalls.

iptables -L -t nat -v -n shows that the connection was actually redirected:

Chain PREROUTING (policy ACCEPT 118004 packets, 15699833 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1   120 DNAT       tcp  --  *      *       0.0.0.0/0            xxx.xxx.xxx.xxx
         tcp dpt:25 to:10.10.10.107:25 
     
(Line broken for readability)

Now... If I try the internal IP:

$ telnet  10.10.10.107 25
Trying 10.10.10.107...
Connected to 10.10.10.107.
Escape character is '^]'.
220 mailserver ESMTP Exim 3.12 #1 Thu, 12 Apr 2001 22:37:13 -0300

It works!

So... What could we be doing wrong? There's no firewall on the mail server 
whatsoever, so I suppose the problem is with the iptables rules in the
NAT box... I know we may have done something silly.

This is all we have on our PREROUTING chain, besides a similar rule for
http traffic and others for ports above 5000.


The iptables documentation mentions that one could use the OUTPUT chain for
locally generated packets, but I understand that "locally" means "generated
in the NAT box", not "coming from the internal network". Anyway, we tried
that also, and it didn't work.

Thanks a lot,
J.

-- 
Jeronimo Pellegrini
jeronimo@opus-software.com.br