NAT problem when coming from private network

Mark Wells mwells at
Wed Apr 27 22:59:37 CEST 2005

 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!


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 from my personal machine
>> which is on I get nothing. According to my reading of the
>> rule, any packets that come from the outside bound for port 25 on the
>> should be NATted to Which they are if they come
>> from the outside. Why shouldn't it work if packets try to hit port 25 on
>> 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 ( 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 
>> -p tcp
>> --destination-port 25 -j DNAT --to-destination
>> /usr/sbin/iptables -A FORWARD -p tcp -i $INTERNAL -d 
>> -j ACCEPT
> You will actually want to use this rule to DNAT internal traffic 
> destined to the external 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 -j DROP
>> /usr/sbin/iptables -A INPUT -i $EXTERNAL -s -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
>> 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 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 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, not 
>, 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 
> -d -p tcp --dport 25 -j SNAT --to-source 
> $INTERNAL_IP_of_router
> /usr/sbin/iptables -t filter -A FORWARD -i $INTERNAL -o $INTERNAL -s 
> -d -j ACCEPT
> This rule will cause any traffic that is from and 
> destined to 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

More information about the netfilter mailing list