On Wed, Feb 15, 2023 at 01:01:10PM -0000, Stuart Henderson wrote:
> On 2023-02-15, Lars Bonnesen <lars.bonne...@gmail.com> wrote:
> > One says:
> >
> > # pfctl -s info
> > Status: Enabled for 0 days 10:56:43              Debug: err
> >
> > State Table                          Total             Rate
> >   current entries                    91680
> 
> Lots of entries, close to the default:
> 
> $ doas pfctl -sm 
> states        hard limit   100000
> src-nodes     hard limit    10000
> frags         hard limit    65536
> tables        hard limit     1000
> table-entries hard limit   200000
> pktdelay-pkts hard limit    10000
> anchors       hard limit      512
> 
> >   half-open tcp                       4032
> >   searches                      3132304294        79494.1/s
> >   inserts                         60916552         1546.0/s
> >   removals                        60824872         1543.7/s
> > Counters
> >   match                           79164265         2009.1/s
> >   bad-offset                             0            0.0/s
> >   fragment                               1            0.0/s
> >   short                                  0            0.0/s
> >   normalize                              0            0.0/s
> >   memory                           1768012           44.9/s
> 
> And this most likely means that you've been bumping into the
> state limit plenty of times already.
> 
> >   bad-timestamp                          0            0.0/s
> >   congestion                          1201            0.0/s
> >   ip-option                              0            0.0/s
> >   proto-cksum                          387            0.0/s
> >   state-mismatch                  82794949         2101.2/s
> 
> Loads of state mismatches and, looking at the rate, this is
> probably on an ongoing basis.
> 
> Check to make sure that all packets match either a "pass" or "block"
> rule (the easiest way to do this is usually to have a simple "block"
> or "block log" as the first rule) - if you don't have any matching
> rule in the config, there is an implicit default which passes traffic
> *without* creating state.
> 
> (One particularly common result of this is that TCP window scaling
> isn't handled properly such that longer lived or fast TCP connections
> are likely to slow down or stall.)
> 
> You might also need to bump the state limit, but I'd check the above
> first because the high number of states might be caused because of
> mismatches.

I think the state-mismatch is a result of hitting the state limit and not
the other way around.  At over 90'000 states the default timeouts are
reduced by more than 50% and so states are removed too soon resulting in a
state-mismatch.

So first bump the limit up and then look at the counters again.

-- 
:wq Claudio

Reply via email to