Hi Mark, I'm one of the people who managed to get in trouble due to this, and I thought I'd just mention that the situations where it can occur can be quite subtle, for example: block all pass in on $external proto tcp from $internet to $webserver port $http pass out on $internal keep state pass out on $external keep state
I figured since "the state" would be "floating" that I'd create all the states on outgoing, but later learned that it's actually two different states, so the $external state will be created with the returning SYN+ACK packet, thus breaking wscale support. From what I can understand so far state entries are bound to either "receive" or "send" queues on interfaces, and "floats" between for example different receive queues on different interfaces, but not between different receieve and send queues... Now I love tools with sharp edges, and if I err and cut myself I'm to blame, but I think the tools also be documented enought to allow people to be creative without having the blade snap. From the OpenBSD manual: "By default, packets coming in and out of any interface can match a state, [...]", but if I create "a state" from A to B on the intial SYN packet on an _outgoing_ internal interface, the returning SYN+ACK will _not_ match it on the external interface (since it's "returning" and thus should be "incoming" I guess?), create a new state, and break window scaling. This to me, still after re-reading documentation, seems like an error in either the documentation or the implementation. Kind regards, Fredrik Widlund Mark Voelker wrote: >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 > >
