Project

General

Profile

Actions

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 9 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
High
Category:
Interfaces
Target version:
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 #1

Updated by Reid Linnemann 9 months 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 #2

Updated by Jim Pingle 8 months ago

  • Plus Target Version changed from 23.09 to 24.03
Actions #3

Updated by Reid Linnemann 8 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #4

Updated by Reid Linnemann 8 months ago

  • Target version changed from 2.8.0 to CE-Next
Actions #5

Updated by Jim Pingle 8 months ago

  • Target version changed from CE-Next to 2.7.1
Actions #6

Updated by Reid Linnemann 8 months ago

Merged to plus in 1fbbea8f10

Actions #7

Updated by Jim Pingle 8 months ago

  • Assignee set to Reid Linnemann
Actions #8

Updated by Jim Pingle 8 months 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.

Actions #9

Updated by Jim Pingle 8 months ago

  • Affected Version set to 2.8.0
Actions #10

Updated by Jim Pingle 8 months ago

  • Affected Version changed from 2.8.0 to 2.7.1
Actions #11

Updated by Hayden Hill 8 months ago

Had this issue on 23.09, patch resolved it! Thank you!

Actions #12

Updated by Jim Pingle 8 months ago

  • Target version changed from 2.7.1 to 2.7.2
  • Plus Target Version changed from 24.03 to 23.09.1
Actions #13

Updated by Jim Pingle 8 months ago

  • Target version changed from 2.7.2 to 2.7.1
Actions

Also available in: Atom PDF