Hi First, thank you Paul and Andy for your input! I'm very thankful for your effort!
On Thu, 2014-10-09 at 16:08 +0100, Andy wrote: > I have seen this when the allowed number or states is too low and PF > clears the idle states too early.. > > See http://www.openbsd.org/faq/pf/options.html; > set optimization/option/ We already had "optimization" set to "conservative" and we also followed [1] to be sure that we don't hit the state table limit. The state table limit is set to 300k and we're seeing around 110k states per average and no massiv peaks. But what we do see is the following quite high number - could this be a problem (pfctl -s info)?: # pfctl -s info state-mismatch 9077705 1.4/s congestion 2228 0.0/s Some settings from our pf.conf which could be related: set block-policy return set debug urgent set fingerprints "/etc/pf.os" set limit states 300000 set limit src-nodes 50000 set loginterface none set optimization conservative set reassemble no set ruleset-optimization basic set state-policy floating set timeout frag 30 set timeout interval 10 So according to Paul the problem lays somewhere in pf itself, should we fill a bug in that case? Or can we do something more to make sure that the problem isn't on our side? Thanks again for your help and have a nice day! Kind regards, Nicolas [1] http://www.packetmischief.ca/2011/02/17/hitting-the-pf-state-table-limit/
