Re: distributed natd

From: Krzysztof Zaraska (
Date: 08/10/01

Date: Fri, 10 Aug 2001 12:54:24 +0200 (CEST)
From: Krzysztof Zaraska <>
To: Tony Landells <>

On Fri, 10 Aug 2001, Tony Landells wrote:

> The idea is to run two (or more) firewalls in parallel in such a way
> that if one failed the other one would pick up the slack without users
> noticing.
Seems interesting.
First, I'd recommend taking at look at IPFILTER. Its nat implementation
has few interesting concepts, including restricting outgoing port range
and viewing state table. There were however some lincensing problems with
this code recently, IIRC.

> Obviously, this wouldn't work terribly well with stateful packet
> filtering...
Could work. I don't see much difference between updating nat dynamic rules
and filtering dynamic rules.

> I haven't even begun to look at the code for natd, but can anyone
> see any fatal flaws in the concept?
So I guess that you want to make your firewalls to exchange information
about changes in state tables, right?

In my opinion both firewalls should communicate over a secure link to
avoid fooling them by someone. Theoretically you could use SSL connections
but I guess it would consume too much computing power. I would make them
communicate over a separate cable (i.e. a small Ethernet connecting only

Next, I don't know whether they should communicate over TCP or UDP. I
would use UDP since it might be faster and it allows broadcasts (one
firewall broadcasting changes to all others on the secure network) but is
unreliable. A persistent TCP connection may be also considered.

Next, I don't know if it is necessary to hack the firewall code. You could
probably escape (at least with slow link and fast machines) with an
userland daemon watching / updating state table an communicating over
secure network.

It is however not clean to me how and how often you want to check if
firewall is alive.

Also it needs to be considered what happens in case one of the firewalls
is compromised. I guess this implies compromise of all firewalling

To Unsubscribe: send mail to
with "unsubscribe freebsd-security" in the body of the message