Daniel, Thanks for a very lucid explanation! I had wondered if it might be more of a user error situation (and thankfully I've only discovered one such erroneously configured OpenBSD machine so far!).
Mark --- Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > On Fri, Jun 30, 2006 at 09:40:38PM -0700, Mark Voelker wrote: > > > I'm frequently hearing (not only in these threads) that pf > is > > thought to be buggy with regards to window scaling that and > that > > it can cause problems like those described in these threads. > > > Problems like this occur when people use pf to filter > statefully, > but do not create state on the initial SYN of TCP connections. > > Window scaling support is negotiated in the SYN and SYN+ACK > packets of connection establishment. pf can only support it > properly when both these packets are seen and associated with > a state entry (i.e. you create state on SYN and SYN+ACK > matches > the state). > > If the ruleset passes the SYN packet statelessly (without > 'keep > state'), but then creates state on the returning SYN+ACK, the > state entry has missed the window scaling negotiation. There > were a couple of reports of people who managed to do this, all > by mistake (if you intend to create state, you most certainly > want to do it on the initial packet). > > Most people would call these misconfigurations (buggy > rulesets), > but some people feel that only a buggy program would allow a > user to make such a mistake, hence pf must be buggy. Hence the > myth of "pf is buggy wrt window scaling". I suggest these > people > don't use tools with sharp edges, they could hurt themselves > ;) > > If you want a simple way to ensure this is not happening with > your ruleset, make sure that > > a) there is a default block policy > b) all 'pass' rules that can match TCP have 'flags S/SA' > c) all 'pass' rules have 'keep state' > > And, no, other packet filters have no magical way of deducing > the > proper scaling factors if they missed the handshake. If they > don't > stall connections in this scenario, it just means they are > using > sloppy TCP window restrictions or don't check TCP sequence > numbers > at all. We are proud of our strict window checks :) > > Daniel > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
