Date: Wed, 3 Sep 2008 16:42:37 +0200 From: Guido van Rooij <guido@gvr.org> To: Jon Radel <jon@radel.com> Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections fails (?) Message-ID: <20080903144237.GA28697@gvr.gvr.org> In-Reply-To: <48BE9B74.90404@radel.com> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 03, 2008 at 10:13:08AM -0400, Jon Radel wrote: > > And why is that so? This bascially rules out keep state on outgouing packets > > on any router-type system. That seems like an unnecessary limitation. > > What? If you want state, turn it on: > > block all > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > should work fine also. Other things being equal (in other words, your > mileage may vary....), that is both more secure and more efficient than > the first rule set I offered as an example. I sent the first one only It's certianly not more efficient as one needs twice as many state entries. > because you insisted that your real rule set for 5 interfaces would not > allow you to maintain state on ep0 (or its equivalent). Suppose I want to limit traffic to 10.0.0.2 which is behind bge0. Then when solving this with keeping state on outgoing packets on bge0 means a single rule. With your suggestion, the amount of rules is five times as big because then I need to add keep state rules for incoming packets on the other interfaces as well. > > You still haven't given us any hints as to why the solution which > maintains state on all interfaces is impossible for you. Like with the ruleset you posted, a single keep state rule is sufficient. > > > > > I have not yet heart any reason why this is the case. pf was modelled > > after ipf, so I wonder why this change in state handling was introduced. > > This is probably the wrong list if you want to have people justify > design decisions. > I honestly don't think this was a design decison, but a bug in pf. Like I said, the state engine was modelled after ipf's (hack, the whole TCP-sepcifics came from a paper I wrote), which behaves exactly similar as pf, _except_ for this specific scenario. So it shure smells like a bug. Please try to undeerstand my question: the question is not: how do I work around a failing ruleset. The question is: why doesn't it work. -Guido
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080903144237.GA28697>