Re: Updating PF to OpenBSD Release 4,1

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Also state keeping is working (and is now default, not due to my 
:decision but it became default in OBSD 4.1 afaict). So this is ready now 
:for "public" testing. I would appreciate very much if people with some 
:sophisticated setup or in-depth pf knowledge could test and give some 
:feedback.

    Yah, this is fine, I'll give up on trying to keep the original
    style and having an option to enable it.

    However, there is one feature of the state keeping which we
    implemented first and Net/OpenBSD implemented later, and 
    that is our 'pickups' feature, as in:

    set keep-policy keep state (pickups)

    In the pre-change DragonFly pf.  Pickups needs to be the default
    too, and I don't think the net/openbsd equivalent feature is.
    (I don't recall what net/openbsd called their equivalent feature).

    What this flag does is allow the router running the PF rules to
    be rebooted and lose its state array without causing all the
    TCP connections that were active as of the time of the reboot
    from getting RSTs after the reboot completes (due to lack of
    information on the window scale sub-state which is only available
    in the SYN/SYN+ACK sequence).  I absolutely do not want the
    default to be that a router reboot causes all active TCP connections
    to get RST'd.

:Be aware that this still pukes out tons of debugging info (propably not 
:useful to anyone but me) on the sys console. I will remove those step by 
:step now.
:
:Finally also be aware that my branch is still based on master from May 
:or so. I haven't rebased it yet. Will do that some time soon.
:
:http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/pf_update
:
:
:Jan

    Two more things:

    On the fairq stuff we use the state info pointer (I think) to hash
    the buckets the fairq uses.  I think Net/OpenBSD also wound up
    doing something similar, though perhaps with a slightly different
    API.  That is the only special thing that the FAIRQ implementation
    needs to operate.  FAIRQ is mandatory, we're the only ones who
    implement it other than Cisco (at least as of 8 months ago).

    Lastly you may need some extra focus on the RDR rules.  On my router
    box I am forced to use IPFW 'fwd' rules for default route adjustment
    because RDR rules in PF don't seem to be reinjected, so it is not
    possible to have RDR rules which then also run through NAT or other
    translation features.  And even with IPFW it doesn't seem to work
    perfectly.  Very annoying to say the least.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>