I used today Action Jump to a Chain. I had to put an second Return just beneath the Jump line to not process also the rest of the lines, when the custom Chain was filtered.
Feature request is like as in Connection Marking an Router Marking, to add a box in Action to stop processing of the rest of the filter lines. You can then tick the box Passthrough and processing is ready for that whole page if filtering of the lines below the jump is not necessary.
Can you post an example, what didn’t work for you as expected, and how the second return saved it? Maybe I’m little slow right now (well, it’s quite late here), but I don’t understand the description.
add action=jump chain=prerouting jump-target=UDP-target protocol=udp
add action=return chain=prerouting log-prefix=UDP-target protocol=udp
.
.
add action=accept chain=UDP-target comment=WireShark/Winpap disabled=yes dst-address=192.168.88.99 dst-port=37008 protocol=udp
.
.
add action=return chain=UDP-target protocol=udp
The last return makes no difference if it is present or not, I think because it is the last line in the /IP firewall RAW
Well, what you should note is that while it is called “jump” it really does a “call”. When the jumped chain does a return, processing continues below the jump.
When you don’t want that, you can make sure the jumped chain does not return but rather ends in a terminating action (Accept, Drop, Reject). Then it will not
come back below the jump action.
Thanks pe1chl that was the solution to my problem to have an extra RETRUN needed to stop UDP traffic travelling on.
The traffic that was the most prominent was port 20561 so when I was using winbox in MAC config. 
This still leaves the request for adding the Passthrough checkbox active because it could be useful if you want a not a watertight filtering because that is done in filter pages after that. MASQ/NAT/Filtering
I’m not convinced.
Return on end of subchain is useless, because it’s already implicit action, it would happen anyway.
Return in top-level chain (prerouting, …) is equivalent to accept.
If you don’t want to return from subchain, just add accept/drop/reject as the last unconditional rule to subchain. And unlike your passthrough option, this gives you a choice, what should happen with packet.
That is right, this is how it works and it already has all capabilities. I normally end each subtable with a drop or accept rule so there
is no return, that is also more obvious for new admins as the “jump” name is counter to what really happens (“call”)
It’s obvious by itself:
>---other_chain--- oops, end of chain!
| |
jump fall down
| |
---main_chain---^ >---main_chain_continues---
Maybe it is because I did programming long ago in assembler, where JUMP typically means “go to a different address in the program” and CALL means “save the current
address on the stack, go to a different address, run the program there until you hit a RETURN instruction, which means get the address off te stack and go there”.
This CALL/RETURN is just like what the JUMP does in iptables (“call a subroutine”)
I think that I know the function of RETURN and to me it looked to have the same working of ACCEPT but that is not the case.
RETURN can be use to steer inside a JUMP and stop processing the rest of the sub-CHAIN.
.
JUMP to sub-CHAIN
.
RETURN specific match (further processing in MASQ/NAT/FILTER page) (same function here as ACCEPT)
.
sub-CHAIN
.
RETURN (return where the jump started and process the lines underneath the JUMP till reaching sub-CHAIN)
.
.
sub-CHAIN end - returns to the jump from which it was called
.
.
JUMP to sub-CHAIN
.
.
sub-CHAIN
.
ACCEPT specific match (does not return where the jump started and goes to MASQ/NAT/FILTER page)
.
.
sub-CHAIN end - returns to the jump from which it was called
I wrote above:
“ACCEPT specific match (does not return where the jump started and goes to MASQ/NAT/FILTER page)”
however after some more expediences it appears to be:
ACCEPT specific match (does not return where the jump started and goes NOT to MASQ/NAT/FILTER page)
Am I correct with this last experience?
The original wording seems correct to me.
The scope of validity of the ****
accept
is only a single pass through a single table. If the packet is accepted anywhere during that pass through that table (no matter whether in the pre-defined chain or any custom chain called from the pre-defined one, directly or indirectly), it then enters the pre-defined chain in the following table on its path through the system. So an
accept
of an incoming packet in
prerouting
chain of table
mangle
, or in any custom chain called from the
prerouting
one, does not mean that the packet would bypass handling by the
dstnat
chain of table
nat
. And accepting of an incoming packet in
dstnat
chain of table
nat
does not mean that it would bypass the
srcnat
chain of table
nat
after getting routed towards outside the Mikrotik.
drop
, quite logically, behaves different - if the packet is dropped at any stage of handling, it is dropped forever.
Let me remind you this picture.