Re: FW-1 Failover

["Sean Costello" <xlate () home com>]

Kelvin wrote:

> I am thinking of using FW-1 for a internal Firewall which will segregate
> four networks of different security levels. The configuration is to be on
> NT, with four Ethernet cards.  The main problem I have is
> providing failover for the FW-1.
>
> I know FW-1 supports failover/load sharing, but will this work with four
> interfaces?

Yes...

I guess the first question here is are you planning to implement just
failover or ha.  I believe either is achievable.

FW-1 provides the ability for two or more pfm's  (let's say two for
simplicity) to synchronize their state tables.  This is accomplished through
constant updates passed between them through an isolated segment. The update
cycle by default is 50 milliseconds but could possibly be increased with the
right utilities and configuration info.

Both firewalls would have corresponding drops to each of the four segments.
By running the boxes in parallel using "state sync" you then implement
routing techniques to distributes the traffic over the two gateways.  In
this configuration ha is achieved like this...

Let's say you initiate a tcp connection and the initial traffic is sent over
pfm A.  The connection traverses the rulebase as normal and in this case the
connection is allowed to pass.  Once the three way handshake is complete the
session is added to the connections table with a default timeout value.

At this point pfm A also sends an update to pfm B over the isolated segment
so now it too is aware of this new established connection.

At this point even if the routing protocol suddenly decides that pfm B would
be a more cost effective route, the packets are still properly routed since
B shows this  conversation as a connection in progress.

This implementation would be best used with something like OSPF being a
stateful routing protocol reaching network convergence relatively quickly
(well opposed to something like RIP...).  Although since your using NT OSPF
would be available through RRAS but it currently isn't capable of load
distribution over equal costs.

You would have to find an arbitrary way to segment the traffic say by
service or source network address.  Although, an area I would causion you to
avoid, of which I've seen a number of implementations is setting up
asymetrical routing configurations.  The primary routes would be defined as
asymetrical and the secondary configured as symetrical routes only to be
used when either machine goes down.

As I said though, I personally wouldn't reccomend this since the update
cycle can be tweaked only so much and under load you may find that you
encounter a high number of dropped connections.  This is due to the fact
that a large number of successive updates between the two pfm's can create
congestion in the synchronization process.  This would lead to response
packets being dropped since the second pfm hasn't received the update.

Since this limit is arbitrary based on an impressive number of variables,
properly identifying the thresholds deemed appropriate would be extremely
difficult at best.

Now if you're refferring to an HA solution with FW-1...

The currently the accepted configuration for a failover solution is
implementing Stonbeat.  The state sync feature is also used here, but...
there is no requirement for dynamic routing capabilities.  The Stonebeat
software handles this aspect for you by manipulating and masking a shared IP
between the two machines on each segment.

In addition to seemless support for load distribution this type of
implementation is also far easier to introduce into an existing
infrastructure.  The added effort of learning and configuring the Stonebeat
software would most likely be far less effort than the routing scenerio
described above.

Both scenerio's though are not with out their merits...

Problem areas to watch out for in both are...

-No failover for (SR) encrypted clients...
-No failover for VPN's without initiating a key exchange...at least not one
I could or would suggest.
-I believe the issues found when the CA fails are resolved in ver 4.0
-A few others are described in the state sync docs which I don't remember
off hand

Hope this was what you were looking for...

Sean R Costello
Network Engineer
xlate () iname com