Re: pfctl 'indicates' states created for 'match' rules or some other stat is being shown?

On Mon, Jan 15, 2018 at 6:02 PM, S. Donaldson <[email protected]> wrote:
> 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     ]

I am going to guess that while this rule created no states, it was
evaluated for outbound traffic related to a state created by some
other rule (a 'pass out' rule I imagine).


> and I just got confused trying to parse the 'filteropt' definition. See
> below....
>
> 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 |
>                  "tos" tos |
>                  ( "no" | "keep" | "modulate" | "synproxy" ) "state"
>                  [ "(" state-opts ")" ] | "scrub" "(" scrubopts ")" |
>                  "fragment" | "allow-opts" | "once" |
>                  "divert-packet" "port" port | "divert-reply" |
>                  "divert-to" host "port" port |
>                  "label" string | "tag" string | [ "!" ] "tagged" string |
>                  "max-pkt-rate" number "/" seconds |
>                  "set prio" ( number | "(" number [ [ "," ] number ] ")" ) |
>                  "set queue" ( string | "(" string [ [ "," ] string ] ")" )
> |
>                  "rtable" number | "probability" number"%" | "prio" number |
>                  "af-to" af "from" ( redirhost | "{" redirhost-list "}" )
>                  [ "to" ( redirhost | "{" redirhost-list "}" ) ] |
>                  "binat-to" ( redirhost | "{" redirhost-list "}" )
>                  [ portspec ] [ pooltype ] |
>                  "rdr-to" ( redirhost | "{" redirhost-list "}" )
>                  [ portspec ] [ pooltype ] |
>                  "nat-to" ( redirhost | "{" redirhost-list "}" )
>                  [ portspec ] [ pooltype ] [ "static-port" ] |
>                  [ route ] | [ "set tos" tos ] |
>                  [ [ "!" ] "received-on" ( interface-name | interface-group
> ) ]
>
>

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
limitations).

-ken