Traffic mysteriously dropping

Christopher McGee chris at xecu.net
Fri Mar 31 14:00:28 UTC 2006



Greg Hennessy wrote:

> 
>  
>
>>These 2 problems, are making pf, virtually unusable for our 
>>firewall needs.  Hopefully there is a fix for them.
>>
>>    
>>
>
>Have you tried to ifconfig polling for all the em interfaces ? 
>  
>
I thought the most current recommendations were not to use polling?  I 
thought this was something handled by most new hardware?

>I have recently installed a PF system on 6.1 prerelease with 4 * em + 2 *
>bge  & 80 odd rules, it's not sweating @ ~600 meg/sec being thrown at it.
>That's with ALTQ compiled in but not used in the policy at present. 
>
>  
>
Altq is compiled in on this machine also, however, when not being used, 
I see the same result.  I've seen many stories of 600Meg/sec+, however, 
up until now, I have not been able to accomplish it.

>Unless you are using synproxy I would suggest getting rid of set
>state-policy if-bound and stick with the default of floating.
>
>  
>
I have switched this back to the default.  I get the same result.  If I 
move the rule even 1 or 2 down in the list, traffic starts dropping on 
the http connections.  I will leave it this way though.

>Are all your stateful tcp rules using flags S/SA to establish state ?
>
>  
>
Not all of the rules are stateful, but the ones that are just use the 
"keep state" directive, they are not using S/SA.  Is this the 
recommended method?  I have read many of the examples and docs, and it 
appears this  is done both ways depending on where you read it.

>Are you running out of state table entries ? 
>  
>
>The default is 10k, tracking it with pfctl -si will tell you.
>
>  
>
We have a lot of smtp traffic sometimes, so for those times, we have 
bumped up the state limit, however, at times like my testing last night, 
there were between 4000 and 5000 states, a few hundred at a time would 
be my testing.

>With nearly 400 firewall rules, I would suggest that there's scope for
>reviewing order and the judicious use of quick to trim the policy into
>something more manageable. 
>  
>
Well, this is something that was inherited, and therefore is taking much 
time to fix, however, the rules will be trimmed.  I've already made 
extensive use of tables, and re-ordered/trimmed certain unnecessary 
things.  That is an ongoing process and with it being a production box, 
it's hard to make any drastic changes.

Chris


More information about the freebsd-pf mailing list