core icon indicating copy to clipboard operation
core copied to clipboard

Specify Multiple Non-Contigous Ports Per Firewall Rule

Open Ryushin opened this issue 9 months ago • 4 comments

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

  • [X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
  • [X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe. Currently it is not possible to specify multiple non-contiguous ports in a single firewall rule, other than creating a special alias specifying those ports. This makes adding firewall rules is time consuming and hard to read in the UI.

Describe the solution you like

Ideally, adding a firewall rule will let you specify the port either as comma separated rules, such as: 25,80,443,465,587,993 or even better you can specify the port and type (TCP, UDP, TCP+UDP), ICMP along Code Type (All or specific pull down for the codescode) and then add a + sign to add additional ports or ICMP types.

Describe alternatives you considered Adding aliases for rules is time consuming and adds clutters

Additional context

Most Enterprise grade firewalls allow adding multiple ports, IPs or Machines to a single rule. Having to create an additional rule for every port or machine is time consuming and greatly clutters up the UI.

Examples: Fortigate UI: https://www.samuraj-cz.com/gallery2/002480.png FWBuilder UI: https://www.linux.com/images/stories/2011/fwbuilder_firewall.png

Ryushin avatar Feb 13 '25 21:02 Ryushin

https://docs.opnsense.org/manual/aliases.html#ports

AdSchellevis avatar Feb 14 '25 08:02 AdSchellevis

https://docs.opnsense.org/manual/aliases.html#ports

I'm aware that it is possible using aliases, but that is a band-aid to the problem. First I would have to create dozens and dozens of aliases which is time consuming in itself. Then in the Firewall UI, I still can't see what the ports are under the alias unless I hover my mouse over the alias. So using an Alias actually makes things worse as I can't see at a glance which ports are open in the firewall rules. It is better to create a rule for each port then so I can see what ports are being allowed.

Displaying all the ports at once in a single rule is just a better way to create a rule and a better way to see what the rules are doing in the UI.

Ryushin avatar Feb 14 '25 12:02 Ryushin

I'm aware that it is possible using aliases, but that is a band-aid to the problem. First I would have to create dozens and dozens of aliases which is time consuming in itself. Then in the Firewall UI, I still can't see what the ports are under the alias unless I hover my mouse over the alias. So using an Alias actually makes things worse as I can't see at a glance which ports are open in the firewall rules. It is better to create a rule for each port then so I can see what ports are being allowed.

Displaying all the ports at once in a single rule is just a better way to create a rule and a better way to see what the rules are doing in the UI.

I think there are two separate problems here. Creating rules, and viewing rules.

I think it would be good to have the option to expand aliases in the rules view, but it would get very long all of a sudden and this definitely shouldn't be the default.

Adding rules using aliases is more work, but it is a much better practice in the long-run than directly referencing multiple ports per rule like your screenshots of Fortigate and FWBuilder.

Directly referencing ports turns into a nightmare if you have any of a lot of rules, complex rules, or a lot of firewalls. It gets exponentially worse if you have multiple of those things at once. It gets almost impossible to keep rules sanely updated when requirements change. Much better to do the work up-front creating sensibly-named aliases to group services than to have to try and clean it up after it turns into a giant mess (ask me how I know).

For this reason alone I wouldn't like to see the ability to have multiple ports per rule. It seems convenient at first, but it's a trap.

amuckart avatar May 30 '25 00:05 amuckart

I think there are two separate problems here. Creating rules, and viewing rules.

I think it would be good to have the option to expand aliases in the rules view, but it would get very long all of a sudden and this definitely shouldn't be the default.

Adding rules using aliases is more work, but it is a much better practice in the long-run than directly referencing multiple ports per rule like your screenshots of Fortigate and FWBuilder.

Directly referencing ports turns into a nightmare if you have any of a lot of rules, complex rules, or a lot of firewalls. It gets exponentially worse if you have multiple of those things at once. It gets almost impossible to keep rules sanely updated when requirements change. Much better to do the work up-front creating sensibly-named aliases to group services than to have to try and clean it up after it turns into a giant mess (ask me how I know).

For this reason alone I wouldn't like to see the ability to have multiple ports per rule. It seems convenient at first, but it's a trap.

I should have actually brought up the fact that Fortigate and FWBuilder let me group protocols and ports into "Services" which would be parallel to Aliases. So say I want to have a WebServer service/alias and have HTTP, HTTPS, ICMP grouped together, I can. Essentially it makes it easier to have one rule for that server and I can either see a aliased group of ports or specify the individual ports.

I should probably also modify the subject as in addition it would be nice to list multiple ports in a rule, it would also be nice to list multiple hosts in the source or the destination in a single rule.

Ryushin avatar May 30 '25 22:05 Ryushin

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.

OPNsense-bot avatar Aug 12 '25 20:08 OPNsense-bot