Recently, I had a problem when some of my friends told me that out voice chat was choppy. When I investigated, I found my OpnSense at 100% CPU. That turned out to be due to 7 WAN block rules for various blocklists and an ongoing DDOS attack.
I had logging enabled for those rules and the log was constantly being written to. I could not even reliably use the web UI.
This made me think about how to rate-limit the logs. Apparently, with 26.7.2, there is now max-pkg-rate from pf available.
So, now, you can create two block rules, one with logging enabled, quick block and "Max packet rate [packets]" = 1 and "Max packet rate [seconds]" = 1 to have a rule that matches at most once per second and logs and another quick block rule without logging and without rate limits immediately following that.
By using that, you still have (rate-limited) logging, but without the risk for a totally overwhelmed OpnSense.
Alas, you need two rules, because the first one will not match any more when the rate limit has been exceeded. Would there be a better way of having such a thing (i.e. eat the cake and still have it)?
P.S.: Allowing rate-limiting on block rules is a potential security hole, IMHO: When you use that without thinking, the block will not be applied when the rate is too high, i.e. block rules can be circumvented by just hitting more frequently at the target....
I guess the original idea was to do this for pass rules only and rate-limiting those on the side.
It seems to me the rule should be applied regardless if the log rate limit has been reached. Obviously, without logging.
There is no log rate limit, yet. @meyergru created a hack using the rule application limit and two consecutive rules to achieve the desired effect.