IPTables Feature set and performance.

IPTables Feature set and performance.

[ccmike]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


O wise netfilter guruz, I pray unto thee in hopes you can answer my most 
humble questions. 

I have been all over the net and looked thru the mailing list archives, but 
cannot find an answer to questions that have been asked a number of times, 
but never with the proper specifications, so I will attempt to ask in a more 
proper form.

First: netfilter vs pix

considering packet filtering only, and ignoring the "extra" things such as vpn 
and pretty gui, administration costs, purchase price, and CYA.

What things can I do with an iptables firewall that I cannot do with a pix 
firewall,  I know about log tagging, but what else?

If the "costs" are not an issue, and the cisco extras are not necessary, would 
you go with a pix or a netfilter solution and why? (skip the 'cause linux 
rulez answers).

It seems that every time that this question was asked in the past the answer 
was "pix comes with cisco CYA", or "what about the admin overhead", or 
"depends on your requirements".  I am interested (as I am sure others are) in 
the technical differences.  I am not trying to build a business case.  

Second: Performance

If I make a monolithic kernel with everything stripped out of it except for 
the code I need to run a netfilter firewall with stateful inspection, and I 
have only the basic ruleset (everything out, established+mail+web+ssh in, 
drop illegal ip addresses and flag combinations). basically a network noise 
filter. How many new connections per second can I expect to handle on what 
type of box?  What type of thruput should I expect on what type of box?

Please note, I have both types of firewalls, and I am just trying to plan out 
how many of what I should put where and why.  I really would prefer to use 
netfilter over pix, it will be an educational exercise for me.  I can D/L 
freeswan, and all the other goodies, and have plenty of boxen lying around 
collecting dust, lots of time and get paid no matter what I decide to do (see 
sig).

There has to be someone, somewhere, who understands what I am asking and has 
the answers.  I have the asbestos underwear properly installed, so flame on. 
I will summarize back to the list.

- -- 
Mike Taylor.  GSEC          Non Impediti Ratione Cogitationis
Coordinator of Systems Administration and Network Security
Indiana State University.                      Rankin Hall Rm 039
210 N 7th St.                                           Terre Haute, IN.
Voice: 812-237-8843
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE966WlknPysOadsKcRAj8HAJ0fYo3EBa9dcjKB/rbwcNRCKE+RpwCgulCb
38DjnIigdHaCkyWmWbpkyNA=
=mReT
-----END PGP SIGNATURE-----

IPTables Feature set and performance.

[hard__ware]

I belive you cant Mangle Packets as well on PIX Firewall
Such as TTL Values & MSS Clamps,

here are some things on why i consider netfilter over any other product for
now ..

1) its easy to understand & it works well
2) Completely Open Source Project
3) Using the help from www.lartc.org QoS can be seamlessly intergrated

4) Squid + Netfilter also offers more advantages like
Speedy Web Cache & ACL Rules to Block ADs ect,

5) IPTState is a good utillity for showing your Connections Through & Too
your netfilter firewall

6) IPTables Allows you to set Variables for its ip_conntrack_helpers such as
ftp & irc like,
the Default Port No: to track is 21 this can be changed to Many or Just One
using sysctrl options

7) Kernel Level Networking & Filtering /w Linux ..
have you got a problem, well if your good enough you
can make changes to your kernel / modules that will
improve / manipulate the way your IP V4 Box works.

hope this helps a bit,

Hard__warE

Re: IPTables Feature set and performance.

[Michael]

hard__ware wrote:

>I belive you cant Mangle Packets as well on PIX Firewall
>Such as TTL Values & MSS Clamps,
>
>here are some things on why i consider netfilter over any other product for
>now ..
>
>1) its easy to understand & it works well
>2) Completely Open Source Project
>3) Using the help from www.lartc.org QoS can be seamlessly intergrated
>
>4) Squid + Netfilter also offers more advantages like
>Speedy Web Cache & ACL Rules to Block ADs ect,
>
>5) IPTState is a good utillity for showing your Connections Through & Too
>your netfilter firewall
>
>6) IPTables Allows you to set Variables for its ip_conntrack_helpers such as
>ftp & irc like,
>the Default Port No: to track is 21 this can be changed to Many or Just One
>using sysctrl options
>
>7) Kernel Level Networking & Filtering /w Linux ..
>have you got a problem, well if your good enough you
>can make changes to your kernel / modules that will
>improve / manipulate the way your IP V4 Box works.
>
>  
>
In addition to this, I have found one mention of throughput capabilities 
of iptables. According to this reference :http://www.hipac.org/  (The 
performance test links), iptables does have significant limitation of 
throughput when large (Sequential) rulesets are used. I believe under 
ideal circumstances, and with carefull attention paid the impact can be 
minimised.

I haven't replicated the tests, and also do not know how authoritative 
the tests are.
If the tests results are accurate, this might help in making comparisons 
and decision making. Does anyone have evidence to backup the findings of 
nf-hipac peaple?

Cheers,
Michael

Re: IPTables Feature set and performance.

[Roberto Nibali]

Hi,

> In addition to this, I have found one mention of throughput capabilities 
> of iptables. According to this reference :http://www.hipac.org/  (The 
> performance test links), iptables does have significant limitation of 
> throughput when large (Sequential) rulesets are used. I believe under 

Exactly.

> ideal circumstances, and with carefull attention paid the impact can be 
> minimised.

Exactly.

But simply consider the fact that some people do not write their fw rules by 
hand, they generate it via a meta language layer. It is apparent that the 
generation of rulesets which span over multiple packet filter instances are 
implicit non-optimised.

Also consider the fact that the way nf-hipac is implemented, the matching rule 
lookup will always be equally or faster to netfilter's table lookup per 
definition and code.

> I haven't replicated the tests, and also do not know how authoritative 
> the tests are.

Preliminary tests were done by me and you can certainly consider them to be 
authoritative. Unfortunately due to health reasons and limited spare time I had 
to stop further tests. I will pick up the conduct of tests maybe in the 
beginning of next year. Together with a friend of mine I've also written a paper 
(for a link, please search this mailinglist archive) about the inefficiencies of 
various rule matching algorithms based on observation, pragmatic testing and 
code reading.

> If the tests results are accurate, this might help in making comparisons 
> and decision making. Does anyone have evidence to backup the findings of 
> nf-hipac peaple?

I do have some numbers and I have posted them to various mailinglists. Also if 
you go to the nf-hipac page itself, you see a quite a convincing test result.

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc