This topic is to share some basic understandings I have to be corrected if wrong and to also bring up some ideas with a goal of optimizing RouterOS firewall rules in production environments. So, I am going to focus on a snippet from this page -> https://help.mikrotik.com/docs/spaces/R ... d+Firewall, namely, the section as follows.

/ip firewall raw
add action=accept chain=icmp4 comment="defconf: echo reply" icmp-options=0:0 limit=5,10:packet protocol=icmp
add action=accept chain=icmp4 comment="defconf: net unreachable" icmp-options=3:0 protocol=icmp
add action=accept chain=icmp4 comment="defconf: host unreachable" icmp-options=3:1 protocol=icmp
add action=accept chain=icmp4 comment="defconf: protocol unreachable" icmp-options=3:2 protocol=icmp
add action=accept chain=icmp4 comment="defconf: port unreachable" icmp-options=3:3 protocol=icmp
add action=accept chain=icmp4 comment="defconf: fragmentation needed" icmp-options=3:4 protocol=icmp
add action=accept chain=icmp4 comment="defconf: echo" icmp-options=8:0 limit=5,10:packet protocol=icmp
add action=accept chain=icmp4 comment="defconf: time exceeded " icmp-options=11:0-255 protocol=icmp
add action=drop chain=icmp4 comment="defconf: drop other icmp" protocol=icmp

So, here goes, when this chain icmp4 is jumped to it starts at the topmost line testing packets and if it matches a rule is accepted and doesn't proceed to the next line leaving the chain but essentially leaves the chain going back to where it was jumped from. In this scenario that would mean once a packet matches a rule it would then go on to the line "add action=jump chain=prerouting comment="defconf: jump to TCP chain" jump-target=bad_tcp protocol=tcp" directly under the jump line of "add action=jump chain=prerouting comment="defconf: jump to ICMP chain" jump-target=icmp4 protocol=icmp". Correct? Or, if it doesn't match any particular action=accept rule it advances on to the next set of rules potentially not matching any of the action=accept rules and getting to the action=drop rule. Perhaps an add to a list which a function operates off sending abuse reports would be in order behind the scenes but I'll focus on these rules.

So, as I understand it, if a packet is going through these rules and it is an icmp packet type 8 code 0 it is going to be tested first by the prior 6 rules in the icmp4 chain, unless, logic behind the scenes to optimize rule processing is taking place. While I am not sure how much it would help in things like decreasing both latency and cpu processing with this set of rules, while they are nicely ordered with the lower icmp types first, and next, the lower icmp codes first, as follows (0,0; 3,0; 3,1; 3,2; 3,3; 3,4; 8,0; 11,0-255) which is helpful in organizing rules, I am assuming it likely with most production environments there would be more matching icmp echo and reply rules than the other rules so pushing them up to the top of the chain assuming the logic itself doesn't change in an optimized set of rules would be beneficial, correct?

So, this brings me to another question kind of related to how in compiling code human language is analyzed looking for patterns that would make the code faster without changing the logic before creating an executable. In practice is there already something going on in how RouterOS handles these rules where it detects things it can optimize without changing the logic or would it be potentially beneficial to work towards putting the most likeliest matches first, not just in this scenario with an icmp chain named icmp4, but other chains and also just in overall goals of writing firewall rules and even adapting when in production perhaps even when handling DDoS scenarios as things change, so that when packets traverse through testing of less likely to be matched rules are not done? I imagine a running firewall could do things like as traffic patterns change after an epoch of say 5 minutes has expired rearrange the order or processing rules where for that set of rules it doesn't affect the logic of traffic flow such that the most commonly matched rules are processed first.

There is no magic in compilation and evaluation of firewall rules. They are strictly evaluated top-to-bottom, first matching executes. So the optimization trick is to reduce average number of rule evaluations (it was never explicitly stated whether all rules cost same CPU to evaluate or not, I'd expect that rules with less matching criteria or simpler matching operations will be evaluated quicker). Usually rules, which match most packets, are placed first (e.g. accept established,related is often top most). Using custom chains (such as yours for ICMP) can reduce average number of evaluations as all non-ICMP packets are only evaluated against single rule.

A thing to remember with custom chains: if packet triggers execution of some rule, then processing of that packet is finished in that firewall stage ... so if ICMP packet is sccepted in your custom chain, processing doesn't return to the basic chain (where processing started before jump). Only if packet doesn''t match any of rules in custom chain, processing continues with rule immediately below the jump rule. Which means that sometimes it's sensible to add a "catch all" rule at the end of custom chain (preferrably drop) if it's expected that any decission about packet entering the custom chain should be made inside this custom chain. Such "catch all" rule can save some processing efforts and can improve readability of rule set.

And then there's exception to rule about placing rules which potentially match most packets high: if there's a rule which matches subset of another rule and action is opposite, then the more specific rule has to be higher.

Example:
(The above is firewall filter example, but principles are the same for all firewall filter types)

I get the concept you are bringing up and it is obviously more complicated than just the quick example you shared.

However,

/ip firewall filter
add action=drop chain=forward in-interface=WAN protocol=tcp dst-port=80 dst-address=!<HTTP server for public access>

AND then

add action=accept chain=forward in-interface=WAN protocol=tcp dst-port=80

UNLESS there are no rules later that would drop packets that match "add action=accept chain=forward in-interface=WAN protocol=tcp dst-port=80 dst-address=<HTTP server for public access>" in which case the rule "add action=accept chain=forward in-interface=WAN protocol=tcp dst-port=80" wouldn't be necessary, right?

SO, an

add action=accept chain=forward in-interface=WAN protocol=tcp dst-port=80 disabled=no comment="This rule can be disabled IF there is not logic in this set of firewall rules to drop a packet that would match this rule as packets pass through the firewall. And, though it might be confusing this rule below the rule with a dst-address=!<HTTP server for public access> implies without stating that dst-address=<HTTP server for public access>."

INSTEAD of the potential

add action=accept chain=forward in-interface=WAN protocol=tcp dst-port=80 disabled=no

MIGHT be helpful.

Myself, I am contemplating documentation/comments procedures and frankly struggling with what I can and cannot do in these kinds of firewall rules and when and how to document/add comments when I left off programming with C++ and object-oriented programming. It's kind of like trying to go back to BASIC. I did see on this forum mention of extensions for Notepad++ that I haven't tried yet. That might help with visualizing these rules if I get it setup.

Personally I tend to avoid the ! matchers ... yes, they can be useful, but when one starts combining multiple "NOT" criteria, they are a bit counterintuitive and thus prone for errors. Or if one wants to have multiple rules with similar matchers, the only difference being the "NOT" criterion (the first one takes care of packets which are supposed to be dealt with by one of later rules).

And then there's a concept of "accept what's necessary, drop everything else" ... I think this is a very good approach. If one follows this approach, ideally there will only be two DROP rules: one near the top (drop invalid) and one as absolute last (drop all). Except where one wants to accept some connections but not a subset of those (as described in my previous post).

But this is only a personal preference.

Does this belong in a !General area?

"In most cases not significantly enough to warrant the loss of throughput by all the rules......... In other words throughput is directly affected by the number of firewall rules, so first things first, be LEAN."

Is that a straw man argument?

Does this belong in a !General area?

You want it moved to Beginner Basics ?

If a router system normally observes packets to a particular UCP port 443 that are accepted along with just a few that are dropped then firewall rules that have a drop at the end potentially even without a log might normally work well depending on requirements others may have I am not aware of. However, if that pattern changes and the router system observes more traffic than normal even passing a threshold that has in place an "analyzer router" that receives the same traffic as the production router but among other things accepts also, after each accept rule, a "not" rule appropriate based upon particular logic flows through the router systems firewall rules added, then I would have the data to potentially change the rules on my production router to enable a drop rule when dealing with a change in traffic.

For example.

Production:

#1101 add action=accept chain=forward in-interface=WAN protocol=udp dst-port=443 dst-address=<QUIC Server>
#1102 add action=drop chain=forward in-interface=WAN protocol=udp dst-port=443 disabled=yes log=yes

...

add action=drop chain=forward

Analyzer:

#1101 add action=accept chain=forward in-interface=WAN protocol=udp dst-port=443 dst-address=<QUIC Server>
#1102 add action=accept chain=forward in-interface=WAN protocol=udp dst-port=443 dst-address=!<QUIC Server>


That setup would allow me to gather real-time statistics from the analyzer in rule #1102 regarding packets that match and potentially exceed a set thresh that would be normally skipped in the production router with rule #1102 disabled on the production router.

Further, if the rules regarding accepting UDP port 443 were part of many other rules I could bump the set of rules for UDP port 443 above the others in situations where though I might not normally see any UDP port 443 traffic compared to other traffic the pattern of traffic changes.

Respectfully, though I understand that I do not understand the requirements of others regarding how many rules they need to handle the tasks they have, nor information about if they have excess rules that could be removed, I believe the ideas I am bringing up here are very much so real-world concepts many deal with even if they don't normally consider Mikrotik a viable option.

There are certain profoundly arrogant and rude people on this forum that I will not be further discussing this topic. If admins feel this post needs deleted or moved to a different category do what you think is best.

I'll just jump on a fragment:

Analyzer:

#1101 add action=accept chain=forward in-interface=WAN protocol=udp dst-port=443 dst-address=<QUIC Server>
#1102 add action=accept chain=forward in-interface=WAN protocol=udp dst-port=443 dst-address=!<QUIC Server>

The second rule is using a "not" matching property. Which is fine if one looks at rule without any context. But when one looks at both rules ... then setting the "dst-address" property on second rule is redundant. First rule accepts packets, destined at QUIC server. So they won't evaluate the second rule. Which means that only packets with dst-address set to anything other than QUIC server will hit the second rule. Which is nothing wrong (again).

But there are two potential problems with it:

1. since we're discussing "optimization" of firewall rules ... matching against another matcher rule will cost CPU cycles ... and it's waste of resources to match against a value which we know it will match 100% of times
2. if you change IP address of your QUIC server, you'll have to update two firewall rules instead of only one ... if you forget to change the second rule, it'll be effectively entirely different rule (just think about the possible scenarios)