Unexpected alias behaviour - two ranges / size limits with FQDN
-
I went further and applied my "Test" alias containing only 473 (of an expected 1,025) records to a disabled firewall rule.
After reloading the filter, my "Test" alias continued to contain only 473 records.
I then 'emptied' the table (i.e.,
Diagnostics / Tables> select Test alias from dropdown > click "Empty Table"), and reloaded the filter (i.e.,Status / Filter Reload).My "Test" alias now contains 165 records—sequential IPs
123.123.120.0-123.123.120.147,123.123.120.149, sequential IPs123.123.120.151-123.123.120.158, sequential IPs123.123.120.165-123.123.120.167,123.123.120.172,123.123.120.178,123.123.120.191, followed at the very end by the A/AAAA records to whichredmine.pfsense.orgresolve (208.123.73.219and2610:160:11:18::219respectively, and in that order). -
I had difficulty making sense of edits after the system has locked up because old entries are retained and test reproduction more difficult.
The other reason I have not focused on it is it tends to demonstrate the bug can be made latent so is bad not good. To explain
For me the bug initially occurred in a production unit. I incrementally update the configuration over years. One update resulted in me going over the total alias entry limit for alias with a FQDN. As old entries and other alias tables are retained after editing an alias, the system continued to work well. Months later I had a prolonged power failure resulting in a pfsense restart. The restart forces a full alias rebuilt but now the failed alias entries were not restricted to my edits 2 months earlier, other more critical entries were omitted. Which presented as failure of my main incoming VoIP supplier to register on my PABX.
As a result I have focussed on behaviour on device restart as I don't like latent failures.
