Updating PF to OpenBSD Release 4,1

Jan Lentfer Jan.Lentfer at web.de
Thu Jul 22 22:51:48 PDT 2010


Matthew Dillon schrieb:
    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.
  
What would be a real life example for such a setup so I can test this? E.g.

10.94.76.100 telnet --> 10.94.76.177 (rdr telnet) ->  192.168.0.100

and then reboot 10.94.76.177 when the telnet session is established 
between 10.94.76.100 and 192.168.0.100? I guess the session should stall 
while 10.94.76.177 is rebooted and become "live" again when 
10.94.76.177/PF is up again?

    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).
  
Do you have a pf.conf example for a fairq setup?

    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.
  
Hmm... I use PF on OpenBSD 4.6 as my primary router to internet. I am 
quite sure that rdr rules are subject to nat'ing but I will try to 
create a test setup to evaluate.

Jan





More information about the Kernel mailing list