pfSense

please re-test on 2.3, a lot of validation improvements there into aliases and some relevant filterdns changes.

Please retest on 2.3. Close if possible. Let me know if it's still an issue

While creating an alias containing multiple networks, I used copy/paste and (unthinkingly) pasted 18 of the 22 entries as #.#.#.0/24:

- the first issue is that these were all accepted without warning
- the second issue is that, apparently upon saving the alias definition, these were not created as though I'd selected "24" via the "CIDR" popup menu (which would have made the first issue a feature, not an issue) ... but each /24 entry was expanded to the 256 IPs as though I'd made the separate 256 entries for each

That is a feature, being able to use ranges and subnets to expand. It's not just meant to be used on that scale. If you're copying and pasting in networks and hosts, use the import feature, which is more prominently displayed on 2.3 on the main aliases page. It was on 2.2.x and earlier but was harder to see (a little up arrow at the bottom)

Input validation prevents it from running too far on 2.3, it will fail to expand once it reaches 5000 entries.

- the third issue is that, once the alias was used in a rule and the alias' table was to be created, the filterdns process was failing:

+ pfSense fails with a "direct" alias definition with 4,612 entries (i.e., not using a URL/file-based alias)

On 2.3, input validation stops this at 5000 entries, which does work provided the browser/client doesn't crash when handling that large of a form.

+ during every "reload," filterdns would (seemingly, by watching top) slowly (5-15 minutes) grow in size then core-dump when it reached around 400 MB "RES"
+ during the "reload," the router is effectively "dead" (i.e., seemingly all traffic, including web-configurator, is blocked)
+ the long-lived all-blocking behavior of this issue makes troubleshooting and repair very difficult ... well, very slow, at least

I can't reproduce any similar problems with filterdns on 2.3, possibly because part of the original conditions could not be replicated.

- the fourth issue -- a very serious one -- is that the failure of filterdns caused multiple tables to still be listed as present, but to have no contents (at a quick glance, it appears this is for any alias table that has one or more FQDN entry)

This is a serious issue because the creation of empty tables causes loss of both functionality and security. In fact, we had one device modified due to the inherent loss of security this failure caused.

Something like that could only happen if you were relying on selective blocking rules before general pass rules. A blank table doesn't match all/any, it matches nothing. So it would simply not match the affected rule and continue on down the ruleset. No issue there except the design of the ruleset.

There doesn't appear to be anything here that's a problem with our current code.