PF match rules questions..

Onepamopa

Onepamopa

Hello,

Got a few questions in regards to the "match" rules.
From what I understand - they do not create states, and, multiple rules are evaluated (i.e. it's not first/last match "wins")

The question is - why do these rules allow, for example:
Code: 
match in on ix0 inet proto tcp from any to 11.22.33.44 port = 60000 flags S/SA keep state (source-track rule, max-src-conn 1, overload <maxconn>, src.track 10)
match in on ix0 inet proto tcp from any to 11.22.33.44 port = 60000 flags S/SA keep state (source-track rule, max-src-conn-rate 1/1, overload <connrate>, src.track 10)
And ... nothing gets "overloaded" in the tables?

I also tried:
Code: 
match in on ix0 inet proto tcp from any to 11.22.33.44 port = 60000 flags S/SA keep state (source-track rule, max-src-conn 1, src.track 10) tag maxconn
match in on ix0 inet proto tcp from any to 11.22.33.44 port = 60000 flags S/SA keep state (source-track rule, max-src-conn-rate 1/1, src.track 10) tag connrate
pass in on ix0 from any tagged maxconn keep state (source-track rule, max-src-conn 1, overload <maxconn>, src.track 10)
pass in on ix0 from any tagged connrate keep state (source-track rule, max-src-conn-rate 1/1, overload <connrate>, src.track 10)
but, for some reason only the 2nd pass rule actually does anything (i.e. overload in table).

As you could probably gather, the idea is to be able to "tell" why an IP went into 1 of the 2 tables. The values 1 and 1/1 are for testing purposes only - to force overloading without making a ton of connections.

Ideas? Why the match rules don't do what (I thought) they should?
Any other option to achieve max-src-conn and max-src-conn-rate overloading in separate tables without the "first/last rule taking precedence" ?
 
match action does not create a state, and cannot be used in states evaluations. In your example packet gets two tags = maxconn and connrate. And then matches two pass rules, where the last rule wins.
 
shurik said:
match action does not create a state, and cannot be used in states evaluations. In your example packet gets two tags = maxconn and connrate. And then matches two pass rules, where the last rule wins.
Click to expand...
So then what's even the purpose of a "match" rule... ?
 

Onepamopa​

from man pf.conf
match
The packet is matched. This mechanism is used to provide fine
grained filtering without altering the block/pass state of a
packet. match rules differ from block and pass rules in that pa-
rameters are set for every rule a packet matches, not only on the
last matching rule. For the following parameters, this means
that the parameter effectively becomes "sticky" until explicitly
overridden: queue, dnpipe, dnqueue, rtable, scrub
Click to expand...
 
skeletor I've read that already and it predates my questions in the first post:

Why do these rules allow, for example:
match in on ix0 inet proto tcp from any to 11.22.33.44 port = 60000 flags S/SA keep state (source-track rule, max-src-conn 1, overload <maxconn>, src.track 10)
match in on ix0 inet proto tcp from any to 11.22.33.44 port = 60000 flags S/SA keep state (source-track rule, max-src-conn-rate 1/1, overload <connrate>, src.track 10)

What's the point of being able to set such rules, if they won't be able to do anything? And why have most of you focused on the 2nd part of the post - the tags? That was just an attempt to do the same thing I tried with the above rules.

match action does not create a state, but can(should be able to) match one.
Maybe something needs to change so rules in such use-cases would be able to "work", and if "match" isn't a good "candidate" then maybe something new should be introduced?
How about having a combined max-src-conn and max-src-conn-rate in a single rule with 2 separate overload tables, one for each condition?
 
Ok, Onepamopa . Let's answer to your question.

Q: 1. Why do these rules allow, for example:
A: shurik has already answered for your question :
And then matches two pass rules, where the last rule wins.
Click to expand...

Q: 2. What's the point of being able to set such rules, if they won't be able to do anything?
A: The main reason is mark packets and then (using a new pass or drop rules) you can manipulate packets according to their marks/tags.

Q: 3. How about having a combined max-src-conn and max-src-conn-rate in a single rule with 2 separate overload tables, one for each condition?
A: It depends on your tasks.

I reread again all of your posts and a little bit confused, could you clarify, what exactly you don't understand about "match"?
 
You must log in or register to reply here.
Back
Top