[Sussex] ipchains help please

[Mark Harrison]

> And I would be one of them.  In the a "true" DMZ you could have two (or
more)
> servers providing the same protocol (HTTP for example).  Both would be
visible
> from the Internet at large.  With a single IP address how would IPCop (or
any
> router) know which packets go to 10.0.0.1:80 and which go to 10.0.0.2.80?

This is where I poke my head above the parapet and admit to being an
infrastructure consultant.

I guess I'd better start by establishing my credentials. Before I went
freelance, I was first Systems Manager, then Head of Systems (pointy-haired)
for eKingfisher. eKingfisher is the web services division of Kingfisher
plc., and I was responsible for the web sites for Woolworths, Superdrug,
Comet, B&Q, Screwfix, MVC and Streets Online. In fact, one of the drivers
for going freelance was that I wanted to get back to being more of a techy
:-)

Now, I will concede that most of them, and most of my current clients, use
"big" firewalls, things like Checkpoint and PIX, rather than IPChains or any
of its packagings, but the principles are the same :-)

Let's start with a small bit of pedantry. The term for what we're actually
talking about is a "Secure Subnet". The term DMZ technically also applies to
anything BETWEEN the bastion firewall and the boundary router.

There are (at least) two ways for a firewall/proxy to be able to send some
packets to 10.0.0.1:80 and 10.0.0.2:80. Reverse Proxying and Port Address
Translation (PAT).

For the sake of what follows, let us imagine that the public IP address is
1.2.3.4

PAT converts a request to a known destination IP/port pair to another one.
Hence requests to 1.2.3.4:80 could be NAT/PATted to 10.0.0.1:80, but
requests to 1.2.3.4:8080 could be NAT/PATted to 10.0.0.2:80. The distinction
is therefore of ports.

The one monkey with this is that some (many) corporates have restrictive
firewall policies that only allow access on certain ports, such as 80 only.
This means if you want to connect to your home servers from work, you can
only access the one with a public port of 80.

Hence, Reverse Proxying comes in. In this, which is basically a special case
of virtual hosting, all incoming requests go to a single web server on the
secure subnet. The web server distinguishes between the two based on DNS
_name_ requested in the HTTP request.

For example, both www.ascentium.co.uk AND www.orchestras.org.uk could both
point to 1.2.3.4. Any request will go in on (http default) port 80. The
router/firewall will direct BOTH to, say, 10.0.0.3:80. 10.0.0.3 is a new
box, running any good web server, such as Apache. The Apache server sets up
reverseproxy directives that take the requests and pass them on.

This second technique requires an extra box to act as this reverse proxy (I
wouldn't recommend you do it on the firewall itself), but this box can be
cheap - a P90 with 32Mb RAM would have more than adequate grunt to reverse
proxy.

In the commercial web world it is regarded as best practice to have all
traffic directed to web heads that contain NO persistent content, simply
pass the appropriate requests on to an application server that will generate
the HTML required on the fly. In practice, the web heads tend to also cache
objects (particularly graphics) for performance. In, say, screwfix.com, the
graphics content is pulled through from an NFS server whenever the servers
boot, or once every 24 hours.

In the real world, webheads are also load-balanced, but that's another story
for another day :-)

Regards,

Mark Harrison