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: [ 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 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 ) ] |
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 |
Free forum by Nabble | Edit this page |