HowTo: Optimising MikroTik Firewall rules

When creating complex firewall rules on MikroTik routers, especially those with high levels of packet throughput, it is important that any rules are processed in an efficient manner. Firewall rules are processed top down. Every new packet is tested against each rule until a match is found. For high packet count traffic, this could mean that all those packets are having to be processed many times before it is matched. This can require a higher processing power than necessary and if the CPU reaches 100%, packet loss will occur.

Naturally, if no firewalling is required at all, using the features of ‘fast-path’ will ensure the packets are forwarded to the correct interface at near wire speed and will avoid being processed by the CPU at all.

But if some firewall rules are required, then there is a basic rule of thumb that the most popular, most frequently matched rules should be higher in the list, compared to the lesser matched rules. In this way, highly popular traffic types will be matched early and reduce CPU usage as it will be matched sooner, rather than later.

This is why it is wise to create a rule to match for ‘established and related’ packets and place it at the top of the list. Most packets belonging to an already tested connection will have already had it’s first packet tested against some very specific match parameter and subsequently ‘accepted’ therefore will have a connection type of established (as a result of the connection tracking engine) and therefore if already tested and accepted, all remaining packets of that connection can go into the ‘established and related’ rule. The more complex and specific testing rule (further down the list) now only needs to test the first packet of a connection.

Also, when creating rules, some matching processes performed on a packet will take more CPU than another. Deep Packet Inspection using a Layer7 rule will clearly take up more CPU power than testing against a source/destination interface, but here is a list published by MikroTik that shows the order of how the match parameters take up CPU time to process ordered from least intensive to most intensive:

1 – In Interface
2 – Out Interface
3 – Protocol
4 – fragment
5 – src-mac-address
6 – in-bridge-port
7 – out-bridge-port
8 – src-address
9 – dat-address
10 – src-address-type
11 – dat-address-type
12 – dst-address-list
13 – src-address-list
14 – ttl
15 – dscp
16 – packet-size
17 – ipv4-options
18 – dst-port
19 – src-port
20 – port
21 – tcp-flags
22 – tcp-mss
23 – icmp-options
24 – ingress-priority
25 – priority
26 – packet-mark
27 – routing-mark
28 – hotspot
29 – connection-mark
30 – connection-state
31 – connection-bytes
32 – connection-limit
33 – connection-rate
34 – connection-type
35 – random
36 – psd
37 – nth
38 – limit
39 – dst-limit
40 – per-connection-classifier
41 – p2p
42 – content
43 – layer7-protocol