Re: [fw-wiz] Firewall rules order and performance

Pierre Blanchet wrote:
This is a well known idea that the rules order is important for the best
performance of a firewall. However, nowadays: 1. Stateful firewalls use their
stateful engine for existing connections to allow traffic. That means that
their performance is more related to the number of existing sessions rather
than the number of rules, or more exactly it is tied to the ratio
new/existing sessions. 2. Some firewalls no longer parse the configuration
line by line but use hardware-based or tree-based model. Again, the number
of rules has less effect on the performance.

I'm looking for benchmarks/ideas that could prove I'm right or wrong. I know
for sure that FW-1 and IOS depend on the rules order but what about the
others ? Google didn't give any information one way or the other.

Define "performance"...

For state keeping packet filters, the general rules (in my experience) are:

- New connections / s is generally limited by ruleset size and complexity. As I recall, several years ago Lucent had an O(1) algorithm for packet filtering on some of their high end routers (OC-12 +) that leveraged some tricky algebra, but it was (at the time) limited to 256 not very complex rules. I suspect some other folks may have figured out similar optimizations. A simple test is to insert 10,000+ dummy rules followed by a rule you'll actually hit. Test connection setup rate that way, and with your matching rule first. You'll quickly determine if there's anything "interesting" going on. Be sure to make the dummy rules annoyingly similar to the real one, but not quite the same (say, filter on TCP flags)

- Throughput tends to be limited by packet rate and # of existing sessions. This is why every vendor specifies throughput based on large packets - ask them for 64-byte packet throughput and watch them squirm.

- Throughput can also be limited by how much protocol parsing is done and how complex it is. If you just have to forward packets, you can do it faster than if you have to look for embedded port numbers in FTP, SIP, etc. Include NAT in the complexity calculation.

- The above variables can also effect _latency_ which can be more or less important that simple throughput, depending on your application.

Application proxies have similar performance correlations, but they're not as straightforward.


firewall-wizards mailing list

Relevant Pages

  • Re: [fw-wiz] Evaluating Firewall
    ... If any state is being kept, only the initial packet / connection traverses ... TCP has more state setup work than UDP, ... Most firewalls have to do a connection lookup for established sessions. ... Do existing connections or old ...
  • Re: How does outpost compair to ZAP?
    ... | There are two diffrent kinds of outgoing protection. ... | scans incoming and outgoing packets or connections for attacks and blocks ... Couple these IDS features with a packet filtering engine and you've ... Indeed, all software firewalls are ...
  • Re: [fw-wiz] Firewall performance testing (Was: Re: Evaluating Firewall)
    ... > This will illuminate the packet rate limitations, as well as the bit rate ... Test for 0% packet loss if you need ... Do existing connections or old ... Others will vary from <50% throughput to... ...
  • Re: Linux kernel on FreeBSD
    ... Is there something I'm missing with the firewalls ... Netfilter seems to have better nat proxy support for protocols like ftp ... If you setting incomming ftp connections to an ftp server ...
  • Re: handling hsrp connections from isp
    ... Because you only have unmanaged switches for your ISP and Firewall ... connections, that is definitely a single point of failure. ... pair of switches, which then go to the firewalls, which then go back ...