Linux netfilter/iptables firewall : impacts on performances ?

I am looking for results of performance studies on the impact of the use
of the Linux netfilter/iptables firewall, typicaly a comparison of
bandwidth and delay time with and without the firewall for several types
of traffic (HTTP, FTP, UDP, etc.).
For the moment, I only need a local firewall on a Linux box (Mandrake
9.2) with only one network interface (FastEthernet).

Thanks.

On Thu, 29 Apr 2004 10:35:55 +0200, Philippe wrote:
> I am looking for results of performance studies on the impact of the use
> of the Linux netfilter/iptables firewall, typicaly a comparison of
> bandwidth and delay time with and without the firewall for several types
> of traffic (HTTP, FTP, UDP, etc.).
> For the moment, I only need a local firewall on a Linux box (Mandrake
> 9.2) with only one network interface (FastEthernet).

Hmmm, seems that would depend on your rules. What are you going to do,
run without the firewall. Why not pick something like
http://www.toast.net/performance/
run a test
clear browser cache
disable firewall
run same test again.
clear browser cache
enable firewall
run same test again.

My guess is network latency will washout the firewall delay.

Philippe <philou-666@caramail.com> wrote in message news:<c6qera$2n5$1@s1.read.news.oleane.net>...
> I am looking for results of performance studies on the impact of the use
> of the Linux netfilter/iptables firewall, typicaly a comparison of
> bandwidth and delay time with and without the firewall for several types
> of traffic (HTTP, FTP, UDP, etc.).
> For the moment, I only need a local firewall on a Linux box (Mandrake
> 9.2) with only one network interface (FastEthernet).
>
> Thanks.

Suspect you won't find any "types of traffic" studies that would be
meaningful for _your_ setup -- fact is, that's one of the reasons you
won't find many (any?) useful benchmarks re: iptables. There are just
_too_many_ variables. Connection rate, MASQing, number of nics,
traffic patterns, which additional modules are running and how, etc.

The other reason you may have difficulty finding any good studies is
that such things are usually only meaningful in comparison to -- what?
Not using _any_ firewall -- not!

A dedicated box, like a Cisco, will always show better _numbers_
because of its additional processors and trimmed down OS
functionality. But, afaik, all packet/acl filtering takes place in OS
space, not asics attached to ports. And you must distinguish
throughput numbers from latency issues with and without a firewall.

You can try some variations on the following string at Google:
netfilter iptables latency benchmark
Sorry I didn't find any ready made benchmark results at first glance
of ~ 50.

Iptables with a reasonable rule chain and no dynamic editing
(insertions, eg.) of the rules will perform quite well -- that's why
you find Linux/netfilter in commercial firewall boxes.

With luck, maybe you can find some diy tools that will suffice to test
_your_ setup.

hth,
prg
email above disabled

rdgentry1@cablelynx.com (P Gentry) said:
>Philippe <philou-666@caramail.com> wrote in message
>news:<c6qera$2n5$1@s1.read.news.oleane.net>...
>> I am looking for results of performance studies on the impact of the use
>> of the Linux netfilter/iptables firewall, typicaly a comparison of
>> bandwidth and delay time with and without the firewall for several types
>> of traffic (HTTP, FTP, UDP, etc.).
>
>Suspect you won't find any "types of traffic" studies that would be
>meaningful for _your_ setup -- fact is, that's one of the reasons you
>won't find many (any?) useful benchmarks re: iptables. There are just
>_too_many_ variables. Connection rate, MASQing, number of nics,
>traffic patterns, which additional modules are running and how, etc.

I recall having a discussion in the news with someone who initially
complained about huge slowdowns with iptables. What solved the problem
was to rearrange the rulesets -- there was rather huge number of rules,
and the most frequently used ones were close to the tail of the rulesets.

Luckily, iptables maintains packet counters to show which rules match
the majority of the traffic -- and it's also possible to branch the
rulesets to reduce the average/maximum ruleset lengths.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)