pfctl 'indicates' states created for 'match' rules or some other stat is being shown?
The output (somewhat redacted) below is from pfctl (OpenBSD 61, amd64, GENERIC.MP kernel).
The rules in question deal with NATing and forwarding packets for sessions that are very short monitoring 'is this service alive' type sessions. So we've tried to limit the number of states, and shorten state life to match the type of traffic.
Internal traffic (and monitoring host) --> FW_em0 pf --> FW_em1 --> monitored systems in DMZ
Curiously the pfctl command shows states for a 'match' rule as per:
pass in quick on em0 inet from 172.a.b.c to <other_dmz_monitoring> flags S/SA keep state (max 200, source-track rule, tcp.established 15, tcp.closing 3, adaptive.start 120, adaptive.end 240) [ Evaluations: 10766662 Packets: 327374 Bytes: 19532619 States: 200 ] [ Inserted: uid 0 pid 24982 State Creations: 29979 ] match out on em1 inet from 172.a.b.c to <other_dmz_monitoring> received-on em0 tag monother nat-to ext.net.add.xxx [ Evaluations: 5693609 Packets: 566240 Bytes: 34069203 States: 347 ] [ Inserted: uid 0 pid 24982 State Creations: 0 ]
However 'keep state' and per rule session tracking are not allowed on match 'actions'.
The above rules are rule 10 and rule 11 in the ruleset. So when I ask to see states by rule
pfctl -s state -R 10
shows states as expected
pfctl -s state -R 11
So is that State count on a 'match' action actually some other statistic?
I tried following the grammar in the pf.conf man page and to me it seems like the match action is allowed both 'keep state'
and I just got confused trying to parse the 'filteropt' definition. See below....
Scott Donaldson Manager of MIS Special Projects SED Systems a division of Calian Ltd. Saskatoon, SK Canada
Office Phone: 306-933-1577
pf-rule = action [ ( "in" | "out" ) ]
[ "log" [ "(" logopts ")"] ] [ "quick" ]
[ "on" ( ifspec | "rdomain" number ) ] [ af ]
[ protospec ] [ hosts ] [ filteropts ]
action = "pass" | "match" | "block" [ return ]
filteropts = filteropt [ [ "," ] filteropts ]
filteropt = user | group | flags | icmp-type | icmp6-type |
This syntax doesn't tell you what the valid rule combinations are,
only what combinations won't fail out of the gate because they cannot
be parsed. There will still be rules that can be parsed but which
can't be understood (e.g. including all three of "nat-to", "rdr-to"
and "binat-to" in a single rule, which the syntax doesn't forbid) or
which simply make no sense (e.g. "set queue" using a non-existent
queue). Also there will be rules which appear to be sensible but
which cannot actually be accomplished by the underlying packet
filtering software (consider these unimplemented features or design