Unable to delete IP Alias outside an interface's subnet where a gateway exists in the same subnet
I have a working 2 FW CARP setup with pfSense 2.2 and a /28 subnet of available ip addresses.
If I add one of my available IPs as as "IP Alias" and later decide I don't want to delete it an error occurs:
"This entry cannot be deleted because it is still referenced by at least one Gateway."
If I don't want the FW listening for a particular IP in my subnet I should be able to delete it.
I did find a previous bug report back in 2013 that seems to reference the same issue in an earlier version of pfSense that was fixed.
The work around is fairly simple. Change the it from an "IP Alias" to an "Other", save it, then delete it.
While the work around it fairly simple this is still a bug isn't it?
Updated by Chris Buechler almost 9 years ago
- Subject changed from Unable to delete IP Alias to Unable to delete IP Alias outside an interface's subnet where a gateway exists in the same subnet
- Status changed from New to Confirmed
- Affected Version changed from 2.2 to All
the specific issue is if you have an IP alias VIP that's not within any of your interfaces' subnets, and you have a gateway configured within that IP alias' subnet, it won't allow you to delete any IP aliases within that gateway's subnet. It should only prevent removal of the last IP alias within that subnet (otherwise it'd allow breaking that gateway's ability to function). It really shouldn't allow switching it to type "Other" either in that scenario to prevent the same breakage, but there isn't validation of that sort on type changes.
Updated by Jim Pingle over 5 years ago
- Assignee set to Jim Pingle
- Target version set to 2.4.4
- Affected Architecture All added
- Affected Architecture deleted (
Easy to reproduce:
1. Add IP Alias VIP in new subnet
2. Add gateway in new subnet
3. Add second IP Alias VIP in new subnet
4. Try to delete either of the VIPs, both fail. Only the last one should fail.
The check at source:src/usr/local/www/firewall_virtual_ip.php#L152 is only testing that the VIP shares a subnet with a gateway. It doesn't check if there are any other VIPs remaining that reference the gateway.
Workarounds include: Changing the VIP type to 'other' or changing the mask to /32, then deleting.
On that note, either of those changes should probably also throw an error if it is the last remaining VIP in the subnet with a gateway.