this is indeed the way it was supposed to work.

* David Gwynne <[email protected]> [2011-08-10 05:44]:
> this reflects my understanding of how this was supposed to work. i have
> written rules with the expectation that they work this way.
> 
> On 10/08/2011, at 4:56 AM, Mike Belopuhov wrote:
> 
> > Hi,
> >
> > I'd like to propose the following change in the pf ruleset evaluation:
> >
> > Index: pf.c
> > ===================================================================
> > RCS file: /home/cvs/src/sys/net/pf.c,v
> > retrieving revision 1.770
> > diff -u -p -r1.770 pf.c
> > --- pf.c    3 Aug 2011 12:28:40 -0000       1.770
> > +++ pf.c    9 Aug 2011 15:50:42 -0000
> > @@ -2924,6 +2924,11 @@ pf_test_rule(struct pf_rule **rm, struct
> >             PF_TEST_ATTRIB((r->match_tag && !pf_match_tag(m, r, &tag)),
> >                     TAILQ_NEXT(r, entries));
> >             PF_TEST_ATTRIB((r->rcv_kif && !pf_match_rcvif(m, r)),
> > +                   TAILQ_NEXT(r, entries));
> > +
> > +           /* see if a rule has reached a maximum number of states */
> > +           PF_TEST_ATTRIB((r->anchor == NULL && r->keep_state &&
> > +               r->max_states && r->states_cur >= r->max_states),
> >                     TAILQ_NEXT(r, entries));
> >
> >             /* FALLTHROUGH */
> >
> >
> > I have an application that dynamically inserts rules like that into
> > the anchor:
> >
> > anchor "foo/*" all {
> >  anchor "7" all {
> >    pass in quick on rdomain 0 inet proto udp from 10.0.2.2 to 10.0.1.2 port
> = 759 flags S/SA keep state (max 1) rtable 0 prio 0
> >  }
> >  anchor "8" all {
> >    pass in quick on rdomain 0 inet proto udp from 10.0.2.2 to 10.0.1.2 port
> = 759 flags S/SA keep state (max 1) rtable 0 prio 0
> >  }
> > }
> >
> > as you can see source and destination addresses as well as a destination
> > port are the same, but these rules serve for two different concurrent
> > connections (source ports are different).
> >
> > Currently this won't work because the first rule matches the second
> > connection and when pf_create_state bails out we are already not in
> > the rule evaluation loop and drop the packet.
> >
> > I consider this to be a misfeature and prefer the ruleset evaluation
> > to continue, hence the diff.  What do you think?  Any objections?
> >
> > And just to be clear, this is NOT considered for the 5.0 release.
> 

-- 
Henning Brauer, [email protected], [email protected]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply via email to