Re: NAT problem when coming from private network

[Mark Wells <mwells@gotvoice.com>]

 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