It will focus more on filter rules definition and ordering performance.
It was mentioned in the past that each rule affects the performance differently, depending on a matcher (selected conditions) of that rule. Most extreme example would be L7 matcher. Obviously 25 rules with L7 matcher will be much slower than 25 rules of src-address matching.
I could not find any information about how to "rank" rules by performance (besides the obvious L7 matcher). Question 1: Does anyone have a link to such a ranking ?
For instance, I'm wondering the following from a performance point of view, maybe you could share your experience:
- globally I have in my rules set 1) input chain rules 2) output chain rules, and finally 3) forward chain rules -> Question 2: Is this order important (i.e. would it change anything if I put input and output rules after forward ones) ?
- for readability reasons, I usually (except for some cases where grouping ports makes sense) have 1 port per rule for a target device/interface. I.e. for N ports I have N rules. Question 3: Does it have a real impact on performance versus having a single rule with "port1, port2, port3, ... portN" (if not rechecking the src or destination each time) ?
- I use "jump" rules based on "in interfaces" (i.e. if in. interface = "interface name" then jump to chain), Question 4: is there a performance difference doing it this way versus using src IP addresses with mask ?
Further here is my global "rules ordering strategy" (for the forward chain):
- fastrack connection
- allow established, related, untracked
- drop invalid
- if protocol = icmp then jump to ICMP chain (then I do not check again for the protocol in the following rules and last rule of the chain is a drop)
- if protocol = udp and port 123 allow traffic (ntp)
- for each in. interface <vlan_interface> jump to specific "vlan_name" chain (Then in each chain I do not check the input interface anymore, and only have rules checking the protocol/dst port/out interface, and finish the chain with a drop)
- drop all the rest
Logs are only done at "drop" time (I have very few "filter related" logs per day). Maximum number of filter rules (including the rules before the jump and the rules for the specific input vlan) is 19. Around ninety percent of the traffic is handled by the 2-3 first rules in each specific vlan chain (i.e. for legit traffic, rule number 7 up to 9 accepts the traffic, except for some specific chains which may need some more checks) and the vlan chains are ordered such as the ones which have most traffic are put on the top of the list. I also have "sub chains" for specific rules shared by multiple VLANs (for instance for printers, or to access to some shared services).
Question 5: Does this strategy sound "ok" to you ?
I know that one improvement I could do is to replace each "drop" at the end of each specific vlan chain by a "return" and move the jump to the ICMP chain and ntp rules just before the "drop all the rest" rule. This would "save" two matches for most of the non-fast-tracked as well as for non-icmp traffic, But I would lose from a readability perspective. This is why I'm not doing it.
Question 6: Would it be worth it to move these rules to the end in your experience/opinion ?
Thank you in advance !