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.
