Hi,
Is there a way to create a new filter protocol “tcp_udp” to avoid having on double rule for tcp and the same for udp immediatly after ?
Exemple : dns, nfs, https (quic is udp)… and maybe others for windows i don’t remember
4 Likes
Or just when port without protocol is set it could be applied for tcp and udp.
1 Like
+1
I run into this one for DNS, & it always seems dumb that you need two rules. Now IMO, given RouterOS config scheme, it might be better if protocol allowed multiple selections, vs. using a "pseudo-protocol" like tcp_udp in the one list.
4 Likes
@optio seems the most suitable one in my opinion, since it feels natural with the rest of the arguments of a firewall rule. Packets where no ports exists will simply be discarded.
I honetsly wonder why this hasn’t been done before.
Not all protocols use ports be my only slight concern.
But it's just always allowing *-port= to always be configured - as it's non-configurable today unless TCP or UDP are explicitly provided. So if inferred that for any "port-based IP protocols" to use the -port= filters for the one that do that be okay IMO too. I'm just not a fan of some "fake" protocol in the protocol= list.
@Amm0 Protocols not using ports don’t match the source or destination port rules, hence skipped for the rule, which I think makes total sense
1 Like
2 problems :
- not possible to create a rule without protocol AND dst/src port
- how to only handle tcp/udp and not any others like ddcp, udp-lite…
- It’s not possible now, but that’s exactly what we propose, that it starts being possible.
- This is the multiple selection that @Amm0 proposes. Neither his suggestion or ours (@optio and mine) are exclusive, both coexist and allow greater flexibility.
If I want to handle DNS (like the example provided by Amm0, although it goes through TCP/UDP by standard, what if there is some non-standard implementation going through udp-lite, for instance? (of course we are assuming here that DNS always goes through 53, which it’s not an universal truth either).
I might not care and indeed would like to cover all protocols anyway
Protocols not using ports don’t match the source or destination port rules
Correct, but it's a feature request. And my point was it could in future.
The secondary point was some fake "tcp_udp" protocol is not the right implementation, IMO. But agree "some solution" be nice.
Easy: because RouterOS is based on Linux, and the underlying mechanism in Linux does not support it.
So having this would require a kernel modification, something you want to avoid because every kernel modification makes it more difficult to upgrade to a newer kernel version in the future.
It doesn't need modifications if such rule from ROS config will be applied as aggregate rule, 2 rules with same params but different protocols. Ufw has simmilar thing - ufw allow 53 applies ufw allow 53/tcp and ufw allow 53/udp.
It has been discussed before to have “protocol specific handling” in the firewall.
When you want that, look at the possibilities of custom chains (you can add new chains with user-defined name in addition to the forward/input/output chains) and the “jump” and “return” actions.
Yes but then you have many rules to configure, I was aiming simple solution having from ROS config side where is single rule and ROS will apply rules to kernel side for both protocols, tricky thing for ROS side will be to aggregate representation counters for such rule from both applied kernel rules.
When you are lazy, RouterOS is not for you!
There are plenty of other devices where you can tick simple boxes and have it all done automatically for you. You already mentioned ufw yourself.
Really I think it is not worth it, and not worth the possible confusion, mistakes, inconsistencies, etc.
Not lazy, practical 
yes, for pratical but for avoid having multiple rules in double each time….
The same beahvior is available for dst/src list addrs…. why not multivalued !?
I wrote before: because Linux does not support it.
Multiple addresses and multiple ports are supported by the system (ipset for addresses) but multiple protocols are not, and require surrogate solutions like “I enter 1 rule but silently 2 rules are made”.
When you are in a “I do need to do that every time” situation, use custom chains.
As soon as one enters this area, the chance of having async between "configured config" and "actual config" becomes notable.
As long as there's a bijective transformation between UI commands and underlying systems (e.g. kernel netfilter), it is possible to re-construct UI commands from actual config. When one starts with "one to multiple" transformations, it's not clear any more whether those two actually running items (e.g. in netfilter) were constructed by two separate UI commands or by single command. Yes, it is possible to map "multiples" back to the "single", but it becomes complex and thus prone to bugs. And benefits are, as already noted by others, questionable at best.
So currently all (not just ip filter) ROS config rules are now 1:1 with underlying system, no one rule → many actions? I doubt it.
When I used zywall firewalls, I seem to recall one could setup a rule that covered both protocols, I cannot remember how, been a while. They have a box entry called service, and that where you enter PING, or whatever, but they also had service groups, and in this case is where one combined both service dns udp and service dns tcp. It made sense then and makes sense now.
Two approaches, allow one to somehow stitch the two together: operator choice,
or hardwire it so that both are always included for DNS. So being a non-techie, is there any case where one would NOT want to have both protocols in play?? If not, then hardwired makes the best option