Bug when deleting nested Aliasses

[tuser_nl]

This week I encountered the following issue with pfSense 2.8.1. I can reproduce this on multiple instances. The issue is that when you delete an alias which is nested in another alias the table is cleared in a certain situation. Expected behaviour would be to deny the deletion of an nested alias, just as deleting an alias which is used in a firewall of NAT rule is not allowd.

Steps to reproduce: I have the following set of test aliasses:

1. Delete TEST_RDS03
2. Click Apply
3. Edit the alias TEST_RDSSERVERS, remove the TEST_RDS03 entry, Klik Save
4. Click Apply
5. Alias TEST_RDSSERVERS now is empty according to status > tables. And associated firewall rules do not work anymore (since the alias is empty).
6. Status -> Filter Reload fills the alias table again (Or a random firewall change + apply which essentially does the same)

If you look at the alias TEST_RDSSERVERS between step 4 and 5, you can see it changed from upper to lower case. (Don't look at the time stamps, i did some extensive testing ;))

I think I can test this later this week on a pfSense plus instance also to see if the bug is present there. But on CE i reproduce this on multiple firewalls. Things to test further:

• does it happen on a clean install
• does it happen without the IPv6 addressess
• does it happen without the IPv4 addressess

[SteveITS]

@tuser_nl IIRC pfSense refuses to delete an alias that’s in use. Perhaps the (initial) bug is step 3?

…which is what you started with I see :)

[SteveITS]

@tuser_nl I just tried to replicate quickly on 26.03 RC. I got a different/interesting behavior.

Note, I found if an alias is not used in a rule, it doesn't show in Diagnostics > Tables. I only created a rule using alias a.

Start:
Alias a contains:

• a1 = 1.1.1.1
• a2 = 2.2.2.2
  WAN rule blocks from source a.

If I delete a2 and do a filter reload:

• Firewall > Aliases shows (a= a1,a2) and (a1=1.1.1.1)
• Firewall > Aliases does not list a2
• Diagnostics > Tables shows (a=1.1.1.1, 2.2.2.2)
• I notice no errors on the filter reload page

I then tried to start over. If I simply recreate a2, and apply, I end up with:

• alias a= a1, a2
• Diagnostics > Tables shows (a=2.2.2.2 only and 1.1.1.1 is missing)
• filter reload does not change a

Seems like there are a few bugs here. I would guess the second result is because it's trying to update the invalid table and failing?

Possibly it allows deleting a2 because a2 is not used in a rule, but it should refuse because a2 is used in a.

@stephenw10

[SteveITS]

@tuser_nl I can also replicate the upper to lower case change if using upper case, the deleted A2 alias changes to lower case in A:

I found the same as I posted, if using IPv6 also.

If "A2" is recreated the parent alias changes to upper case again ("A1,A2").

I recreated A1 using only 2.2.2.2 (not 1::2) and Diagnostics > Tables still includes 1::2 which is in neither alias.

https://redmine.pfsense.org/issues/16754

[SteveITS]

duplicate of https://redmine.pfsense.org/issues/16750