Bug #14434


PPPoE WAN interface with VIPs causes continuous interface restarting

Added by Bert Smith 9 months ago. Updated 15 days ago.

PPP Interfaces
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


I have a /28 routable legacy IP block from the ISP, and they assign the first usable address of the /28 block as a /32 to the PPPOE interface, so i have:

Routable block: x.x.x.64/28
PPPOE address: x.x.x.65/32
LAN address CARP VIP: x.x.x.65/28

This configuration worked fine in 22.05, but is broken in 23.01 and remains broken in 23.05.

The PPPOE connection establishes and calls /etc/rc.newwanip, which then calls find_interface_ip() and get_interface_ip() to determine the address assigned to pppoe0. These functions return NULL, which causes rc.newwanip to restart the pppoe0 interface. This then causes an endless loop. The logs show the correct interface name, but no IP:

rc.newwanip: on (IP address: ) (interface: WAND[opt5]) (real interface: pppoe0).

Looking through the find_interface_ip() function, i can see it looks for $interface_ip_arr_cache - this array exists, but is empty causing the function to fail and return NULL.

I can see that if $interface_ip_arr_cache does not exist, it should open /var/db/${interface}_ip

        if (!isset($interface_ip_arr_cache[$interface]) or $flush) {
                if (file_exists("/var/db/${interface}_ip")) {

The file /var/db/pppoe0_ip is present and contains the correct address.

I'm hoping someone more familiar with the codebase and changes between 22.05/23.01 could give some insight into this otherwise i'll be trying to track it down further.

Actions #1

Updated by Steve Wheeler 8 months ago

  • Project changed from pfSense Plus to pfSense
  • Subject changed from PPPOE WAN interface overlapping with CARP VIP causes continuous interface restarting to PPPoE WAN interface with VIPs causes continuous interface restarting
  • Category changed from PPP Interfaces to PPP Interfaces
  • Priority changed from Normal to High
  • Target version set to 2.8.0
  • Affected Plus Version deleted (23.01)
  • Plus Target Version set to 23.09
  • Affected Version set to 2.8.0

This also affects 2.7 and when using IPAlias VIPs on the WAN.


Actions #2

Updated by Steve Wheeler 8 months ago

  • Affected Version changed from 2.8.0 to 2.7.0
Actions #3

Updated by Jim Pingle 5 months ago

  • Plus Target Version changed from 23.09 to 24.03

Moving the target ahead for now but there have been several other fixes for interface/VIP functions in 23.09 already so it's possible the underlying problem has already been addressed.

Actions #4

Updated by Steve Wheeler 2 months ago

Still present in 23.09.1

Actions #5

Updated by Adam French 15 days ago

Steve Wheeler wrote in #note-4:

Still present in 23.09.1

I can also confirm it is still present is the latest stable release since I was affected by this issue too.
Oddly removing the VIP's has not affect for me though. PPPoE comes up for very short period and goes back down again. Same log events saying "caught fatal signal TERM"
When monitoring this I noticed the line does come up and is assigned an IP using DHCP from our ISP, but quickly get's shutdown when this log event occurs.
This was previously working in 22.05.1, stopped in 23.01 and continued to not work in 23.05 and also in 23.09.1
Whatever change was made between 22.05.1 and 23.01 has broken the PPPoE functionality.


Also available in: Atom PDF