Hi,
I would like to build up a firewall rule-set which is flexible enough for future implementations and changes on a RB3011 (e.g. VPN, Port Forwarding, etc.)
I have learned that it is smart to use "address-lists" and "customized chains" for specific exceptions (e.g. protocol related, deny DNS Requests from WAN, or ssh) I also red the manual https://wiki.mikrotik.com/wiki/Manual: ... all/Filter but I am a little bit confused about the correct order of the rules. I learned that the order runs from "permissive" to more and more "restrictive" rules with a "drop" at the end.

But what I do nor understand is, if this can be managed in "blocks" for "input", "Forward", "Output" and "Custom"- Chains, or if the rule-order has to be managed by restrictions..
If it can be managed in "Chain-Blocks" how is the best way to implement?
e.g.

• Input - rules
• Forward-rules
• Output rules
• Custom-rules

Christian

Typically one has input rules, then forward rules, and there is no such thing as custom rules.
They all fit into Input or Forward (output is used rarely or so it seems).
The use of JUMP and Mangle areimportant skill set to have if doing more complex setups, which I have not acquired.
Similarly the use of VLANs can be intimidating.........

The use of custom chains (not rules as mentioned) is VERY useful to separate traffic by function (ex. Web server farm, input traffic, VoIP, etc.). It makes management visually easier and helps with cpu and memory offloading by sending traffic to the right custom chain to be processed right away and not having to go through many rules for no reason. The use of a flat structure is not suggested unless you have a very simple firewall.

Order will depend on your traffic. Put rules that are "hit" often early on in the blocks. Also put basic management traffic early also (echo replies, DNS replies and so on).

A firewall structure should not be viewed as static, meaning that order may change as traffic changes.

Personally, I like to process extrrnal input traffic rapidly to drop attacks asap and to permit management traffic just as fast.

Also, when using the JUMP action, be as specific as possible (or as needed) with your matchers and don't repeat those matchers once in your custom chain as they are implied. You may want to add different matchers depending on your goals though.

Best regards,


Sent from Tapatalk

And one quick jump back to something more basic, input, forward and output have different purpose, each packet will go only in one of the three:

- input = packet coming to router itself, i.e. destination address is one of router's own ones
- forward = packet going through router
- output = packet sent by router, i.e. by process running on router, so not when it's going from one interface to another (that's forward)

So whether you have input before forward, other way around, or even if you mix rules from these different chains, it doesn't matter, do whatever you like best.

What does matter is order of rules within the same chain, because those are processed from first to last.

Hello,
many thanks for the reply. But there is a question left.
If I use the "jump" in a rule how is it processed. Is it like a subroutine and returns the process back to the point, where the "jump" was initiated

e.g. The "jump" is initiated in line2, line 4 - line 7 will be processed, but what happens then, will the process automatically jump back to line 3?)

Regards,
Christian

If there's matching rule in ssh-in, processing ends there. In your case, #7 will match anything, so it will never return to original chain. If you didn't have #7 and nothing matched in ssh-in, it would return back to input and would be dropped by #3.

If there's matching rule in ssh-in, processing ends there. In your case, #7 will match anything, so it will never return to original chain. If you didn't have #7 and nothing matched in ssh-in, it would return back to input and would be dropped by #3.

Are you sure about that? In the wiki it says:

When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action). If a packet has not matched any rule within the built-in chain, then it is accepted.

Yes, input is built-in chain (with implicit accept at the end), but ssh-in isn't, so if nothing matches there, it returns back to original chain and continues after the jump.

So if I can be permitted to Squeeze Sob ;-P,

Then you are both saying the same thing. If no rules are matched in the SSH chain it is accepted, to the next rule after the initial JUMP rule in firewall filter list.
In other words, the packet was not needed after all, in the jump chain, and should go back and be processed like the rest of the packets in the normal list.

The firewall rules are implicitly accept and thus why I like the drop everything at the end of input and forward.

Hi all,
thank you so much for support.
Let me summarize in oder to check, if I understood correctly:

• the order of input-, forward-, output- and "jump-in"-chain doesn't matter, because a package can only pass one of the chains.
• if there's matching rule within a chain, processing ends there and the rest of the chain will be ignored for the specific package
• if nothing is matching in the "jump-in"-chain, rule-processing will be continued after the initial jump-command in the specific chain.
• for completeness, there should be a "drop everything" at the end of each chain

Please correct me, if I am wrong,
Regards,
Christian

So if I can be permitted to Squeeze Sob ;-P,

Then you are both saying the same thing. If no rules are matched in the SSH chain it is accepted, to the next rule after the initial JUMP rule in firewall filter list.
In other words, the packet was not needed after all, in the jump chain, and should go back and be processed like the rest of the packets in the normal list.

The firewall rules are implicitly accept and thus why I like the drop everything at the end of input and forward.

No, Sob is correct. "Accept" means something very specific. It means that a packet continues into the next stage of packet processing, outside of Filter stage and its chains.

I misread that Wiki sentence because I was not careful enough to note it specifically refers to "built-in" chain.

I may still retain an explicit Return in custom chains in my configurations where it makes sense to use it, but clearly it is not required at the end of a custom chain block ever.