Project

General

Profile

Actions

Regression #14623

closed

Primary interface address is incorrectly set to the last address on the interface

Added by Ajay Easter over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Interfaces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Default
Affected Version:
2.7.x
Affected Architecture:
All

Description

The fixes for #11545 seem to have introduced another regresssion when finding the primary interface address.

My WAN interface gets both a GUA and a ULA address from the upstream router. In pfSense 2.6.0 the primary interface address shown in the UI would correctly be the GUA. In pfSense 2.7.0 it now always uses the ULA as the primary interface address, breaking things like IPsec. My site-to-site tunnels would only come up again after I had manually removed the ULA from the interface.

I traced the problem to the new get_interface_addresses function. It always returns the last IPv6 address it found for an interface (excluding VIPs). I am not sure by which logic FreeBSD sorts IP addresses, but in my case the GUA is always listed first. Maybe it's just the same order the addresses were specified in the Router Advertisement.

In any case pfSense's previous behaviour should be restored, which is to use the first address returned by the OS as the primary address rather than the last. pfSense_get_interface_addresses, which was deprecated by get_interface_addresses, still does exactly that. In 2.7.0 it still correctly returns the GUA while at the same time get_interface_addresses returns the ULA.

Fixing this should be as easy replacing array_pop with array_shift.


Related issues

Related to Bug #14725: Primary IPv6 interface address may be incorrect when a ULA is setResolvedMarcos M

Actions
Related to Bug #14785: Primary IPv6 interface address may be incorrect when a VIP is setResolvedMarcos M

Actions
Has duplicate Bug #14782: RFC 2136 Dynamic DNS client selects a virtual IPv6 address instead of statically configured WAN Ipv6 addressDuplicate

Actions
Actions #1

Updated by Marcos M over 1 year ago

  • Tracker changed from Bug to Regression
  • Subject changed from Primary interface address is always set to ULA if present to Primary interface address is incorrectly set to the last address on the interface
  • Status changed from New to Pull Request Review
  • Assignee set to Marcos M
  • Target version set to 2.8.0
  • Plus Target Version set to 23.09
Actions #2

Updated by Marcos M over 1 year ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #3

Updated by Marcos M over 1 year ago

  • Related to Bug #14725: Primary IPv6 interface address may be incorrect when a ULA is set added
Actions #4

Updated by Jim Pingle over 1 year ago

  • Has duplicate Bug #14782: RFC 2136 Dynamic DNS client selects a virtual IPv6 address instead of statically configured WAN Ipv6 address added
Actions #5

Updated by M Felden over 1 year ago

I am not convinced #14782 is a duplicate of #14623 as the behavior observed in #14782 was all about GUA and involved a VIP. There are no ULA are present on the WAN interfaces of these boxes described in #14782

Actions #6

Updated by Jim Pingle over 1 year ago

M Felden wrote in #note-5:

I am not convinced #14782 is a duplicate of #14623 as the behavior observed in #14782 was all about GUA and involved a VIP no ULA are present on the WAN interfaces of these boxes.

Then test it and provide the data to back up that assertion either way. ULA vs GUA does not matter on this particular issue, it's about the order they appear on the OS interface when there are multiple addresses on an interface. The ULA vs GUA part was handled separately on #14725 and not this issue.

Actions #7

Updated by M Felden over 1 year ago

Apologies.

In the original report here and https://github.com/pfsense/pfsense/blob/f106b62cfbed279e8140ffa1edf535defb0221ab/src/etc/inc/interfaces.inc#L7471 seemed to indicate that VIP are handled separately and would not trigger it.

I see it using VIP addresses sort of like in #11545 hence the confusion. I will monitor #14623 :)

Actions #8

Updated by Marcos M over 1 year ago

  • Status changed from Feedback to Resolved

The fix has worked well (the first interface address is used instead of the last). However, fixing this uncovered two related issues: #14725 and #14785.

Actions #9

Updated by Marcos M over 1 year ago

  • Related to Bug #14785: Primary IPv6 interface address may be incorrect when a VIP is set added
Actions #10

Updated by Jim Pingle about 1 year ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF