From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Wells Subject: Re: NAT problem when coming from private network Date: Wed, 27 Apr 2005 13:59:37 -0700 Message-ID: <426FFD39.3020001@gotvoice.com> References: <49795.72.11.67.10.1114115075.squirrel@72.11.67.10> <4268779A.70401@riverviewtech.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4268779A.70401@riverviewtech.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Taylor Grant Cc: netfilter@lists.netfilter.org 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. . . . > -- "There are 10 types of people in the world... those who understand binary and those who don't." That's only 2 types of people, kow. STUPID