feature request: add Port List to firewall

lbgaus · Wed Jul 27, 2016 3:31 pm

Hello, I would like to request a new feature... Just like in the firewall where you can make groups of addresses with the Address Lists option, it would be great if you could make port groupings with different types of ports (tcp, udp, etc...) in the firewall with a list. This would reduce the number of rules needing to be created. Thanks!

Wed Jul 27, 2016 7:12 pm

I agree - the ipset functionality of the netfilter suite (which I'm assuming is what Mikrotik uses to implement their firewall) already supports port lists, so it shouldn't be a huge endeavor to implement this - especially now that they've also implemented interface lists.

Paternot · Wed Jul 27, 2016 7:30 pm

Most useful, indeed.

Cha0s · Fri Jul 29, 2016 2:15 am

Fri Jul 29, 2016 8:25 am

Wasn't it already requested in the past?
http://forum.mikrotik.com/viewtopic.php?f=1&t=110552
http://forum.mikrotik.com/viewtopic.php ... 88#p535688

I am for this too.

OKNET · Fri Jul 29, 2016 11:01 am

Yes, me too http://forum.mikrotik.com/viewtopic.php ... 1fa1a908bd
Hope to see it soon....

efaden · Fri Jul 29, 2016 12:01 pm

Yep.

Sent from my XT1575 using Tapatalk

Fraction · Fri Jul 29, 2016 4:48 pm

+1 for the ability to use multiple protocols & ports in one filter rule.

pe1chl · Fri Jul 29, 2016 6:29 pm

+1 for the ability to use multiple protocols & ports in one filter rule.

- multiple protocols: this makes no real sense, and netfilter doesn't support it anyway
- multiple ports: this is already possible, only you need to specify it inside the rule, not as a separate "port list".

Cha0s · Fri Jul 29, 2016 7:14 pm

- multiple ports: this is already possible, only you need to specify it inside the rule, not as a separate "port list".

Yes, but if you have multiple rules using the same port range/list, currently you have to manually edit each rule (or run some cli magic to do it) if you want to change 1 port for example.

Having a port-list like adress-lists or interface-lists, you simply edit the port-list and all rules follow that without any further edits.

pe1chl · Fri Jul 29, 2016 7:37 pm

I think multiple rules with the same port-list should not be very common, and also they can often be replaced
by using custom chains. Matching should be done as little as possible, especially on complicated criteria.

Fraction · Fri Jul 29, 2016 10:01 pm

- multiple protocols: this makes no real sense, and netfilter doesn't support it anyway

Its not so uncommon that applications uses both, udp- and tcp-ports and also icmp is used in quite strange places.

-multiple ports: this is already possible, only you need to specify it inside the rule, not as a separate "port list".

Yes I know, and therefore that protocol mixing is more important new feature for me personally, but I can also see clear benefits of doing some kind of "service objects" (all ports needed by application/service X) and use them in multiple rules.

pe1chl · Fri Jul 29, 2016 10:29 pm

- multiple protocols: this makes no real sense, and netfilter doesn't support it anyway
Its not so uncommon that applications needs both, udp- and tcp-ports and also icmp is used in quite strange places.
And if you want to do strict rule for encrypted EoIP-tunnel, you need 3 rules at minimum:
-one for IKE/ISAKMP (udp/500 & udp/4500 for NAT-T if needed)
-one for ESP (ip/50)
-one for GRE (ip/47)
For me it makes a lot sense to do this with one rule.

Netfilter (the mechanism below what you see in Firewall) cannot do that!
There is a part "ipset", also mentioned above, that can store a portlist, actually just a bitmap corresponding to port 0..65535
for use in filters with protocol TCP or UDP. Not a list of protocol/port combinations, or even protocols without ports.
There would be some use of a portlist when there really are a lot of applications that require both TCP and UDP portlists
with the same portnumbers, but I think these generally are the result of laziness or misinformation. One of the few applications
that require this is DNS. And it uses only a single port, hardly worth it to store it in a set.
To implement what you suggest above, RouterOS would have to make a 1:many mapping of "high-level rules" in the UI
and real netfilter rules. I think it now never does that, and I am not sure it is a good idea to introduce that. Maybe some
shortcut in the UI that auto-inserts some predefined rulesets like the above, but that would then be further maintained
as separate rules just as it is now.

Fraction · Sat Jul 30, 2016 1:34 am

- multiple protocols: this makes no real sense, and netfilter doesn't support it anyway
Its not so uncommon that applications needs both, udp- and tcp-ports and also icmp is used in quite strange places.
And if you want to do strict rule for encrypted EoIP-tunnel, you need 3 rules at minimum:
-one for IKE/ISAKMP (udp/500 & udp/4500 for NAT-T if needed)
-one for ESP (ip/50)
-one for GRE (ip/47)
For me it makes a lot sense to do this with one rule.
Netfilter (the mechanism below what you see in Firewall) cannot do that!
There is a part "ipset", also mentioned above, that can store a portlist, actually just a bitmap corresponding to port 0..65535
for use in filters with protocol TCP or UDP. Not a list of protocol/port combinations, or even protocols without ports.
There would be some use of a portlist when there really are a lot of applications that require both TCP and UDP portlists
with the same portnumbers, but I think these generally are the result of laziness or misinformation. One of the few applications
that require this is DNS. And it uses only a single port, hardly worth it to store it in a set.
To implement what you suggest above, RouterOS would have to make a 1:many mapping of "high-level rules" in the UI
and real netfilter rules. I think it now never does that, and I am not sure it is a good idea to introduce that. Maybe some
shortcut in the UI that auto-inserts some predefined rulesets like the above, but that would then be further maintained
as separate rules just as it is now.

I understand that. If the port list in Netfilter works that way, then I agree with you, no real use for that. Does not change the fact that it would be useful feature in many situations and done by many other vendors. Just one more evidence that RouterOS is more router than firewall.

Zorro · Sat Jul 30, 2016 3:50 am

router IS firewall and vice versa.
and decent router - insecure and useless/dangerous w/o decent firewall and decent firewall ~ useless w/o routing.

Fraction · Sat Jul 30, 2016 4:33 pm

router IS firewall and vice versa.
and decent router - insecure and useless/dangerous w/o decent firewall and decent firewall ~ useless w/o routing.

There is a lot of places where you have router doing just routing and firewall doing just filtering and optionally NAT:ting (of course with default route pointing to that router). Internet is of course one example, but also internal networks in many big companies.
Anyhow, I was just trying to say that I have seen more intuitive UI:s for firewall management than in RouterOS. And ability to group things like ports & protocols is one of the key elements.

pe1chl · Sat Jul 30, 2016 7:38 pm

Oh but I have also seen commercial enterprise routers that are a lot worse in configuration, including putting comments
in configuration and structuring filtering rules in a sensible way... (e.g. Cisco IOS)
MikroTik has a comment field in almost every config item and it allows a tree structured filtering chain instead of a plain list.

Zorro · Mon Aug 01, 2016 9:52 pm

router IS firewall and vice versa.
and decent router - insecure and useless/dangerous w/o decent firewall and decent firewall ~ useless w/o routing.
There is a lot of places where you have router doing just routing and firewall doing just filtering and optionally NAT:ting (of course with default route pointing to that router). Internet is of course one example, but also internal networks in many big companies.
Anyhow, I was just trying to say that I have seen more intuitive UI:s for firewall management than in RouterOS. And ability to group things like ports & protocols is one of the key elements.

nowwhere you can legally anymore in last 10 years atleast ever in backbone completely separate firewalls and routers from each others. and generally you wouldn't want if you feel okay.
personally i proposed port-lists ~8 years ago in that forum and twice later(one last in present, non -deactivated nickname AFAIK), cuz its make sense and make configuration more readable/simpler and improve router performance aswell and same about protocols lists and interfaces lists.
as for "structured list" its more like nftables feature eg for ROS7 or even bit more later subversions(some may remember say PF and NPF and alikes, but thats not matter much).

kujo · Tue Aug 02, 2016 12:37 am

Cool. Make port-list, list in list also good ))
P.S. in prerouting mangle mark dscp (63-groups/portlist) and manipulate packets in filter on dscp based rules. Portlist by routeros(We are not looking for easy ways)

Have a good day!

pavelkolchanov · Tue Aug 30, 2016 12:03 pm

It would be useful to add ip:port address lists. We have blocklists of proxies and anonymizers and using separate filter rules for every record (aprox ~12k rules and increased every week).

pe1chl · Tue Aug 30, 2016 2:43 pm

When you have a proxy blocklist it normally is not required to have portnumber information, you can just block
all access to that address, and it is already possible to do that with an address list. You can also write a rule
that blocks access for TCP and a list of ports (e.g. 80,443,3128,8080) to the members of that address list, and
leave everything else open.
Again, there is no functionality for storing lists of ip:port in the underlying OS so this kind of feature request
is not straightforward to implement.

pavelkolchanov · Wed Aug 31, 2016 12:56 pm

you can just block all access to that address

Yes, I can, but the regulator requires to block concrete address and port.

pe1chl · Wed Aug 31, 2016 2:22 pm

When you want to abide to what your regulator asks and want to gain performance in your router, you can
make a 2-step block: in the forward rule put a match on address list that does a jump to a new chain "blockedproxies"
where you put all the addresses with portnumber(s) and a block on each of them, and end that chain with a return.

Of course to make this practical you need to make a script for add/remove ip:port which puts the IP in the
address list and the ip:port in the blockedproxies chain at the same time. (and similar for remove)

This way your router does not have to validate 12k rules for every new connection (I presume you have accept established/related
at the top anyway).

Remember, IF MikroTik would implement this request, their only option is to do it in a similar way, maybe without
the user seeing what is exactly happening. (as they do in other parts of the router as well)

Zorro · Fri Sep 02, 2016 11:06 am

When you want to abide to what your regulator asks and want to gain performance in your router, you can
make a 2-step block: in the forward rule put a match on address list that does a jump to a new chain "blockedproxies"
where you put all the addresses with portnumber(s) and a block on each of them, and end that chain with a return.

Of course to make this practical you need to make a script for add/remove ip:port which puts the IP in the
address list and the ip:port in the blockedproxies chain at the same time. (and similar for remove)

This way your router does not have to validate 12k rules for every new connection (I presume you have accept established/related
at the top anyway).

Remember, IF MikroTik would implement this request, their only option is to do it in a similar way, maybe without
the user seeing what is exactly happening. (as they do in other parts of the router as well)

with such requirements - border usage of somethng like CCR was relevant and they had more than adequate horserower to do it.
MIPS32(and even worserr SMIPS) SoC used in less expensive routers - aren't much, because very-very tiny L1, L2 caches - easily thrashed/saturated with and memory controller in - not perfect yet, too. but new ARM chips - look quite promising, i mean A35 and A32 cores. fk cold, small and VERY fast(its had bigger gain from than say A12/A17 to A32 than transitionfrom R4.12 to R5.0 of 32-bit MIPS-BE ISA). PPC chips on Power8/Power9 arch remain neat and had similar advantages, but both they and mips64(and superscalar 32-bit versions of of)recent forks - simply fail to gain chipmakers attentions, so they basically turned back to them and shifed to ARM in 90% cases.
my point is: its about time to stop being problem. very near time i mean. since asus and netgear, alpha, belkin and other taiwan SOHO brands - start moving from 2-core A9 SoC to 4xcore A17 and then proposed design of A32 SoC for "ought to be next"(no A35 chips on horison, yet, except one was targeted for automotive application(had built-in all-band RX and telemetry TX

.

mohkamdin · Fri Mar 09, 2018 11:49 pm

is this still in the feature request queue ?

MayestroPW · Thu Jun 21, 2018 1:10 pm

+1
I hope we will get it someday, with an option to specify multiple protocols, or at least TCP and UDP, so we will not have to make two rules for services like DNS which are using TCP/54 and UDP/54.
And it would be great to have the ability to specify multiple port lists in Filter Rule.

pe1chl · Thu Jun 21, 2018 3:06 pm

When you consider that a useful feature and cannot remember port numbers for services you can add custom chains like this:

/ip firewall filter
add action=accept chain=dns dst-port=53 protocol=udp
add action=accept chain=dns dst-port=53 protocol=tcp
add action=return chain=dns

Then wherever you like to "allow dns" (in input, forward, and with any other specifier you like, you can do:

/ip firewall filter
add action=jump jump-target=dns ....

This will implement the "recognize services in the firewall" feature, in this case for the "dns" service but it can be done for any service.
This is much more flexible than "port list". You can make a library of services (like the first paragraph) and load those in all your routers.

Cha0s · Thu Jun 21, 2018 3:52 pm

is this still in the feature request queue ?

There is no "feature request queue".
We just ask for stuff here, and MikroTik usually just implements stuff that nobody asked or cares about (eg: Kids Control, Detect Internet, etc).

Thu Jun 21, 2018 6:23 pm

That's how it works. We can just take it or leave it.

Milkthief · Mon Jun 25, 2018 12:29 pm

+1 by me!

pe1chl · Mon Jun 25, 2018 1:44 pm

+1 by me!

Implementation using currently available features and reason why this would not bring much was already given above.

Milkthief · Mon Jun 25, 2018 1:58 pm

+1 by me!
Implementation using currently available features and reason why this would not bring much was already given above.

If you refer to the "jump" method, it is your point of view, not the equivalent solution.

In example, I prefer to have all in order with lists.

TarikMikrotik · Tue Jun 26, 2018 11:54 pm

+1 from me.

lbgaus · Thu Jun 28, 2018 9:05 am

+1 by me!
Implementation using currently available features and reason why this would not bring much was already given above.
If you refer to the "jump" method, it is your point of view, not the equivalent solution.
In example, I prefer to have all in order with lists.

The reason I thought to request this feature two years ago was because I already am making great use of "jump" rules to make the CPU usage lower while having a complex mangle ruleset. My rules deal with tunneling certain types of traffic to a network inside the tunnel and other types of traffic to that same network outside the tunnel. I do not wish to add more jump rules when a port list would let me remove rules.

The complexities of if/how to make the underlying operating system deal with port lists are the only wildcard to me, and the reason for me to ask for help from Mikrotik, I would be able to greatly reduce the number of rules I have to look at in WinBox if this "port list" feature were implemented (currently 57 mangle rules I have to match and mark various traffic). Reducing the number of rules is desirable to me even if I was keeping the same processor load as I am having now.

pe1chl · Thu Jun 28, 2018 10:24 am

The kernel and the "ipset" command used to manage the lists in Linux did not have the requested functionality in the version running inside RouterOS.
However, I see that this functionality has been added in a later version!

That likely means your only hope of seeing this in RouterOS is in the mythical "v7".
For your application: I presume you already know that a list of ports inside a single rule is already supported, something like 21-23,80,443

Icceman · Sat Dec 14, 2019 10:01 pm

I agree. In order not to view al the open ports just in one place, would be very useful. I am opening ports now that I might change in the future, it would be useful to havd them all listed together.

olivier2831 · Mon Dec 20, 2021 3:56 pm

I agree. In order not to view al the open ports just in one place, would be very useful. I am opening ports now that I might change in the future, it would be useful to havd them all listed together.

I don't think I currently need to reuse a Port List several times in the same config but I would sure appreciate to be able to edit a long port list (40 items as I need to forbid some P2P ports).
If I'm not mistaken, current 6.48.6 implementation limits each list to include 15 members where 10001-10005 count as 5 ports, so I needed to to split my target list in 3 different firewall rules.
At the same time, current WebFig implementation also uses a small field and can't read a 15 members list without using external tools or workarounds.

+1 for a Port List tab in Firewall
or if not possible: +1 for 64 ports limit (increase from 15)
or if not possible: a large edit field in both Src or Dst Port fields.

anav · Mon Dec 20, 2021 6:41 pm

The jump variation is a nice use of jump rule, but I have to side with the +1 crowd on this one seeing as the functionality is now avail in the kernel being used.
The question is how important is it compared to bug fixes, and other enhancements being requested.
It seems the MT team has their hands full getting Vers 7 completed which will not likely happen until 7.5 ish most likely.
So unless its low hanging fruit enhancements will have to wait. Bugs, completing ROS 7 functionality, key enhancements available due to kernal change and worth $$$$ to 'important' clients, very good enhancements, and finally "nice to have" enhancements. My guess is that this one falls into the latter category.

olivier2831 · Mon Dec 20, 2021 8:01 pm

... finally "nice to have" enhancements. My guess is that this one falls into the latter category.

Agreed

pe1chl · Mon Dec 20, 2021 8:12 pm

Probably the main issue will be to introduce new types of address list entries.
Up to now, all address lists are of type hash:net. Address lists are not explicitly defined, they are automatically created when the first entry is added.
To have all kinds of different types of address list (there are other types in ipset that would be useful), it will likely be required to introduce explicit creation of address lists, similar to how it is now required to define routing tables before using them (was not required in v6, but in v7 it is).
That will probably create some conversion difficulties and user resistance.

Once that is overcome, it would be good to have hash:net,port and bitmap:port but also bitmap:ip.
And once address lists are to be pre-defined, it is also possible to introduce items like default timeout and counter per entry as parameters of address list creation.
(counter per entry is also something I miss in the RouterOS address lists, very useful feature of ipset)

All this will make it more than "an easy new feature programmed in an afternoon".

Sob · Mon Dec 20, 2021 9:15 pm

The hash:ip,port and list:set for me, please. It doesn't have to be right away, it's enough as next year's Christmas present.

pe1chl · Tue Dec 21, 2021 11:28 am

Yes, list:set is another useful one. But you likely agree that such changes will require an explicit "define address list" level, like with routing tables, interface lists.

Sob · Tue Dec 21, 2021 7:08 pm

I could live with that, and I'm sure that everyone else could too (it's easy when there's no choice). In any case, it would be worth it. It's a shame that such useful functionality already exists and it's just not exposed.

pe1chl · Tue Dec 21, 2021 8:05 pm

Maybe a hash:net address list could be created by default when an entry is created with the existing address= list= format...

User4011 · Sun Jan 28, 2024 1:46 am

BTTT:

Feature Request

- Ability to Add ports to a Ports list

Should reduce firewall rules and make management easier

optio · Sun Jan 28, 2024 6:30 pm

I doubt it will reduce number rules it they are correctly written, since you can literally add list of ports and range in single rule, unless you mean that port list can contain protocol also, but this imho can create configuration mess for rules, I would rather have multiprotocol rule for such cases (eg. tcp,udp port 53 for DNS in single rule). But regarding management yes, it will be more convenient if you need to apply same list of ports on different rules without need to edit each of them for some change, you can simply edit port list.
Also it will reduce configuration size in some cases if same ports are applied on multiple rules, because then port list name will be referenced and amount of bytes will be reduced in cases where port list name has less number of characters than actual list of ports.

sadjoe · Sun Jan 28, 2024 9:35 pm

When you consider that a useful feature and cannot remember port numbers for services you can add custom chains like this:
Code: Select all
/ip firewall filter
add action=accept chain=dns dst-port=53 protocol=udp
add action=accept chain=dns dst-port=53 protocol=tcp
add action=return chain=dns
Then wherever you like to "allow dns" (in input, forward, and with any other specifier you like, you can do:
Code: Select all
/ip firewall filter
add action=jump jump-target=dns ....
This will implement the "recognize services in the firewall" feature, in this case for the "dns" service but it can be done for any service.
This is much more flexible than "port list". You can make a library of services (like the first paragraph) and load those in all your routers.

It should be

/ip firewall filter
add action=accept chain=dns dst-port=53 protocol=tcp,udp (no need a second row for the same)
add action=return chain=dns

pe1chl · Mon Jan 29, 2024 11:17 am

That does not actually work... and it is not supported by the Linux firewall.
Even in "ipset" it is not possible to have a single entry with two protocols.
But you can make an ipset with 2 items, one is "tcp port 53" and the other is "udp port 53" and refer to that.

optio · Mon Jan 29, 2024 6:25 pm

Yes, just checked issue (long time passed when I switched to ufw firewall wrapper) is that iptables doesn't support multiple protocols like -[p/m] udp,tcp in combination with --[s/d]port(s), it has all but you cannot combine it with ports, like ROS rule doesn't allow entering port without protocol set. Unless ROS rule in such cases combine multiple iptables rules, but that will just result less rules on ROS side without performance improvment.

Who is online