The problem:
Filter table gets so polluted that on routers with lots of rules, it’s difficult to understand what’s being filtered and why sometimes. If you have dynamic rules, it makes it even more challenging.
On iptables, there’s a solution for this by creating additional chains, and then joining those chains to the input chain.
If RouterOS is already capable of this, how do we achieve it?
I’m at 90 rules on my one router and as much as I’d love to add more rules to it, I’m reluctant to simply for the reason that it will become more unusable and the chances of me having forgotten about some edge cases to account for because of the mess is quite high. If I could organize it, it would make it so much more manageable.
The particular use case where I have requirement for a lot of filter rules:
I have a master VPN server. That VPN server is used by my own company and a number of clients. I want my clients to be able to access all of their assets, but nothing else. I want myself and my techs to be able to access all of our assets, and all client assets. I have monitoring servers that also need to be able to access all client assets.
Sometimes I will need to put in additional masquerade rules so that the end customer doesn’t see subnets from outside their known world showing up in their logs as well.
Remember it is named “jump” but it is actually “call” (for those who know about programming).
So, indeed you can “return” to the place where the “jump” was done, and in fact this is what happens automatically when the jumped table just ends without a terminating action (drop, reject, accept).
This may be unexpected to new users. I normally make sure that any table that I “jump” to ends in a “add action=drop” just as I use at the end of the input and forward tables (I like to do a default-drop configuration where everything I want to allow as an “accept” and at the end of everything there is a “drop” or “reject” instead of the default “accept” that is in RouterOS).
