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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
