Re: [fw-wiz] Firewall Sizing?

Darden, Patrick S. wrote:

This is an incredibly complex question, that I don't think has an easy answer. Major factors (in *generally* desdending order of importance):

1. # concurrent sessions (this is more and more important the more your firewall does: layer 3, stateful, packet inspection, app proxy, anti-malware, vpn endpoints, ssl endpoints, etc.)
2. bandwidth.
3. # rules.
4. complexity of rules.
5. depth of the firewall--e.g. is it just layer 3 or is it doing application proxying as well? Does it also scan for malware? Even if it is only layer 3 is it stateful, is it doing packet inspection, is it doing protocol sanity checking?
6. is it doing encryption, e.g. a VPN endpoint. 3DES takes a lot more cpu than AES. etc.
7. you should match the hardware it is running on to the depth of the firewall; e.g. if you are doing app proxying, virus checking, and stateful packet inspection, then you should have multiple CPUs. If your rule base is large and stateful, and/or you are using several services such as VPN and app proxy, then you will need more RAM. Etc.
8. is it doing a lot of routing as well?
9. Is the hardware dedicated/accelerated in any way--e.g. using ASICS for ROSM, thus making extensive routing less of an issue (e.g. for a WAN firewall with hundreds of networks attached).

My best advice to you is to get a unit and test it in a lab under worst case conditions (take what you have and double it--# connections, # rules, etc.). In lieu of that--over-purchase. You don't want to do a major upgrade and then have to do it again due to performance issues.

[ Belatedly responding - greetings from Florence! ]

I generally agree with the above. However there are 2 other things to worry about:

- Packet rate. Usually _far_ more important than bit rate ("bandwidth" above). May be influenced by:
- Ruleset size / complexity
- # of current sessions
- Protocol logic complexity
- Packet rewriting (NAT etc.)

- Connection establishment rate. Especially important for HTTP servers.

Having presided over a large firewall RFP for a Fortune 50 financial, I can tell you that almost no vendors will disclose the numbers needed to make a sane sizing decision (64-byte packet forwarding rate, anyone?). The only way to be sure is to spend too much money (over-purchase) or test it with your workload in-house. Or negotiate a full credit for an upgrade with your vendor, in the event that you purchase a unit that is too small for your needs (this is not at all uncommon, and is a good idea in any case).

firewall-wizards mailing list

Relevant Pages

  • Re: ISA Server or Firewall Appliance?
    ... misconfigured appliance firewalls. ... I'm not convinced 'the vast majority of that complexity doesn't exist' ... you have folks that understand that firewall you can make such blanket ... In this case, that implication is very true, as both ISA ...
  • Re: New?? firewall idea, self-learning?
    ... put parts of the firewall in the kernel. ... No, it _Decreases_ complexity.. ... those command-line nerds that thinks GUIs are evil. ... "Anything worth having is worth fighting for" ...
  • Re: SELinux
    ... to be no system security will often mean the other systems adapt ... variety of inputs permissible and thus the complexity. ... The firewall case is a good one. ...
  • Re: Dont use a Firewall other than Windows Firewall?
    ... "Sam" wrote in message ... > Windows Firewall, and of course an antivirus scanner? ... I don't believe in increasing complexity without good reason. ... This makes it easier for me to secure it. ...
  • Re: ISA Server or Firewall Appliance?
    ... ISA is a very flexible piece of software, ... Complexity is not ... in regards to an internal firewall). ... internal network is NOT a good idea, ...