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