Project

General

Profile

Bug #5261

Existing src or dst network is not shown when editing a rule

Added by Phillip Davis almost 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
10/06/2015
Due date:
% Done:

100%

Estimated time:

Description

1) Add a rule with src or dst "Network" and enter some network (e.g. 10.11.12.0/24)and save.
2) Edit the rule

firewall_aliases_edit shows the source/destination address as "any" - it loses the "Network" selection and network address.

Note: This is a problem both before and after https://redmine.pfsense.org/issues/5252 which fixed the case of a rule that has "Single host or alias" and an alias specified.

So I have logged this as a separate bug. I will have a look shortly at what is needed to fix this case.

Associated revisions

Revision aadc5973 (diff)
Added by Steve Beaver almost 4 years ago

Fixed #5261
Corrected src/dst type logic

Revision 3e8bac5f (diff)
Added by Phillip Davis almost 4 years ago

Fix #5261 last time I hope

The previous version was considering "Single host or alias" to be "Network"because the !is_specialnet() test came first - and that matched both 'network' and 'single' types, which are both not a specialnet.
If have re-ordered the tests so that it is written in a positive order. I think that makes it easier to read.
1) If it is_specialnet then pass the special name straight through to $ruleType.
2) Next see if it is a single IP address or alias.
3) The rest must (should, better) be 'network'.

I tried editing all sorts of aliases with various types and this works form me.

History

#1 Updated by Steve Beaver almost 4 years ago

  • Status changed from New to Feedback

Corrected src/dst type logic

#2 Updated by Steve Beaver almost 4 years ago

  • % Done changed from 0 to 100

#3 Updated by Phillip Davis almost 4 years ago

Now that makes a problem when the src is LANnet, for example. It considers that a 'network' type - see GitHub comment on commit https://github.com/pfsense/pfsense/commit/aadc597321a9cbb41fb76a5faed256ed8a13f96a

#5 Updated by Phillip Davis almost 4 years ago

Can someone else please give this a good testing, because I have done that last change myself so I will easily miss some unusual combination when testing. Things that need to be tested are creating new and editing existing rules with source and/or destination IP like:
a) any
b) special names like LAN net, LAN address, WAN net, WAN address, OPT1 net, OPT1 address, PPPoE clients, L2TP clients and...
c) Single host or alias - put a single IP address and/or an alias name
d) Network - specify a network address with CIDR bit count

Make sure that the current values really are the ones displayed and saved when editing.

It is important that this works correctly because combinations of these are used in every rule, and the rules are the heart of a firewall.

#6 Updated by Chris Buechler almost 4 years ago

  • Status changed from Feedback to Resolved

all those circumstances seem fine, been through a variety in the past couple days with no issues found.

Also available in: Atom PDF