NAT problem when coming from private network

NAT problem when coming from private network

[Mark Wells]

 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?

I tried something like this(and a few variations) to no avail:
/usr/sbin/iptables -t nat -A PREROUTING -i $INTERNAL -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 $INTERNAL -d 192.168.1.0/24 -j ACCEPT

I also tried commenting out these lines:
/usr/sbin/iptables -A FORWARD -i $EXTERNAL -s 192.168.0.0/16 -j DROP
/usr/sbin/iptables -A INPUT -i $EXTERNAL -s 192.168.0.0/16 -j DROP

Which are the standard lines for blocking packets with spoofed private
network addresses that might show up from the net.

I only did that as a test to see if that was where the packets were
getting hung up(being well aware of the potential security issues
associated with not having these in place). No dice.  I can attach my
complete script if it would help, but it's pretty standard stuff for
masquerading from our private network out, and doing NAT to bring traffic
to selected ports from the net to machines on the inside. Like our mail
server.

Of course I can go directly to the mail server by going  to 192.168.1.8
and that works just fine, but that's beside the point.

The problem is, we have guys here with laptops, and they need to be able
to hit mail.gotvoice.com by name from both outside and inside. We got a
bunch of other services here that people get to by name as well.

We could just run a seperate DNS server internally to resolve the names to
private addresses, but we really don't want to get into running two
seperate DNS setups, when this should be a simple fix on the firewall.

Any ideas?

Appreciated as always,

Mark

Re: NAT problem when coming from private network

[Alistair Tonner]

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

Re: NAT problem when coming from private network

[Royce Kemp]

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

Re: NAT problem when coming from private network

[Taylor Grant]

> 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?

No, this is not possible because the client will think that it is talking to the firewall and is getting a response back from the mail server which it was not talking to (in the client's mind).



Grant. . . .

Re: NAT problem when coming from private network

[Jason Opperisano]

On Thu, Apr 21, 2005 at 07:35:33PM -0700, Royce Kemp wrote:
> 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?

just as people refuse to search the ML archives, i refuse to re-type
this email for the 50th time.  speaking of #50--here it is:

  http://marc.theaimsgroup.com/?l=netfilter&m=110571844432115&w=2

-j

--
"Stewie: OK, Harold, what do you think of our Mad Lib
 Stewie: "Cinderella had two step-'watermelons', who were very 'smelly'
 to her. So her fair god'toilet' turned her pumpkin into a big 'fanny',
 and dragged her off to the 'poop'.
 Stewie: Oh, how ruthlessly absurd."
        --Family Guy

Re: NAT problem when coming from private network

[Taylor Grant]

> Pretty standard stuff.

Yes what you are doing could be considered standard and not complex.  Thus there are some gremlins at work in this situation.

> 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?

I'm not 100% sure, but I think the problem lies in the fact that when your traffic comes in your $INTERNAL (eth1) LAN interface and FORWARD and SNAT out to loop back in to your $EXTERNAL (eth0) interface your traffic never really does go out the $EXTERNAL (eth0) interface b/c the external ip (72.11.67.10) is directly accessible on the router / firewall machine it's self and thus is not subject to the inbound DNATing that you are doing. It's sort of like being able to ping your own LAN IP even if you have the cable unplugged.  However I could be completely off base on this.  Any one have any follow up on this?

> I tried something like this(and a few variations) to no avail:
> /usr/sbin/iptables -t nat -A PREROUTING -i $INTERNAL -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 $INTERNAL -d 192.168.1.0/24 -j ACCEPT

You will actually want to use this rule to DNAT internal traffic destined to the external 72.11.67.10 IP address.  However there is more that needs to be done.  (See below)

> I also tried commenting out these lines:
> /usr/sbin/iptables -A FORWARD -i $EXTERNAL -s 192.168.0.0/16 -j DROP
> /usr/sbin/iptables -A INPUT -i $EXTERNAL -s 192.168.0.0/16 -j DROP

I think you can put these rules back in as I don't think the traffic is ever really going out the $EXTERNAL (eth0) interface and subsequenly back in and thus subject to said rules.

> Which are the standard lines for blocking packets with spoofed private
> network addresses that might show up from the net.

Yes they are and you do want to have such rules.  In fact the more that you do have and the more strengent that you can be the better.  See RFC 3330 if you want to be absolutely as tight as possible.

> I only did that as a test to see if that was where the packets were
> getting hung up(being well aware of the potential security issues
> associated with not having these in place). No dice.  I can attach my
> complete script if it would help, but it's pretty standard stuff for
> masquerading from our private network out, and doing NAT to bring traffic
> to selected ports from the net to machines on the inside. Like our mail
> server.

Ok, your logic is sound, keep it up.

> Of course I can go directly to the mail server by going  to 192.168.1.8
> and that works just fine, but that's beside the point.

I would hope so, if not there are other larger problems.  HEY!!! Who unplugged the power from my server???  ;)

> The problem is, we have guys here with laptops, and they need to be able
> to hit mail.gotvoice.com by name from both outside and inside. We got a
> bunch of other services here that people get to by name as well.

This make sense to me.  Even if you just said that you wanted to do it for the sake of doing it and saying that you did, that's enough reason to at least figure out how to make it work isn't it?

> We could just run a seperate DNS server internally to resolve the names to
> private addresses, but we really don't want to get into running two
> seperate DNS setups, when this should be a simple fix on the firewall.

You really don't want to go to all that trouble do you?  I did not think so.  (But if you did, you might want to look at views in Bind.  Ask me questions if you are curious.)

Yes this is a fairly simple fix on the firewall.  In fact you are almost all the way there.  You have two out of the three rules that you need.  The problem you ran in to when you DNATed the internal traffic distend to the 72.11.67.10 IP was that the Mail server responded directly back to the clients.  What's wrong with this setup is that the client systems are communicating with 72.11.67.10, not 192.168.1.8, which is who is responding to their traffic and thus dropping the traffic.

I think you need to add a rule to your nat table POSTROUTING chain that will SNAT any traffic leaving the router / firewall distend to the mail server on port 25 to appear to the mail server as if the traffic is coming from the router / firewall it's self.  This will make the mail server respond back to the router / firewall which will in turn unSNAT the traffic and subsequently unDNAT the traffic and send it back to the clients on the local LAN.  However this might mess up your mail server logs a little bit as it would see ALL traffic to it (save for the client systems that talk directly to it) appear as if it is coming from the router / firewall, even the external internet traffic.  If you do care about these logs / source IPs on most of your traffic you could set up the SNATing rule to only SNAT if the traffic is coming in from the internal LAN.  Thus you would add a rule like this:

/usr/sbin/iptables -t nat -A POSTROUTING -o $INTERNAL -s 192.168.0.0/16 -d 192.168.1.8 -p tcp --dport 25 -j SNAT --to-source $INTERNAL_IP_of_router
/usr/sbin/iptables -t filter -A FORWARD -i $INTERNAL -o $INTERNAL -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT

This rule will cause any traffic that is from 192.168.0.0/16 and destined to 192.168.1.8 be SNATed to the source IP of your router / firewall's internal LAN IP thus forcing the mail server to respond directly to the router / firewall which will respond back to the client.

Well that's how I understand your scenario any way.  I hope that will help you or at leas shed some light on your predicament.  If you need any thing else, just reply to the mail list or send me an email directly.  :)



Grant. . . .

Re: NAT problem when coming from private network

[Mark Wells]

 Hey Taylor and all,

 I just wanted to thank you for your help on this. I haven't had a 
chance to actually try your suggestion yet(I'm the lone admin for a 
growing startup), but I will get to it. For now, I did the dual DNS 
thing to limp by. Slightly lame I know, but being the only admin here I 
got a ton of stuff piled on my plate.

 I just wanted to let you guys know that it is greatly appreciated not 
only by me, but a friend of mine who has the same problem.

 I'll let you guys know how it worked(or come begging for more help ;)) 
when I get a chance to try it in a few days or whenever I can.

Thanks again!

Mark


Taylor Grant wrote:

>> Pretty standard stuff.
>
>
> Yes what you are doing could be considered standard and not complex.  
> Thus there are some gremlins at work in this situation.
>
>> 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?
>
>
> I'm not 100% sure, but I think the problem lies in the fact that when 
> your traffic comes in your $INTERNAL (eth1) LAN interface and FORWARD 
> and SNAT out to loop back in to your $EXTERNAL (eth0) interface your 
> traffic never really does go out the $EXTERNAL (eth0) interface b/c 
> the external ip (72.11.67.10) is directly accessible on the router / 
> firewall machine it's self and thus is not subject to the inbound 
> DNATing that you are doing. It's sort of like being able to ping your 
> own LAN IP even if you have the cable unplugged.  However I could be 
> completely off base on this.  Any one have any follow up on this?
>
>> I tried something like this(and a few variations) to no avail:
>> /usr/sbin/iptables -t nat -A PREROUTING -i $INTERNAL -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 $INTERNAL -d 192.168.1.0/24 
>> -j ACCEPT
>
>
> You will actually want to use this rule to DNAT internal traffic 
> destined to the external 72.11.67.10 IP address.  However there is 
> more that needs to be done.  (See below)
>
>> I also tried commenting out these lines:
>> /usr/sbin/iptables -A FORWARD -i $EXTERNAL -s 192.168.0.0/16 -j DROP
>> /usr/sbin/iptables -A INPUT -i $EXTERNAL -s 192.168.0.0/16 -j DROP
>
>
> I think you can put these rules back in as I don't think the traffic 
> is ever really going out the $EXTERNAL (eth0) interface and 
> subsequenly back in and thus subject to said rules.
>
>> Which are the standard lines for blocking packets with spoofed private
>> network addresses that might show up from the net.
>
>
> Yes they are and you do want to have such rules.  In fact the more 
> that you do have and the more strengent that you can be the better.  
> See RFC 3330 if you want to be absolutely as tight as possible.
>
>> I only did that as a test to see if that was where the packets were
>> getting hung up(being well aware of the potential security issues
>> associated with not having these in place). No dice.  I can attach my
>> complete script if it would help, but it's pretty standard stuff for
>> masquerading from our private network out, and doing NAT to bring 
>> traffic
>> to selected ports from the net to machines on the inside. Like our mail
>> server.
>
>
> Ok, your logic is sound, keep it up.
>
>> Of course I can go directly to the mail server by going  to 192.168.1.8
>> and that works just fine, but that's beside the point.
>
>
> I would hope so, if not there are other larger problems.  HEY!!! Who 
> unplugged the power from my server???  ;)
>
>> The problem is, we have guys here with laptops, and they need to be able
>> to hit mail.gotvoice.com by name from both outside and inside. We got a
>> bunch of other services here that people get to by name as well.
>
>
> This make sense to me.  Even if you just said that you wanted to do it 
> for the sake of doing it and saying that you did, that's enough reason 
> to at least figure out how to make it work isn't it?
>
>> We could just run a seperate DNS server internally to resolve the 
>> names to
>> private addresses, but we really don't want to get into running two
>> seperate DNS setups, when this should be a simple fix on the firewall.
>
>
> You really don't want to go to all that trouble do you?  I did not 
> think so.  (But if you did, you might want to look at views in Bind.  
> Ask me questions if you are curious.)
>
> Yes this is a fairly simple fix on the firewall.  In fact you are 
> almost all the way there.  You have two out of the three rules that 
> you need.  The problem you ran in to when you DNATed the internal 
> traffic distend to the 72.11.67.10 IP was that the Mail server 
> responded directly back to the clients.  What's wrong with this setup 
> is that the client systems are communicating with 72.11.67.10, not 
> 192.168.1.8, which is who is responding to their traffic and thus 
> dropping the traffic.
>
> I think you need to add a rule to your nat table POSTROUTING chain 
> that will SNAT any traffic leaving the router / firewall distend to 
> the mail server on port 25 to appear to the mail server as if the 
> traffic is coming from the router / firewall it's self.  This will 
> make the mail server respond back to the router / firewall which will 
> in turn unSNAT the traffic and subsequently unDNAT the traffic and 
> send it back to the clients on the local LAN.  However this might mess 
> up your mail server logs a little bit as it would see ALL traffic to 
> it (save for the client systems that talk directly to it) appear as if 
> it is coming from the router / firewall, even the external internet 
> traffic.  If you do care about these logs / source IPs on most of your 
> traffic you could set up the SNATing rule to only SNAT if the traffic 
> is coming in from the internal LAN.  Thus you would add a rule like this:
>
> /usr/sbin/iptables -t nat -A POSTROUTING -o $INTERNAL -s 
> 192.168.0.0/16 -d 192.168.1.8 -p tcp --dport 25 -j SNAT --to-source 
> $INTERNAL_IP_of_router
> /usr/sbin/iptables -t filter -A FORWARD -i $INTERNAL -o $INTERNAL -s 
> 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
>
> This rule will cause any traffic that is from 192.168.0.0/16 and 
> destined to 192.168.1.8 be SNATed to the source IP of your router / 
> firewall's internal LAN IP thus forcing the mail server to respond 
> directly to the router / firewall which will respond back to the client.
>
> Well that's how I understand your scenario any way.  I hope that will 
> help you or at leas shed some light on your predicament.  If you need 
> any thing else, just reply to the mail list or send me an email 
> directly.  :)
>
>
>
> Grant. . . .
>

-- 
<kow`> "There are 10 types of people in the world... those who understand binary and those who don't."
<SpaceRain> That's only 2 types of people, kow.
<SpaceRain> STUPID

Re: NAT problem when coming from private network

[Mark Wells]

Hey Taylor and all,

I just wanted to thank you for your help on this. I haven't had a chance 
to actually try your suggestion yet(I'm the lone admin for a growing 
startup), but I will get to it. For now, I did the dual DNS thing to 
limp by. Slightly lame I know, but being the only admin here I got a ton 
of stuff piled on my plate.

I just wanted to let you guys know that it is greatly appreciated not 
only by me, but a friend of mine who has the same problem.

I'll let you guys know how it worked(or come begging for more help ;)) 
when I get a chance to try it in a few days or whenever I can.

Thanks again!

Mark

>
>
>
> Taylor Grant wrote:
>
>>> Pretty standard stuff.
>>
>>
>>
>> Yes what you are doing could be considered standard and not complex.  
>> Thus there are some gremlins at work in this situation.
>>
>>> 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?
>>
>>
>>
>> I'm not 100% sure, but I think the problem lies in the fact that when 
>> your traffic comes in your $INTERNAL (eth1) LAN interface and FORWARD 
>> and SNAT out to loop back in to your $EXTERNAL (eth0) interface your 
>> traffic never really does go out the $EXTERNAL (eth0) interface b/c 
>> the external ip (72.11.67.10) is directly accessible on the router / 
>> firewall machine it's self and thus is not subject to the inbound 
>> DNATing that you are doing. It's sort of like being able to ping your 
>> own LAN IP even if you have the cable unplugged.  However I could be 
>> completely off base on this.  Any one have any follow up on this?
>>
>>> I tried something like this(and a few variations) to no avail:
>>> /usr/sbin/iptables -t nat -A PREROUTING -i $INTERNAL -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 $INTERNAL -d 192.168.1.0/24 
>>> -j ACCEPT
>>
>>
>>
>> You will actually want to use this rule to DNAT internal traffic 
>> destined to the external 72.11.67.10 IP address.  However there is 
>> more that needs to be done.  (See below)
>>
>>> I also tried commenting out these lines:
>>> /usr/sbin/iptables -A FORWARD -i $EXTERNAL -s 192.168.0.0/16 -j DROP
>>> /usr/sbin/iptables -A INPUT -i $EXTERNAL -s 192.168.0.0/16 -j DROP
>>
>>
>>
>> I think you can put these rules back in as I don't think the traffic 
>> is ever really going out the $EXTERNAL (eth0) interface and 
>> subsequenly back in and thus subject to said rules.
>>
>>> Which are the standard lines for blocking packets with spoofed private
>>> network addresses that might show up from the net.
>>
>>
>>
>> Yes they are and you do want to have such rules.  In fact the more 
>> that you do have and the more strengent that you can be the better.  
>> See RFC 3330 if you want to be absolutely as tight as possible.
>>
>>> I only did that as a test to see if that was where the packets were
>>> getting hung up(being well aware of the potential security issues
>>> associated with not having these in place). No dice.  I can attach my
>>> complete script if it would help, but it's pretty standard stuff for
>>> masquerading from our private network out, and doing NAT to bring 
>>> traffic
>>> to selected ports from the net to machines on the inside. Like our mail
>>> server.
>>
>>
>>
>> Ok, your logic is sound, keep it up.
>>
>>> Of course I can go directly to the mail server by going  to 192.168.1.8
>>> and that works just fine, but that's beside the point.
>>
>>
>>
>> I would hope so, if not there are other larger problems.  HEY!!! Who 
>> unplugged the power from my server???  ;)
>>
>>> The problem is, we have guys here with laptops, and they need to be 
>>> able
>>> to hit mail.gotvoice.com by name from both outside and inside. We got a
>>> bunch of other services here that people get to by name as well.
>>
>>
>>
>> This make sense to me.  Even if you just said that you wanted to do 
>> it for the sake of doing it and saying that you did, that's enough 
>> reason to at least figure out how to make it work isn't it?
>>
>>> We could just run a seperate DNS server internally to resolve the 
>>> names to
>>> private addresses, but we really don't want to get into running two
>>> seperate DNS setups, when this should be a simple fix on the firewall.
>>
>>
>>
>> You really don't want to go to all that trouble do you?  I did not 
>> think so.  (But if you did, you might want to look at views in Bind.  
>> Ask me questions if you are curious.)
>>
>> Yes this is a fairly simple fix on the firewall.  In fact you are 
>> almost all the way there.  You have two out of the three rules that 
>> you need.  The problem you ran in to when you DNATed the internal 
>> traffic distend to the 72.11.67.10 IP was that the Mail server 
>> responded directly back to the clients.  What's wrong with this setup 
>> is that the client systems are communicating with 72.11.67.10, not 
>> 192.168.1.8, which is who is responding to their traffic and thus 
>> dropping the traffic.
>>
>> I think you need to add a rule to your nat table POSTROUTING chain 
>> that will SNAT any traffic leaving the router / firewall distend to 
>> the mail server on port 25 to appear to the mail server as if the 
>> traffic is coming from the router / firewall it's self.  This will 
>> make the mail server respond back to the router / firewall which will 
>> in turn unSNAT the traffic and subsequently unDNAT the traffic and 
>> send it back to the clients on the local LAN.  However this might 
>> mess up your mail server logs a little bit as it would see ALL 
>> traffic to it (save for the client systems that talk directly to it) 
>> appear as if it is coming from the router / firewall, even the 
>> external internet traffic.  If you do care about these logs / source 
>> IPs on most of your traffic you could set up the SNATing rule to only 
>> SNAT if the traffic is coming in from the internal LAN.  Thus you 
>> would add a rule like this:
>>
>> /usr/sbin/iptables -t nat -A POSTROUTING -o $INTERNAL -s 
>> 192.168.0.0/16 -d 192.168.1.8 -p tcp --dport 25 -j SNAT --to-source 
>> $INTERNAL_IP_of_router
>> /usr/sbin/iptables -t filter -A FORWARD -i $INTERNAL -o $INTERNAL -s 
>> 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
>>
>> This rule will cause any traffic that is from 192.168.0.0/16 and 
>> destined to 192.168.1.8 be SNATed to the source IP of your router / 
>> firewall's internal LAN IP thus forcing the mail server to respond 
>> directly to the router / firewall which will respond back to the client.
>>
>> Well that's how I understand your scenario any way.  I hope that will 
>> help you or at leas shed some light on your predicament.  If you need 
>> any thing else, just reply to the mail list or send me an email 
>> directly.  :)
>>
>>
>>
>> Grant. . . .
>>
>

RE: NAT problem when coming from private network

[Gary W. Smith]

This is what we do...  Not sure if it's right but it works.

Eth0 is the external interface, 10.0.0.0/24 is the internal lan...

-A POSTROUTING -o eth0 -s 10.0.0.55 -j SNAT --to-source 22.33.44.55
-A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.55 -j SNAT --to-source
22.33.44.55

Otherwise machines on the local network just get all screwed up

If we do this then then other subnets get confused.
-A POSTROUTING -s 10.0.0.55 -j SNAT --to-source 22.33.44.55

Hope that helps.

Gary

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Royce Kemp
> Sent: Thursday, April 21, 2005 7:36 PM
> To: Alistair Tonner; netfilter@lists.netfilter.org
> Subject: Re: NAT problem when coming from private network
> 
> 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
> 
>