I'm dealing with some of this currently, also. I've gotten some issues
resolved ... and some not.
Where I have packet filters ... I do a hot-standby (tough issue is just
keeping their configs in sync, nice issue is that this provides a
'secondary' box to implement changes on and verify before hitting
the primary box). If I did something in parallel here (these are not
routers, but IP Filter boxes), I'd be stuck doing routing protocol
... and that doesn't make me fell all happy inside.
Where I have application level gateways, I do them in parallel -
so I can tolerate an outage. Also, go as far as you can - buy
hot-swappable things (RAID, etc ... money isnt' the biggest
problem of mine, so you mileage may vary).
It is not worth falling back to network-level filtering for my
company ... again, your policy - your choice. I just wouldn't
Biggest thing for me, since my support staff is a separate group
under a separate manager, is to DOCUMENT the procedures for
disaster recovery, fail-over, etc, etc. .... Don't leave them
standing around scratching their heads or calling you at 3am.
Big bonus here is, if you are hit by a truck then the company
can keep going forward.
From: uskanbye @
Sent: Wednesday, March 12, 1997 2:24 PM
To: firewalls @
Subject: Firewall and "single point of failure" issue
In an environment with a single network connection to the Internet guarded
by a firewall, what's the best strategy for providing fault-tolerance to
A few things we're looking at:
- aggressive service and response-time (< 2 hrs) requirements for firewall HW
- a "standby" preconfigured firewall HW box that we'd plug in if primary down
- in case of firewall failure, fall back on router packet filtering
without a firewall in place.
Comments? What are you doing?
--------KANSAS DEPARTMENT OF HEALTH & ENVIRONMENT---------
----------Mills Bldg Suite 501 Topeka, KS 66612-----------
---------Phone (913) 296-5643 FAX (913) 296-8943----------