This is a common problem which is explained in in Section 6.7 under "Note #2".
Basically, say your domain, acme.com, has an external IP address is 1.2.3.4 and you are PORTFWing all WWW traffic to an internal machine, say, 192.168.1.20. Then as an /internal/ user, you are trying to contact to http://www.acme.com and expect things to work. Well, that isn't correct. Basically, http://www.acme.com is being resolved to the IP of http://1.2.3.4. What you really should doing is contacting http://192.168.1.20.
See the difference?
The proper solution to this is to setup a SPLIT DNS server. Internal users would be configured to use the /internal/ DNS server which would reply with the 192.168.1.20 address when asked for www.acme.com. All external users will get a reply from the /external/ server resolving to the the 1.2.3.4 IP address. From there, IPTABLES/IPCHAINS/IPFWADM would then PORTFW the traffic to the 192.168.1.20 server like normal.
Another alternative if you only have a few internal machines is to setup a "hosts" file entry on all internal machines. That entry would basically look like:
www.acme.com 192.168.1.20 |
Got it? If you are interested in doing the more scalable DNS approach, TrinityOS completely covers split and chrooted DNS servers. TrinityOS - Section 24 http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos
Now, if the split DNS server or hosts file idea doesn't interest you, you can add the following line to your firewall ruleset. Please note that this section currently doesn't cover the use of REDIR. If you need help with REDIR, send me an email.
# $IPTABLES - this is the full path to where your copy
# of iptables is
#
# $PORTFW - this is the IP address of the internal WWW
# server
#
# $INTLAN - this is the network of your internal MASQed
# network. e.g. 192.168.1.0/24
#
# $INTIP - this is the internal IP address of the
# MASQ server
$IPTABLES -t nat -A POSTROUTING -d $PORTFW -s $INTLAN \
-p tcp --dport 80 -j SNAT --to $INTIP |
The problem with this approach is that every packet will be going from the MASQed web client, to the MASQ server, to the MASQed WWW server, and back again. This is very wasteful on both network bandwidth and server CPU!