[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Dual firewall question (summary)
From:       Dennis Dai <ddai () telgate ! com>
Date:       2001-02-28 1:02:47
[Download RAW message or body]

Here's the summary of the discussion:

Problem:

If you want to add a redundant link to the Internet from another ISP for
your web server (or whatever service you provide), and if you don't have
the budget to go with BGP peering or dedicated hardware, you can setup 2
firewalls each connecting to different ISP.

The problem is that the web server can have only 1 default gateway
(well, with the lowest metrics). So when client request comes in, the
web server has no way of knowing through which link the request is
coming in. Thus it will just send the reply packet to the default
gateway which is one of your firewall. Obviously, this is not the
desired result.

Solution:

As pointed out by Ben and mouss, you can use another NAT box to rewrite
the client's source IP so the web server knows where it comes from. Or,
use an ALG (or reverse proxy, whatever you call it) so that the
connection is coming from the firewall. These 2 solutions are actually
the same.

The problem I was having is I'd like to combine the firewall and NAT box
but I don't know how to do it. mouss kindly pointed out that I can use 2
nat rules that I didn't think possible:

> Use 2 different rules: a map and an rdr.
> - an rdr on the external interface to redirect traffic to the server
> - a map on the internal interface to convert clients addresses.

So in my ipnat.rules, I'd write:

rdr on <FW's external interface> from any/0 to x.x.x.x/32 port = 80 ->
y.y.y.y/32 port 80
map on <FW's internal interface> from any/0 to y.y.y.y/32 -> <FW's
internal IP>/32

The rdr rule will be applied when the packet goes through the FW's
external interface, the map rule will be applied when the packet goes
through the FW's internal interface. Note the from-to syntax in map only
appears in ipfilter 3.4.x series.

So from web server's point of view, each connection is coming from each
FW's internal IP address, so it knows where to send the response back.

And viola, you got your poor mans link redundancy!

Well, not quite. You'll have to do some work in your DNS (Ben pointed
this out to me off list). Because if one ISP's link is down, half (well,
let's say part, depending on how you setup round-robin) of the
connection will be broken. In that case, you'll have to use a fairly low
value of TTL for your web server in your DNS and modify the web server's
A (or CNAME?) RR on the fly when one link is down.


Cheers,
Dennis

[prev in list] [next in list] [prev in thread] [next in thread]