Perhaps it has something to do with Citrix being a dinosaur. God forbid the powers that be choose on premise unix. Regards Patrick
> On Jun 4, 2021, at 6:43 AM, Stuart Henderson <s...@spacehopper.org> wrote: > > On 2021/06/03 15:04, Chris Cappuccio wrote: >> Stuart Henderson [s...@spacehopper.org] wrote: >>> >>> Oh watch out with sloppy. Keep an eye on your state table size. >> >> Really? Wouldn't sloppy keep the state table smaller if anything since it's >> tracking less specifically? >> >> Anyways I use sloppy across four boxes that run in parallel with pfsync. >> There could easily be 10,000 devices behind it at any given time. I keep my >> state table limit at 1,000,000. It's around 300,000 during this lighter >> traffic period today. I had to do sloppy after moving to several boxes in >> parallel, I didn't notice sloppy making any significant difference? >> >> Chris > > The problem I had was in conjunction with synfloods. I didn't get > captures for everything to figure it out (it was in 2018 and my > network was in flames, with the full state table bgp sessions were > getting dropped / not reestablishing) but I think what happened was > this, > > spoofed SYN to real server behind PF > SYN+ACK from server > > and the state entry ended up as ESTABLISHED:ESTABLISHED where it > remained until the tcp.established timer expired (24h default > or 5h with "set optimization aggressive"). > > My "fix" was to move as much as possible to "pass XX flags any no state" > but that's clearly not going to help with what Denis would like to do. > (fwiw - I'm not doing flow monitoring regularly, but when I do it's > usually via sflow on switches instead, which solves some problems, > though it's only possible in some situations). >
