Firewall filter: Is the return rule really necessary?

RouterOS General
1

I am currenty configuring my RB3011UiAS-RM (v. 6.42.5) - especially the firewall. While doing so I am checking whether or not I need to add a return-rule to custom chains so that the order of rules being processed is as expected.
With the following ruleset I would have expected that rule no. 5 would not be checked because of the jump-rules and their order. The only matching rule in my expectation is rule no. 3.

The logged traffic looks as follows:

input: in:e2-intern out:(unknown 0), src-mac xx:xx:xx:xx:xx:xx, proto TCP (SYN), 10.10.0.250:40014->10.10.0.253:80, len 60

I have the following address lists:

/ip firewall address-list
add address=172.16.0.0/30 list=net_sync
add address=10.10.0.0/24 list=net_intern

The firewall rules look as follows (I removed the comments of the rules in favor of readability):

/ip firewall filter
add action=jump chain=input jump-target=input_basic
add action=jump chain=input connection-state=new in-interface=sfp1-sync jump-target=input_sync
add action=jump chain=input in-interface=e2-intern jump-target=input_administration log=yes protocol=tcp src-address-list=net_intern
add action=drop chain=input_basic connection-state=invalid
add action=accept chain=input dst-port=80 protocol=tcp
add action=accept chain=input_basic connection-state=established,related
add action=accept chain=input_sync connection-state=new dst-port=22 in-interface=sfp1-sync protocol=tcp
add action=accept chain=input_administration connection-state=new dst-port=22 in-interface=e2-intern protocol=tcp src-address-list=net_intern
add action=accept chain=input_administration connection-state=new dst-port=8291 in-interface=e2-intern protocol=tcp src-address-list=net_intern
add action=return chain=input_administration disabled=yes

So rule no. 3 does match and should - in my opinion - jump to rule no. 8 which would lead to the end of the ruleset. The return rule (rule no. 10) is disabled.
Nevertheless rule no. 5 has passing traffic and both bytes and packets increase when checked with a simple curl statement.
Is using the return rule now necessary or not - or when should it be used?

curl http://10.10.0.253

Please keep in mind that I am aware that this is not a restrictive firewall at all - it is work in progress :wink:

2

The point is that despite its name, action=jump is actually action=call. So the processing continues by the first rule of the custom chain given as jump-target, but when the last rule in the custom chain has been evaluated and didn’t yield a final decision (accept or drop), the evaluation returns to the calling chain and continues by the rule following the action=jump one. So an action=return rule as the last one of a custom chain has no effect; a matching action=return rule in the middle of the custom chain causes the rest of that chain to be skipped.

3

@sindy
Thank you for the detailed explanation! That makes sense now.