Nix Bits

So you have just one IP address and a bunch of machines behind NAT.
You’ve got port redirection working so your interal webserver behind
the firewall is serving pages. But now you’ve got a second box that
you need to host content on. Perhaps you have need to have a separate
webserver running mod_perl and one running php. Or perhaps you’ve got
(God forbid) an IIS box. And you don’t want to redirect alternate
ports. Here’s away to have multiple webservers behind a single
external IP address all running on Port 80.

What you need is a reverse inbound proxy established on your firewall.
Apache with mod_proxy built and
enabled does the trick.

First and foremost you need to have your DNS sorted out. I have both
external and internal DNS servers. Bind 9 can do
this with “views” though I personally have a preference for setting up
djbdns. If you do not have
an internal DNS for your domains then you’ll need to reference your
internal boxes by IP address in your apache configuration (see below).

The next thing to do is fix your firewall. You need to install apache.
mod_proxy should come with it. You need to stop redirected port 80
inbound in your NAT (aka IP Masq) configuration since the firewall
will now answer on Port 80. Since I have internal DNS servers, I
also made sure my firewall’s /etc/resolv.conf pointed to the
internal DNS server.

Now you set up Apache on your firewall. Just do a basic configuration.
Here’s the magical lines snipped from httpd.conf

LoadModule proxy_module       libexec/apache/libproxy.so
AddModule mod_proxy.c

NameVirtualHost your.external.ip.address

<VirtualHost your.external.ip.address>
   ServerAdmin webmaster@yourwebsite.net
   ServerName www.yourwebsite.net
   ProxyPass / http://www.yourwebsite.net/
   ProxyPassReverse / http://www.yourwebsite.net/
   ErrorLog /var/log/apache/yourwebsite.net/error_log
   TransferLog /var/log/apache/yourwebsite.net/access_log
<VirtualHost>

Since the internal DNS server has a local (ie 192.168.x.x) address
for “www.yourwebsite.net”, requests to that NameVirtualHost go
to the appropriate internal box. And it need not be running
apache. Anything that speaks http will be transparently proxied.

If you don’t do internal DNS you’d replace
“http://www.yourwebsite.net” with something like “http://192.168.5.80″
where that is the IP of the internal server that you want to answer
for www.yourwebsite.net.

Note that you can also do SSL https connections this way. The key is
that you need to have your SSL certs and keyfiles on the firewall. The
firewall would then speak standard http on port 80 to the internal box
The config looks like this:

<VirtualHost your.external.ip.address:443>
   ServerAdmin webmaster@yourwebsite.net
   ServerName secure.yourwebsite.net
   ProxyPass / http://secure.yourwebsite.net/
   ProxyPassReverse / http://secure.yourwebsite.net/
   SSLEngine on
   SSLCertificateFile /path/to/certfile
   SSLCertificateKeyfile /ditto/for/keyfile.key
   ErrorLog /var/log/apache/secure.yourwebsite.net/error_log
   TransferLog /var/log/apache/secure.yourwebsite.net/access_log
</VirtualHost>

As you can see, it really helps to have internal DNS set up.
That makes things easier and allows you to have NameVirtualHosts
on your internal boxes. You could just to IP based VirtualHosts
internally configuring multiple 192.168.x.x IPs on your internal
servers.

I’m sure you can imagine some very useful ways of doing this.
It makes a test and development environment easy. You can stand up
a replacement website without going through the hastle of waiting for
public DNS to “catch up”.

Obviously there are security considerations. I won’t go into a major
discussion about that here except to say that you need to think about
it. For my needs, this increased my security posture because I could
move Win2000 machines with many potential vulnerabilities behind the
firewall and reduce exposure to just IIS and cross-site scripting
issues. That’s still plenty to worry about, but better than having,
say, MSSQL outside your firewall)

Another implication of this is that your logging of website
connections changes. All that your internal boxes will ever log now
are connections from the firewall. So those logs are useless for
tracking site traffic, etc. But all your hits are logged —
separately the way I configured it — on the firewall itself. Just make
sure you make those log subdirectories manually before restarting
apache because apache won’t create them. The master apache error log
will report this, of course.

References:
1

2
3