HEADS UP - full build recommended for master, PF comments
dillon at apollo.backplane.com
Mon Sep 1 14:10:35 PDT 2014
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
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
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.
<dillon at backplane.com>
More information about the Users