On 2020/03/06 18:53, Jyri Hovila [Turvamies.fi] wrote: > Hi! > > > Look at pfctl -ss -v. Do you have "wscale" values printed for most > > TCP connections? > > There's wscale for all the active connections, at least at the moment. > > > If not then you are likely creating state on intermediate > > rather than ACK packets (window scaling values are not present in most > > packets, only the initial handshake). If that is the case, make sure > > you don't have anything passed by the implicit default rule which is > > equivalent to "pass all flags any no state", > > I don't pass anything without a state. > > > I like to make sure I don't > > hit this by starting my ruleset with "block log". > > This has always been the default approach for me, since day 1. > > Note that I've used more or less the same setup, based on and refined from > several "howto do it properly with pf" articles, for literally decades. It's > the first time ever I'm experiencing the issue. Since I'm following CURRENT, > I'm leaning towards the conclusion that rather than anything being wrong with > my ruleset, something has changed in the kernel / pf. Disclaimer: can't be > sure, of course. > > > Note the paragraph starting "Where more than one firewall might actively > > handle packets" in pfsync(4) if this might apply to you. > > There's nothing like that going on here; it's a traditional single-host setup. > > Actually, I'm experiencing the same issue on two hosts -- both of which were > functioning fine until about a month ago this problem popped up. > > > You can also try bumping up the PF debug level (pfctl -x; the default > > is "err"), be careful doing this on a busy system (take it up one notch > > at a time and make sure it doesn't create insane amounts of logging, be > > ready to knock back to a previous level if needed). Be extra careful > > with this if you have serial console. > > I'll try this. > > -j. >
Thanks, and sorry I missed in your previous mail that things were working OK before. In which case it doesn't sound like a configuration problem which I wasn't sure about. Do you have any logs that might help tie it down to a shorter timeframe? (kernel messages at boot ae written to /var/log/messages, so the snapshot date will show up there if the logs haven't rotated away yet). I think it would be good to move this to bugs@ as it won't get the attention it needs on misc - can you collate things into one mail and include a dmesg please?
