Project

General

Profile

Actions

Bug #10952

open

Inconsistency in Subnet Defaults Between Firewall Rules and Interface Address Assignments

Added by Kris Phillips over 3 years ago. Updated over 3 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Rules / NAT
Target version:
-
Start date:
10/03/2020
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.5-p1
Affected Architecture:
All

Description

When creating a new firewall rule, after selecting "Network" under the source or destination fields, the field defaults to both the address and subnet fields being blank.

When assigning Static IPv4 or IPv6 addresses to a new interface, the address field is blank, but the subnet mask defaults to a single host subnet (/32 or /128 for IPv4 and IPv6 respectively). Since this represents inconsistency in the UI and since a /32 or /128 are rarely/never used for an interface, it would be helpful to default this to a blank field instead like it is in other drop down menus.

Actions #1

Updated by Jim Pingle over 3 years ago

  • Category set to Rules / NAT

We've debated this in the past and always come back to leaving it as-is. We can't know what the user needs to put there. Any suggested default is going to be incorrect for a non-insignificant portion of the user base, and using /32 for IPv4 and /128 for IPv6 is safer than using a mask that is too large. It may not work if they user doesn't set it incorrectly, but it's unlikely to break.

The way the subnet mask/prefix length control is designed I don't think it's viable to add a blank entry to it to force the issue, but we can leave this open to investigate. The same form type (Form_IpAddress) is used in many different pages, all of which would need to account for such changes.

Actions #2

Updated by Kris Phillips over 3 years ago

Jim Pingle wrote:

We've debated this in the past and always come back to leaving it as-is. We can't know what the user needs to put there. Any suggested default is going to be incorrect for a non-insignificant portion of the user base, and using /32 for IPv4 and /128 for IPv6 is safer than using a mask that is too large. It may not work if they user doesn't set it incorrectly, but it's unlikely to break.

The way the subnet mask/prefix length control is designed I don't think it's viable to add a blank entry to it to force the issue, but we can leave this open to investigate. The same form type (Form_IpAddress) is used in many different pages, all of which would need to account for such changes.

Jim,

Appreciate the follow up. It would be helpful to simply have it blank and not allow end users to apply changes until they set a proper subnet field (similar to other required fields).

Actions #3

Updated by Kris Phillips over 3 years ago

Important to note that if we're going to add field verification and blank fields for the subnets, we should do it for all fields except for the interface drop down (since we're already creating the rule by navigating to the interface tab). Most importantly, blanking out the Protocol field instead of displaying TCP and adding verification for a user to ensure they selected something would be helpful here.

Actions

Also available in: Atom PDF