NAT problem when coming from private network

Royce Kemp rkemp at ip3.com
Fri Apr 22 04:35:33 CEST 2005


at first this is what I thought the solution would be, but Mark Wells said 
that his mail server is on the same subnet as the client machine 
(192.168.1.8 and 192.168.1.34)... so why can't the mail server communicate 
directly with the client machine? so packet go from client to firewall and 
are redirected to the mail server.. then the mail server will arp for 
192.168.1.34 and return packet directly to him). is this not possible?

-r


At 07:16 PM 4/21/2005, Alistair Tonner wrote:
>On April 21, 2005 04:24 pm, Mark Wells wrote:
> >  Apologies if this is an RTFM but I have searched and found nothing.
> >
> >  The problem:
> >
> > We're doing NAT (DNAT) on our firewall from a valid outside ip to a
> > machine on our private network which is handling mail. So the rule looks
> > like this:
> >
> > /usr/sbin/iptables -t nat -A PREROUTING -i $EXTERNAL -d 72.11.67.10 -p tcp
> > --destination-port 25 -j DNAT --to-destination 192.168.1.8:25
> >
> > /usr/sbin/iptables -A FORWARD -p tcp -i $EXTERNAL -d 192.168.1.8 --dport
> > 25 -j ACCEPT
> >
> > $EXTERNAL being eth1 our  "outside" interface.  There is also a $INTERNAL
> > which corresponds to eth0 - the interface on out private network.
> >
> > Pretty standard stuff.
> >
> > So NAT works great for incoming mail, and we have similar rules for POP3,
> > IMAP, etc. All works great from outside.
> >
> > The problem comes when we try to hit the mail server (by going to that
> > outside ip),  from a machine that's already on the private network. So for
> > example if I telnet to port 25 on 72.11.67.10 from my personal machine
> > which is on 192.168.1.34 I get nothing. According to my reading of the
> > rule, any packets that come from the outside bound for port 25 on the
> > 72.11.67.10 should be NATted to 192.168.1.8. Which they are if they come
> > from the outside. Why shouldn't it work if packets try to hit port 25 on
> > 72.11.67.10 from the private network then?
>
>         <Bulk snippage>
>
>
>         Basically your problem is this.  Works from outside.  Come inside 
> and the
>system contacts the firewall correctly, gets redirected to the correct inside
>server ****** and the inside server replies directly to the inside pc *******
>and said packet (reply) is not related to anything the inside pc is aware of.
>
>         Ta DAH!
>
>         Now -- to solve.
>
>         write a rule that takes the connections coming from inside ONLY 
> that are
>headed OUT of your firewall (on the way to the mailserver) and SNAT (Source
>Nats) them to the inside ip of the firewall ... this way the mailserver (or
>whatever else) replies back to firewall and firewall sends it to inside ip.
>
>(I'm NOT guarranteeing syntax here I'm TIRED)
>
>iptables -A POSTROUTING -t nat  -p tcp -s ${lan_ip_range} -d
>${lan_ip_of_mailserver} \ --dport ${mail} -j SNAT --to-source
>${lan_ip_of_firewall}
>
>
>         although it worked for me. -- FYI the reason for the -s filter 
> there is so
>that internet traffic connections ARE NOT SNATted on the way in -- thus when
>you only see connections from the firewall to the mail server in the logs you
>know it was someone on the inside of the lan ...
>
>         -- off to bed with me.
>
>         Alistair Tonner
> >
> > Appreciated as always,
> >
> > Mark





More information about the netfilter mailing list