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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

S. Donaldson
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

shows nothing 

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 | 
                 "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 ) ] 


Reply | Threaded
Open this post in threaded view
|

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

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