Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Oct 2001 09:44:31 -0400
From:      Kenneth Culver <culverk@yumyumyum.org>
To:        FreeBSD <freebsd@XtremeDev.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: IPFW or IPFILTER?
Message-ID:  <20011013134430.8E19E37B411@hub.freebsd.org>
In-Reply-To: <20011013011937.B75955-100000@Amber.XtremeDev.com>
References:  <20011013011937.B75955-100000@Amber.XtremeDev.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 13 October 2001 03:28 am, you wrote:
> > On Fri, 12 Oct 2001, Kenneth Wayne Culver wrote:
> > > I suppose another big reason that I started using ipfilter is it's
> > > performance... for me and for what we do through our FreeBSD router
> > > (with gaming through the nat) ipfw + natd just wasn't cutting it.
> >
> > 	I don't buy that...let's see some numbers people...
>
I'd give numbers if I was doing another lanparty soon. :-) That was the only 
time I ever measured... 

> No numbers from me. I've never done a performance compare between the two.
> Wouldn't mind seeing it though.
>
> > 	Since everyone is giving their opinions, I might as well share
> > 	mine as well.  Even though, this conversation does not belong on
> > 	-stable.  Hell, it doesn't even belong on -questions.  More like
> > 	-chat or something.  But anyway I'm a big IPFW fan because :
> >
> > 	1) it is simple and straightforward.  IPFILTER has ipf, ipfstat,
> > 	ipmon, ipnat...what a head-ache.  IPFW has ipfw...
>
> ipf and ipfstat shows more info than ipfw alone. ipmon is a whole 'nother
> program, doesn't really fit into the comparison. Like adding in ngrep or
> something. And ipnat controls nat, what natd does for ipfw. So the
> only "complexity" is ipfstat which gives stat info. Big whup.

I agree, one of the reasons I chose ipfilter was because it has ipfstat. It 
lets me watch the state table in real time (well once per second, but that's 
close enough) and because ipnat lets me see the nat  table. I couldn't find 
anything similar in FreeBSD. 
>
> > 	2) IPFW can bring packets out of the Kernel into userland via
> > 	divert...this can be a very powerful interface that only a few
> > 	things use that I know of, one of them being natd.  Of course,
> > 	this could be dangerous too.
>
> No comment on this one. Powerful yes, dangerous possibly. Performance hit?

For me it was a performance hit, although you really had to load it down to 
see the hit.
>
> > 	3) It comes as a kernel module.  I'm tired of building a kernel on
> > 	every machine to enable IPFILTER.
>
> IPF is available as a kernel module. /modules/ipl.ko.
> Need to load it on a GENERIC system? kldload ipl.ko.
>
> > 	4) Bandwidth control
>
> ipf is lacking in this respect. I would rather see AltQ or some other
> standard thing (doesn't KAME use AltQ? Isn't that part of FreeBSD base
> now?) though, than something more to bloat ipf code.

It works fine when using altq with it. I'm doing that now to control 
bandwidth usage on my DSL connection.
>
> > 	5) Bridging firewalls
>
> Being worked on. As someone else have pointed out, ipf has supported
> bridging on other systems for a long time, it's just been lacking proper
> support in FreeBSD.
>
>
>
> Not trying to flame, but thought I'd toss in my two cents. The point is
> that it's great to have a choice, and you use the firewall with the
> feature set that best fit your needs. Or both if you prefer the
> combination.

I'd have to agree here too.

Ken

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011013134430.8E19E37B411>