Reported in forum https://forum.pfsense.org/index.php?topic=82319.0
The "if (is_subnet($src)) ... filter_address_add_vips_subnets" code needs to go outside all of the if that checks for opt interfaces (not just in the else part). That makes filter_address_add_vips_subnets get called in all cases, including when optn network is specified. (line 2264, 2265)
Then filter_address_add_vips_subnets needs to process the "not" code early, before checking if there are any VIPs (which was causing the routine to exit early in simple cases) - lines 2093-2100 chunk. This should also fix cases of using "LANnet", "WANnet" and "not" in rules on an interface that has just a plain address (no VIPs).
Lines 2144 and 2158 are no functional change. The formatting of the multi-line statement was odd, so I put it back all on 1 line.
Currently if you enter a space-separated list of subnets in the IP address box when entering an alias, the code reports that the data is invalid. But it does actually expand the list of subnets into multiple rows, and enters the various subnet CIDRs into the CIDR column for the user. The user can press Save a second time and the data is now valid so the code saves it happily. This is rather odd, as reported in redmine #3890.
Also, if you input an IP range (e.g. 192.168.20.0-192.168.20.30) plus description and in the 2nd row put some other subnet and description, the range is correctly expanded, but the description only appears against the 1st subnet of the range. The description from the 2nd row ends up as the description against the 2nd subnet of the range, and the rest of the descriptions are blank. i.e. the descriptions do not get copied and pushed down as the IP ranges are expanded.
This change fixes all that stuff by first parsing the posted data and expanding any IP ranges and/or space-separated lists, building arrays that have all their entries lined up:
$input_addresses[]
$input_address_subnet[]
$final_address_details[]
which are then validated.
This is for master (2.2) branch. Actually it was not too difficult to integrate.
If type URL Table then the heading "Description" on the 3rd column gets suppressed (I am not really sure why that is, since the description data entry box still appears - I guess someone intended that the data entry box itself also be suppressed, since URL Table takes just a single line entry, the overall description of the alias should be enough - no need for a per-line description.)
In any case, if the user then selects some other Alias Type, the "Description" heading on the 3rd column is not re-enabled.
This change fixes that.
I also implemented what is suggested in Redmine #3893 - making the 1st column heading say "IP or FQDN", "Network or FQDN". IMHO that looks fine on the UI and cannot do any harm. (and yes, the longer explanatory text already tells the user that an FQDN is allowed in these cases.)
While looking at other checks in the code I noticed this check. It was not effective anyway, because the first line inside "if ($_POST)" below does
unset($input_errors);
which undoes this check anyway.
In any case the check is not relevant. For example I might have interface WAN with description (which is really the alternate/display name for an interface) as MYISP.
I cannot also have an Alias with name MYISP - that is checked for already later in the code.
But I can have an Alias with description MYISP - in the case of an Alias the description really is just helpful text for the user, it is the name that really counts for use in the pf configuration.
So the code is not needed.
Chris Buechler
Ermal
Renato Botelho
Phil Davis
Steven Selph
PiBa-NL
jim-p
Jean Cyr