pfSense

But this wasn't about the issues with creating an alias table (which is why it's a separate report). This is about having a sanity check that's run every time there's an update that would alter/(re)define the alias tables.

This is important due to the fact that such failures/bugs (which, we can see, there have been ... and likely will continue to be -- hey, it's software) are critical to both the functionality of pfSense and, therefore, the security of the using organization's devices.

I propose that any such issues and resulting failures are potentially so critical to security that there deserves to be (at least) some sanity checking performed that will catch (at least) the "empty table" and "missing table" cases that result from any alias/rule-creation issues. I'm guessing that such a check is not even that difficult, especially in relation to its value.

The alternative is that you're exposing pfSense to a failure that could have spectacular (negative) results and publicity for pfSense.

In my case, since I no longer have any confidence in this aspect of pfSense (having suffered 2 different failures), I now am compelled to spend the time to check each of the (currently) 112 tables every time I make a change ... a significant cost, in time.

Don't get me wrong, I think pfSense is a great product and that y'all do an exemplary job.

It's just that it seems obvious that this is a critically important issue that needs to be addressed ... assuming you care about security.

B. Derman wrote:

But this wasn't about the issues with creating an alias table (which is why it's a separate report). This is about having a sanity check that's run every time there's an update that would alter/(re)define the alias tables.

That's precisely what I changed in 2.3, those alias contents, when updated, are fully validated. Rules specifying aliases that don't exist aren't included in the ruleset (which has been true for a number of years with the exception of a ports URL table alias edge case fixed in 2.3).

If you're aware of a specific circumstance that doesn't work in 2.3, please provide specifics to replicate, I'll fix it. I see no indication that's the case though.