Regression #14966
closedDHCP WAN with multiple (2+) IP Alias VIPs may show ``0.0.0.0`` as an interface address at boot
100%
Description
On a system with a DHCP WAN and more than one IP alias VIP on the same interface the firewall may end up with the temporary DHCP 0.0.0.0
address remaining on the interface at the end of the boot sequence. This bogus address is shown as the interface address in the dashboard widget for Interfaces as well as under Status > Interfaces. The console menu, however, prints the correct address.
I've reproduced it on CE 2.7.1 and Plus 23.09 with as few as 2 (two) IP Alias VIPs. The VIPs do not need to be in the same subnet as the interface to trigger the problem.
It isn't 100% consistent and seems to be much easier to trigger on virtual machines, but we have reproduced it on hardware as well. It isn't specific to network drivers as it's happened on vtnet
, em
and even lagg
interfaces.
Performing a DHCP release/renew from Status > Interfaces returns the interface to normal, as does save/apply changes on the interface.
Of note is that when performing a manual DHCP release, the DHCP address remains on the interface, but 0.0.0.0
and the VIPs are removed.
Though it seems like it might be an issue in the DHCP script, the exact same code paths appear to be executed in the same way in the script with and without the VIPs present.
It does not appear to affect operation of the firewall as far as I've seen yet either, so may be more of a cosmetic annoyance, but something we need to address either way.
Updated by Reid Linnemann about 1 year ago
It's not strictly a cosmetic annoyance, as the 0.0.0.0 address is the primary address of the interface. Things like ICMP and CARP start misbehaving as (apparently) the wrong source address is used.
This does seems to be a problem in the dhclient script. pfSense has its own copy of the script from ~2004-2005 which still has a two step process of assigning the 0.0.0.0 address on PREINIT and unaliasing it on reason MEDIUM. This has been unnecessary since BPF based dhclient operation was introduced but remained in the script until earlier in 2023.
Currently I do not see the MEDIUM reason passed to the script at all so the zero address must be removed by some other means. The failure of this removal seems related to the presence of VIPs on the systems that I can reproduce it, so perhaps there is a race between the dhclient script and VIP configuration that makes the VIP configuration preserve the 0.0.0.0 address that would otherwise have been replaced by the dhclient script. Regardless, setting the source address to zero is no longer a necessity, and its removal remedies the immediately observable problem.
Updated by Jim Pingle about 1 year ago
- Plus Target Version changed from 23.09 to 24.03
Updated by Reid Linnemann about 1 year ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 1fbbea8f10c58ef11851662588819c654e31ceae.
Updated by Reid Linnemann about 1 year ago
- Target version changed from 2.8.0 to CE-Next
Updated by Jim Pingle about 1 year ago
- Target version changed from CE-Next to 2.7.1
Updated by Jim Pingle about 1 year ago
- Status changed from Feedback to Resolved
Works properly on 2.7.1 RC, the bogus 0.0.0.0 address is no longer present at boot.
Updated by Jim Pingle about 1 year ago
- Affected Version changed from 2.8.0 to 2.7.1
Updated by Hayden Hill about 1 year ago
Had this issue on 23.09, patch resolved it! Thank you!
Updated by Jim Pingle about 1 year ago
- Target version changed from 2.7.1 to 2.7.2
- Plus Target Version changed from 24.03 to 23.09.1
Updated by Jim Pingle about 1 year ago
- Target version changed from 2.7.2 to 2.7.1