Regression #14966: DHCP WAN with multiple (2+) IP Alias VIPs may show ``0.0.0.0`` as an interface address at boot - pfSense - pfSense bugtracker

Actions

Copy link

Regression #14966

closed

DHCP WAN with multiple (2+) IP Alias VIPs may show ``0.0.0.0`` as an interface address at boot

Added by Jim Pingle about 1 year ago. Updated 12 months ago.

Status:

Resolved

Priority:

High

Assignee:

Reid Linnemann

Category:

Interfaces

Target version:

2.7.1

Start date:

Due date:

% Done:

100%

Estimated time:

Plus Target Version:

23.09.1

Release Notes:

Default

Affected Version:

2.7.1

Affected Architecture:

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.

Actions

Copy link

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.

Actions

Copy link