Project

General

Profile

Actions

Bug #7058

closed

Alias type-checking issues

Added by Stilez y over 8 years ago. Updated over 8 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
12/31/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

pfSense really needs a more strongly type-checked alias system/API/library.

Current example: often these days a single device might have both an IPv4 and an IPv6 address. The user may see no reason not to define a mixed alias such as _"Printer1 := { 1.2.3.4 , 1.2.3.4::5.6.7.8}" (nothing in the GUI says not to do so or creates an error condition if they do). If they do, then the firewall code doesn't detect and handle this correctly (fw_rules_edit around line 400-600 is supposed to trap IPv4 in IPv6 rules and vice-versa but doesn't do so if it occurs in an alias).

The real underlying problem is that pfSense's current alias management functions aren't tightly enough defined, they should probably test for and flag what the alias contains in a more careful way, so that calling code can rely on it and determine more accurately at the time, if an alias content is going to cause an error condition.

A second issue is that there isn't really a good reason why mixed IPv4/IPv6 addresses can't be allowed in some situations and split 'behind the scenes' into a separate IPv4 rule and IPv6 rule for pf - after all it's what we already do in filter.inc for rules on IPv4+6 because it's convenient to do so. Also because really the user probably won't appreciate being forced to define separate IPv4 and IPv6 aliases in the example above, a single mixed alias really does represent what they want to define.

I'm happy to look into and fix this as it should be transparent/behind the scenes, and I'd like to do so. So this issue note is so that if for any reason I don't get round to it, the fact of the issue existing isn't lost.

Actions #1

Updated by Jim Pingle over 8 years ago

  • Status changed from New to Not a Bug

What's the bug here?

pf allows mixed aliases and only uses appropriate addresses when matching. We allow it because pf allows it and it works. You can have both types in an alias, then use it on IPv4 rules or IPv6 rules or both and pf uses it in each context correctly.

I've used that for matching dual-stack hosts for years without issue.

Actions #2

Updated by Stilez y over 8 years ago

In which case flip the question on-end, why does the code (firewall_rules_edit.php) seem to disallow IPv4 and IPv6 addresses in IPv4+6 rules, when there is a perfectly valid meaning and also would be allowed if part of an alias? There's something a bit inconsistent here?

Actions #3

Updated by Jim Pingle over 8 years ago

You cannot specify either one in the rule directly because it doesn't make sense. Use an alias with mixed contents in either source or destination. If you have a mixed-type source alias then it makes no sense to have a single type allowed in the destination, or vice versa. Use "any" in one or the other, or an alias in both.

If you want to use a single type explicitly as a source or destination then set the rule to match the type.

Actions

Also available in: Atom PDF