HEADS UP - full build recommended for master, PF comments

[Matthew Dillon]

    I've made some commits to the PF code in master.  A full buildworld
    and buildkernel is recommended.  If you wish to do an incremental build
    then I suggest:

	a full buildkernel
	cp /usr/src/sys/net/pf/pfvar.h /usr/include/net/pf/
	cd /usr/src/usr.sbin/pfctl; make clean; make obj; make all install

    This is because the pf state reporting (pfctl -s state) structure
    has changed size.

    --

    Anyone using RDR rules in PF needs to be cognizant of how RDR rules
    work.  The RDR rule will match and create state on the packet input
    path (NAT rules in contrast match and create state on the packet
    output path).  Any packets coming from the original direction will
    then match that state on the input path.  However, *return* packets
    coming from the other side will match the state on the packet output
    path.

    This means that in the forward direction the packet can still match a
    PASS OUT rule in the output path and in the reverse direction the
    packet can still match a PASS IN rule in the input path without
    conflicting with or matching the established RDR state at those points
    in the filter.

    If you have a PF configuration using RDR and also have PASS rules
    as described above, the PASS rules will only see one side of the
    tcp connection (because the RDR eats the other side).  Thus, any
    such PASS rules must be sure to either not specify a 'keep state'
    clause and thus use the default keep state (which is 'pickups' and
    'sloppy'), or if they do specify a 'keep state' clause they must be sure
    to specify the 'pickups' and 'sloppy' option to prevent those states
    from doing full-duplex tcp sequence spcae checks and RSTing the
    connection.

    This shouldn't effect too many configurations since the default keep
    state is 'pickups' and 'sloppy'.

    --

    It's unclear what the designers intended for this sort of combination
    of rules in terms of TCP stateful checking, or if the designers intended
    the PASS rules to not establish any PASS state at all.  But in reading
    various implementations I don't see how PASS state would not be
    established.  It's harmless as long as it doesn't do full tcp state
    checking, but I dunno.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>