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

Also available in: Atom PDF