Port forwarding allows invalid protocol selection with "ALL" and still shows port fields

[cotosso]

Description:

When creating a port forward rule, selecting the "ALL" protocol from the dropdown should imply that the rule applies to all protocols and ports. In this case, the port fields should be hidden or disabled, as they are irrelevant.

However, the UI currently allows:

• Selecting "ALL" alone while still displaying the port fields.
• Selecting "ALL" together with other protocols (e.g., TCP, UDP), which is inconsistent and leads to confusing behavior.

This can easily result in misconfigured rules where users believe they are opening only specific ports (e.g., 53 TCP/UDP), but instead end up forwarding all ports and all protocols, which is incorrect and potentially dangerous.

Steps to Reproduce:

1. Go to Port Forwarding and create a new rule.

2. In the protocol dropdown:

   • Select only ALL, or
   • Select ALL along with other protocols (e.g., TCP, UDP).

3. Observe that the port fields are still shown and editable.

Expected Behavior:

• Selecting ALL should disable/hide port fields.
• ALL should not be selectable together with other protocols.

Actual Behavior:

• Port fields remain visible even when ALL is selected.
• UI allows invalid protocol combinations.

Components:

NethSecurity 8-24.10.0-ns.1.6.0

[cotosso]

Proposed Solutions

Option 1 (quick fix)

Remove the ALL option from the protocol dropdown.
In this case, selecting all traffic is only possible by leaving the protocol field empty, this automatically hides port fields and displays a warning message.

Option 2 (better UX)

Replace the dropdown with a radio button that offers two choices:

• Select one or more protocols (from a list without the ALL option).
• Forward all traffic : when this is selected, the port fields are hidden and protocol selection is disabled.

[AmaLuci]

We’ve decided to move forward with the 2nd solution:
Adding an explicit selection between “Select protocols” and “All traffic”, as shown in the attached mockup.
When All traffic is selected, the source port input will be hidden, since it's no longer relevant.

Plus, we can take the opportunity to improve a few things:

• The inline notification: more clear, user-friendly, and aligned with the overall tone of the UI (see mockup for a first proposal – open to changes).
• Add the ability to directly select “Firewall” as a destination address, instead of requiring users to leave the IP field empty.

[cotosso]

I propose to modify the inline message so that it is clear that the host is exposed and firewall services could result to be unavailable.

Version 1
All incoming traffic will be forwarded to the selected destination.
The destination host will be exposed and any firewall services will be unreachable on this WAN IP.

Version2
All incoming traffic will be forwarded to the selected destination.
This bypasses firewall protection, exposes the destination host, and makes firewall services (e.g. UI, SSH) unreachable on this WAN IP.

[cotosso]

requirements to add

• Typical usage case
  Redirecting a port without changing the destination port.
  The helper text on the destination field should be removed, as it is misleading in this scenario ("leave blank for any port")

• Forwarding all TCP (or UDP or any protocol) traffic
  The source port field should be allowed to be empty when forwarding all traffic of a protocol.

• Firewall as destination host
  If the firewall is selected as the destination host, at least the source port must be mandatory.

• Forwarding all traffic to an internal host
  When forwarding all traffic to an internal host:

  • port fields must disappear
  • the “firewall as destination” option must also disappear