[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: really bizarre behavior (somewhat long)
From:       "Devon Bleak" <devon () admin2 ! gisnetworks ! com>
Date:       2001-04-29 19:03:01
[Download RAW message or body]

the system has 256MBs RAM...  the trick just seems to be getting it all used...  i think i saw a #define on the max number of state table entries a while back (or a variable that directly translated to it)...  i'll have to experiment with it...  we get a _lot_ of incoming connections though (20M+ most days), so i'd like to refrain from keeping state on all of them if i can (in case of a huge increase in traffic one day, i don't want the firewall running out of state entries and choking the traffic).

i'll try putting in the 'pass out all' rule and see if that helps any...

devon


----- Original Message ----- 
From: "Gert-Jan Vons" <vons@iname.com>
To: "Devon Bleak" <devon@admin2.gisnetworks.com>
Cc: <ipfilter@coombs.anu.edu.au>
Sent: Sunday, April 29, 2001 2:27 AM
Subject: Re: really bizarre behavior (somewhat long) 


> At 22:10 28/04/2001, Devon Bleak wrote:
> 
> >as for keeping state: i'm not trying to keep state on connections coming 
> >in on fxp0.  i'm trying to keep state on tcp/udp/icmp connections 
> >originating from machines on fxp{1,2,3} (which doesn't work with the 
> >aforementioned 2.8 kernel, but does work with the aforementioned 2.7 
> >kernel), but i still need the packets from those connections incoming to 
> >fxp0 to be passed back through the firewall.
> 
> If you don't keep state on fxp0, you'll need explicit rules to let 
> _everything_ out with something like "pass out quick on fxp0 all".
> 
> If it works with the older ipfilter version without such a rule, it must be 
> due to a bug or something.
> 
> >i tried keeping state on all incoming connections when i first wrote the 
> >rules and my state table filled up quite quickly (if anybody knows how to 
> >get state tables to use as much memory as the machine has available that'd 
> >be a nice tip).
> 
> If you have so many active connections that the table fills up, your system 
> may be under-dimensioned.
> 
> If you get lots of state table entries even for a small number of 
> connections, you may have a problem with your rules (like keeping state on 
> each packet instead of only the initial syn?)
> 
> If the table is full with dead connections (e.g. lacking the final close), 
> you should be looking elsewhere for the cause of the problem.
> 
> Note that the timeout values for tcp/udp/... connections can be tuned.
> 
>     Gert-Jan
> 
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]