I agree with Chris. This is NO WAY to test the throughput of a firewall. If
you want to test it in a fast and easy way, try iperf
http://dast.nlanr.net/projects/Iperf and you will see that m0n0wall performs
as one of the best (also the beta versions).
A pity that you came with this "problem" the way you did. Firewall newbies
could interpret it as a minus for m0n0wall, but instead it's a plus! The way
ICMP bulk traffic is handled is very well done.

Wim.

-----Oorspronkelijk bericht-----
Van: Chris Buechler [mailto:cbuechler at gmail dot com] 
Verzonden: zaterdag 26 maart 2005 18:17
Aan: Bryan Marc Schaubach
CC: m0n0wall at lists dot m0n0 dot ch
Onderwerp: Re: [m0n0wall] Why I left M0N0Wall

On Sat, 26 Mar 2005 11:33:30 -0500, Bryan Marc Schaubach
<omschaub at gmail dot com> wrote:
> 
> 
> My main machine does indeed run a gigabit card and I have had everybody
> I know run that ping command.. some on the stable m0n0wall version and
> some on beta versions and it all resulted in a 20-24% packet loss for
> EVERYBODY.. from someone using a 400mhz machine to even better than my
> 933 celeron with 512MB of ram!
> 

Yeah!  As designed!!  FreeBSD limits ICMP.  That means *nothing*.  See
your logs when you try to do that.

kernel: Limiting icmp ping response from 237 to 200 packets/sec
kernel: Limiting icmp ping response from 240 to 200 packets/sec
kernel: Limiting icmp ping response from 232 to 200 packets/sec
kernel: Limiting icmp ping response from 241 to 200 packets/sec
kernel: Limiting icmp ping response from 241 to 200 packets/sec

(about 10 times that many entries like that)  

That's because flooding ICMP is ridiculous and there's no need to bog
down the system with replying to several hundred or thousand pings a
second.


> 
> So I switched to ClarkConnect and now when I run the ping command, I get
> 0% packet loss..
> 

Heh.  Congrats, you now have a firewall that doesn't limit ICMP.  

If you can find a real benchmark that means something, I'd like to try it.  

But I think there is a bug in IPFilter that it doesn't work
exceptionally well with P2P because it tends to close connections
(remove from state table) before they're completed sometimes.  P2P
seems to be the only thing that actually has problems with this, and
it typically doesn't seem to cause any problems.