<=> thus performance is only affected by “number of filters that traffic was tested against before matched”?
<=> thus any amount of filters that are virtually unreachable for traffic (matched before) will not affect performance (as long as there is enough memory they will be occupying while rotting ) (?)
question from original post - how exhausting is jumping without reason?
In many cases its the rules that are inefficient, for example just make a firewall address list of all those individual addresses and then its one forward chain rule.
Yup, got your rule of thumb “when to use address lists” hanging framed above my imaginary desk
I’ve used somewhat unfortunate example, but it’s just to visualise the point - pinpointing the actual moment in filter’s lifespan when it affects performance.
Does having a filter listed already affect performance, or only the moment when traffic hits it to be tested/matched against?
And what about passthrough filters?
Rules are matched in order. Each matching costs CPU resources (some are probably cheaper than others, perhaps matching against address list is more expensive than against a single address, but cheaper than multiple matching against single address). Which is the reason to put rules, which match most packets, higher on the list (keeping the order so that security is not compromised).
Creating separate chains can help to reduce average number of rules tried for a packet so this can actually speed up firewall. But matching against “jump” rule costs as well, so one has to make some compromises.
Regarding those “25 filter rules”: only knows exact setup used for tests. It could be that there are exactly 25 filter rules, none matching (so only the matching performance affects test results). But anyway, I’d say that you can assume “average number of rules matched against” and actual packet processing delay will depend on number of matchings performed before a rule is executed.
I’m on the other hand all about theory in this case - once I’m happy with understanding basics I promise to F something up and bring it to you for help
it would actually help to first match src-address=10.0.0.10 and jump to custom “destination chain” (added ports for @anav not to say to go for address-list )
add action=jump to-target=destinations_xyz src-address=10.0.0.10 in-interface-list=trusted out-interface-list=!WAN
add action=accept chain=destinations_xyz dst-port=123 dst-address=10.0.20.31
add action=accept chain=destinations_xyz dst-port=1234 dst-address=10.0.20.34
add action=accept chain=destinations_xyz dst-port=22 dst-address=10.0.111.123
add action=accept chain=destinations_xyz dst-port=9876 dst-address=10.0.123.145
# and so on...
# drop all or return to forward
And passthrough would be as resource hungry as any filter as long as it needs matching…
so summarising:
Not number of filters themselves would account for resource hunger, but their “weight” - amount of parameters to check inside each
Personally I use a number of jumps to some other chain. For example I have four Raspberry Pis that each can be accessed via VNC (with various security). From the Internet each is accessed via a different port. So I have a rule that matches the four ports and jumps to the “VNC” chain where all the other assorted security takes place. So for traffic that is NOT going to VNC on one of the RasPis, the ports do not match so those packets do not match the rule and therefore do not make the jump and skip all the other security rules that apply only to VNC packets.
) (?)