<![CDATA[Bug when deleting nested Aliasses]]>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:
8731b3cf-770b-45b1-a10c-98993e242214-2026-03-20_08-00.png

  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 ;))
1a185d05-f64a-47db-9149-7d6551adb98c-2026-03-20_07-59.png
1c0a1ba4-9e46-4466-b62b-f628d79ce06e-2026-03-20_08-01.png

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
]]>https://forum.netgate.com/topic/200390/bug-when-deleting-nested-aliassesRSS for NodeSun, 14 Jun 2026 20:01:31 GMTFri, 20 Mar 2026 08:03:41 GMT60<![CDATA[Reply to Bug when deleting nested Aliasses on Fri, 20 Mar 2026 16:17:36 GMT]]>duplicate of https://redmine.pfsense.org/issues/16750

]]>https://forum.netgate.com/post/1240019https://forum.netgate.com/post/1240019Fri, 20 Mar 2026 16:17:36 GMT<![CDATA[Reply to Bug when deleting nested Aliasses on Fri, 20 Mar 2026 15:51:17 GMT]]>@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:
b0b701f0-7dd9-4432-a5a7-574ac67a2fe1-image.png

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

]]>https://forum.netgate.com/post/1240017https://forum.netgate.com/post/1240017Fri, 20 Mar 2026 15:51:17 GMT<![CDATA[Reply to Bug when deleting nested Aliasses on Fri, 20 Mar 2026 13:36:17 GMT]]>@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

]]>https://forum.netgate.com/post/1239990https://forum.netgate.com/post/1239990Fri, 20 Mar 2026 13:36:17 GMT<![CDATA[Reply to Bug when deleting nested Aliasses on Fri, 20 Mar 2026 12:28:28 GMT]]>@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 :)

]]>https://forum.netgate.com/post/1239981https://forum.netgate.com/post/1239981Fri, 20 Mar 2026 12:28:28 GMT