NAT problem when coming from private network
mwells at gotvoice.com
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.
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 22.214.171.124 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
>> 126.96.36.199 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
>> 188.8.131.52 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 (184.108.40.206) 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 220.127.116.11
>> -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 18.104.22.168 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
>> to selected ports from the net to machines on the inside. Like our mail
> 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 22.214.171.124 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 126.96.36.199, 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
> /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.
More information about the netfilter