I’m migrating from Ubiquity Edgerouters to Mikrotik CCR.
On the Edgerouters I can define port lists for the firewall. In RouterOS I need to specify the ports on each rule. This is less maintainable.
I know it’s been asked before, the last time I was able to find was in 2016. So I thought I’d refresh the ask.
Can we have port lists in the RouterOS firewall, that work for both IPv4 and IPv6? It would really make life much easier.
Thanks for your help, but I was referring to TCP and UDP ports, not interface ports.
In the firewall rules I need to enter 25, 465, 587 in Mikrotik where in the Edgerouter I could enter Mail_Ports. When Mail_Ports changes, all related firewall rules are updated, instead of having to adjust each rule individually.
It's a feature I've always looked for over the years because it's undoubtedly very useful, but until now it's remained on the wish list. Did you request the feature by email to support@mikrotik.com?
That funcionality would be nice. We have been waiting for it for years.
Same protocol ports can be separated with commas in FW rules.
Not yet, but I will. Thanks for the pointer.
It’s also called “aliases” generally in the pf* world. And yeah, it wouldn’t be a bad feature.
In the iptables world that MT exposes, the usual way to avoid having to repeat port numbers is via the custom chain/jump/return mechanism. I don’t know what your exact situation is, but proper use of this feature eliminates the need for such repetition.
If you’re willing to post relevant snippets of your rules, I’m happy to take a look at how they could be refactored.
The feature in the underlying Linux system that RouterOS uses for “address lists” is “ipset”, and it offers some more capabilities than address lists do in RouterOS.
Not only “ports lists” but also “lists containing other lists”, “list of MAC addresses”, and some types of combinations of these.
However, early in RouterOS v6 the decision was made that a list does not have to be created before adding the first item, which now makes it more difficult to add new types. Back then, creation of items like a list or a routing mark or a routing table etc was done completely behind-the-scenes. I guess that now keeps them from just adding new features, as it requires conversion and that often leads to issues with some configurations, as we have seen when routing tables were required to be created first before being used.
But you can’t argue that it would be in any sort of widespread use. I think what OP meant was more along the lines of syntactic sugar. (That would of course have the current limit of (I think) 16 values/ranges per rule.)
Maybe port lists could be added from ipset directly, however I’m not sure of the utility. Address/port hashes I think have very low utility.
Indeed there could be some use for “port lists” but I agree that in general the fact that you can add your own chain and call it from another one is more versatile and it allows more than just a port list could do, e.g. for DNS you can allow port 53 both for UDP and TCP.
I use those user-defined chains a lot. They allow you to group relevant stuff together and it is also more efficient. E.g. for “new” packets coming from some interface “jump” to a chain with handles the allowed traffic from that interface.
(“jump” should actually have been named “call”, as it allows a “return” back to the calling chain. but that naming comes from iptables)
However, I absolutely agree that hierarchical address lists would be really nice and I desperately miss them.
I agree that the new way of declaring things before use, as exemplified by interface lists and routing tables, is the way to go.
Implementing hierarchical address lists would not go afoul of the current system. (As I would image the internal implementation - maybe erroneously - is that everything mentioned anywhere is implicitly created.) It would however require one more overloading of the address parameter for items: it could no longer contain an ip address or a dns fqdn, but another address list as well. I think the different types for this parameter should be disambiguated anyway.
Do you think it’s worthwhile to file a feature request? Has it already been done? Am I deluded in my thinking?
I have seen requests for “lists of lists” and I have use for them, but it is not high priority.
Similarly I would like to see “groups of connection/packet marks” where you can have multiple marks on a single connection or packet. The underlying Linux feature allows it, as packet mark is a 32-bit value which can be AND/OR masked. There could be a global setting of “all packet marks in one group” which would mean max 32 packet marks in total and each one could be set/reset independently, or e.g. 4 groups of each max 255 packet marks that could be independently set on a packet.
While we are throwing out suggestions I would like also ability to select multiple address lists from single firewall rule.
That is covered by the “list of lists” feature. You can then define a list that has other lists as members, and use that in a firewall rule to include all those lists in a single rule.
What, never heard of this, i cant find anything like that in winbox or any info or net, am i that blind?
EDIT:
If you mean like this ?Because this doesnt work .
/ip firewall address-list
add address=1.1.1.1 disabled=no dynamic=no list=test1
add address=8.8.8.8 disabled=no dynamic=no list=test2
add address=test1 disabled=no dynamic=no list=testCombined
add address=test2 disabled=no dynamic=no list=testCombined
More generically a "port list" is really it exposing /etc/services in UI, which be useful in other contexts like logs to show port names. And on the specific in firewall, being able to dropdown known ports (with override) like the IP protocol be handy.
And, 
more "lists of lists".
Thanks for the suggestion and the offer. I figured out how to use the custom chains. and have the IPv4 implementation done. Next IPv6.
Glad it worked out, even if we side tracked the thread.
