>As this review clearly states:
> We decided to focus our evaluation on performance rather than
>I think the whole idea of having a secure firewall is that it's supposed
>to be secure and how fast it performs is not the most essential criteria.
I wish I had the *luxury* of taking that approach. The fact is that we
(or at least those in the commercial world) do not. If a firewall does
not perform adequately for the users/owners, it (and often the person
responsible) gets replaced.
As a consequence I always take the view that "Good Enough" (C) performance
is one of the requirements of any firewall. Now since a firewall does not
need to be a single platform ("that collection of devices..."), I make tests
based on expected load and am not loath to put multiple devices in serial/
parallel configurations and divide the load by port or subnets - nothing
ever said one size must fit all and TCP/IP communications fits easily
into such divisions. If WWW is a bottleneck, then I may install one or more
"devices" that respond to port 80 only. This reduces the sizes of the ACLs
in each machine.
Fact is that a collection of firewall devices can be much more flexible and
purpose driven than the manufacturers provide as a default. As I have
mentioned before, a Multiple Array of Inexpensive Devices can always
outperform individual machines yet can be configured to appear as a single
machine to the network (of course you need a few obsolete PCs on the inside
running feedthroughs and connected to the console port for maintenance). Add in
one last machine that does nothing but log ports that are not connected and
you have an effective solution without too much work.
In fact you can really sow confusion by having a setup that responds to
E-Mail as an NT device and WWW as a Unix box - different machines, same
address (just one ICMP responder though) - is really amazing what can be
done with a separate subnet and some address translation.
Something to think about while digesting 8*),