CRITICAL: 25.11 has broken VIPS defined on PPPoE interfaces managed by if_pppoe

ChrisJenk

I just upgraded a 6100 from 25.07 to 25.11 and now my two IPv6 VIPs on my WAN interface (PPPoE using if_pppoe) do not work - they simply do not get created. All VIPS on LAN interfaces are fine. I tried deleting and re-creating the WAN VIPS - GUI shows them there but ifconfig shows they are not (and they are non-functional - of course). Reboot did not help.

I have temporarily reverted to the deprecated PPPoE driver but that only seems to allow one (IPv6) VIP on the WAN so only slightly better.

I totally rely on / need these two VIPS so I'm in kind of a pickle now.

I saw mention of a 'fix' relating to VIPs on if_pppoe managed interfaces in the release notes; I suspect that 'fix' has actually broken VIP support on those interfaces???

ifconfig output (using deprecated driver) - only one VIP. Using if_pppoe there are no VIPs; was workign fine under 25.07.

root: ifconfig pppoe0
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
description: WAN
options=0
inet 212.69.48.211 --> 212.69.63.54 netmask 0xffffffff
inet6 fe80::92ec:77ff:fe7f:c9d9%pppoe0 prefixlen 64 scopeid 0x11
inet6 2a02:390:feed:62fb:92ec:77ff:fe7f:c9d9 prefixlen 64 autoconf pltime 604800 vltime 2592000
inet6 2a02:390:62fb::123 --> fe80::2a3:8eff:feca:ae80%pppoe0 prefixlen 128
groups: AllWANs
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Screenshot 2025-12-18 at 11.25.12.png

stephenw10

Hmm, how is IPv6 configured on the PPPoE?

ChrisJenk

@stephenw10 The only way that works... (this was all fine under 25.07)

WAN IPv6.png

stephenw10

Ok. You shouldn't need MTU and MSS set there. MSS is set on the PPPoE config anyway unless you have disabled it. But that shouldn't make any difference to VIPs.

Do you see anything logged if you resave the VIP or at boot?

ChrisJenk

@stephenw10 It's perfectly fine to set MTU and MSS there (there aren't any exactly equivalent options in the PPPoE config anyway).

I switched back (temporarily) to using if_pppoe and rebooted. Then I tried deleting and recreating one of the VIPs (::1) and saw some strange errors in the log (screenshots below). I also tried editing the same VIP to change the IPv6 prefix length and got a different error. Both those operations work fine in 25.11 with the deprecated driver (and used to work fine with if_pppoe in 25.07).

Seems something is badly broken in this area in 25.11. Maybe related to the fix detailed in the release notes?

I'm back to running with the deprecated driver for now but that is not a suitable long term workaround.

Delete then add.png

Prefix 64.png

wisepds

@ChrisJenk said in CRITICAL: 25.11 has broken VIPS defined on PPPoE interfaces managed by if_pppoe:

be related to the fix detailed in the release notes?

Hi, we have a lot of problems too with PPPoe.
Check this post: https://forum.netgate.com/topic/199596/pfsense-25.11-broke-my-lan.

stephenw10

Ok that ioctl error looks pretty clear. Let me see....

stephenw10

Are those VIPs all inside the dhcpv6 /64?

ChrisJenk

@stephenw10 No they are not (and they should not need to be).

The DHCP assigned address is:

2a02:390:feed:62fb:92ec:77ff:fe7f:c9d6/64

I am not allowed to use any other addresses within that prefix.

My ISP provides me with a fully routable /48 prefix (2a02:390:62fb::/48). The VIPs are both within that prefix range (2a02:390:62fb::1/128 and 2a02:390:62fb::123/128).

That should be perfectly fine. It was fine under 25.07 for both the deprecated driver and if_pppoe and it is still fine when using the deprecated under 25.11. It should also be fine under 25.11 with if_pppoe.

With the deprecated driver under 25.11:

pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
description: WAN
options=0
inet 212.69.48.211 --> 212.69.63.54 netmask 0xffffffff
inet6 fe80::92ec:77ff:fe7f:c9d6%pppoe0 prefixlen 64 scopeid 0x11
inet6 2a02:390:62fb::123 prefixlen 128
inet6 2a02:390:62fb::1 prefixlen 128
inet6 fe80::92ec:77ff:fe7f:c9d9%pppoe0 prefixlen 64 scopeid 0x11
inet6 2a02:390:feed:62fb:92ec:77ff:fe7f:c9d6 prefixlen 64 autoconf pltime 604800 vltime 2592000
groups: AllWANs
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

stephenw10

Indeed they should not need to be I was just trying to replicate your setup as closely as possible.

But I have replicated it now:

Dec 18 19:38:52 	php-fpm 	52225 	/firewall_virtual_ip.php: The command '/sbin/ifconfig pppoe0 inet6 '2001:db8::1111' -alias' returned exit code '1', the output was 'ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address'
Dec 18 19:38:52 	php-fpm 	52225 	/firewall_virtual_ip.php: The command '/sbin/ifconfig 'pppoe0' inet6 '2001:db8::1111'/'128' alias fe80::5b8:2073:9365:e785%pppoe0 ' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): File exists'

Digging....

stephenw10

OK there seem to be a number of things interacting here.

However when using if_pppoe the gateway is not required on the VIPs and can be simply omitted. Doing so allows the interface to come up as expected with all the VIPs:

[25.11-RELEASE][admin@m470-3.stevew.lan]/root: ifconfig pppoe0
pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
	description: PPPOE_WAN
	options=0
	inet 10.2.25.4 --> 10.2.25.1 netmask 0xffffffff
	inet 10.0.6.1 --> 10.2.25.1 netmask 0xffffff00
	inet 10.0.6.2 --> 10.2.25.1 netmask 0xffffffff
	inet6 fe80::290:7fff:feda:4472%pppoe0 --> fe80::f154:13ba:488b:7b10%pppoe0 prefixlen 128 scopeid 0x16
	inet6 2001:db8::1111 prefixlen 128
	inet6 2001:db8::2111 prefixlen 128
	inet6 2001:db8::3111 prefixlen 128
	inet6 2001:db8::934 prefixlen 128 pltime 43200 vltime 43200
	groups: pppoec
	nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD>

However that breaks mpd5/netgraph so some further thought is required here.

Are you able to run a test?

ChrisJenk

@stephenw10 Yes, I can run a test if you provide detailed instructions on what to do and what to expect.

I'm not sure what you mean by 'the gateway is not required on the VIPs and can be simply omitted'; there is no where that that is specified in the configuration? Do you mean add them manually using the command line (which is fine for a test)? Specifically would the command be something like:

/sbin/ifconfig pppoe0 inet6 2001:db8::1111/128 alias

Also what does it mean 'that breaks mpd5/netgraph'?

Please advise.

Also, I'm quite interested to understand why NetGate is shipping production security software based on what is essentially a beta OS version (at best). In my 40+ years in the industry no company I have worked for would even consider doing such a thing, and if they did their customers would (rightly) have their guts for garters (as we say in the UK). I'm not saying the FreeBSD 16 is related to this issue (though I suspect it is) but it seems like a potentially dangerous and perhaps ill-considered policy. I'd be interested in your comments.

ChrisJenk

@stephenw10 Okay, I went ahead and did the following:

Created a script containing the commands:

/sbin/ifconfig pppoe0 inet6 2a02:390:62fb::1/128 alias
/sbin/ifconfig pppoe0 inet6 2a02:390:62fb::123/128 alias

Set this up to run after boot via 'shellcmd'.
Deleted the two WAN VIPs in the GUI.
Switched back to if_pppoe and rebooted.

After the reboot the VIPs were created and functional. I've run my full gamut of network tests and everything is up and working as expected.

Is it safe to stick with this as a workaround pending a code fix? Or could there be any bad consequences of running like this?

stephenw10

The code that adds the VIPs when the interface is configured includes the gateway from that interface for PPPoE links because at one time that was required. See: https://redmine.pfsense.org/issues/7132

That is no longer the case and is in fact creating an issue in 25.11. So simply omitting it should allow PPPoE using if_pppoe to work. I tested this by commenting out line 3354 from /etc/inc/interfaces.inc:

		if (is_pseudo_interface($realif)) {
			if (is_ipaddrv4($vip['subnet'])) {
				$gateway = get_interface_gateway($if);
			} else {
		//		$gateway = get_interface_gateway_v6($if);
			}
		}

But doing so only works with the new if_pppoe code. It will break the old pppoe code that used mps5 and netgraph.

Unfortunately I don't have any real VIPs on my PPPoE WAN to test with so I have only tested that internally. If you are able to test it on a real WAN that would be very helpful. Here's a patch you can apply via the system patches package to do the same.

184.diff

ChrisJenk

@stephenw10 See my latest post above. I tested this using if_pppoe and it works just fine. I would normally only use if_pppoe so a temporary 'fix' that works only for that is fine. I've never used the 'system patches' package; is it pretty straightforward to apply your patch? It would be nice to be able to create the VIPs via the GUI rather than via the script that I am using.

stephenw10

Ah sorry we cross posted. OK good.

Yes the system patches package is pretty self explanatory but there is also a docs page: https://docs.netgate.com/pfsense/en/latest/development/system-patches.html
It's almost always better to use that because you can then trivially apply or revert a patch at any time. And it is stored in the config so it survives an upgrade etc.

That is almost certainly not the final fix here though. There are a number of things interacting unexpectedly and we need to fully understand the changes since 25.07.1 first. Most of this code has existed for years without an issue. But using the System Patches package you can easily revert this and apply a final patch in the future.

ChrisJenk

@stephenw10 I've applied the patch, delete the VIPs manually, disabled the shellcmd and re-created the VIPS via the GUI.

The VIPs exist and everything is working as it should (well, all my tests pass anyway).

Is there likely to be another interim patch or will the final fix come in the next release?

Also, I'm quite interested to understand why NetGate is shipping production security software based on what is essentially a beta OS version (FreeBSD 16). In my 40+ years in the industry no company I have worked for would ever consider doing such a thing, and if they did their customers would (rightly) have their guts for garters (as we say in the UK). I'm not saying the FreeBSD 16 is related to this issue (though I suspect it is) but it seems like a potentially dangerous and perhaps ill-considered policy. I'd be interested in your thoughts.

stephenw10

There will likely be another patch once we have understood the root cause here. It will probably be a recommended system patch in a package update. You'll notice there aren't any recommended patches in the package for 25.11 yet.

if_pppoe is a relatively new feature. It doesn't entirely surprise me that there are still some bugs to find in it. What's more surprising is that this also effects mpd5/netgraph. But, as you also found, it doesn't appear there until you add at least 2 IPv6 IPAlias VIPs so it passed testing a single VIP. I'll add a further test there.

ChrisJenk

@stephenw10 There seem to be 4 recommended paths for 25.11, unless I am misunderstanding something?

Screenshot 2025-12-19 at 14.49.25.png

I have applied them; should I revert them?

Any comments on my question about the use of a beta OS?

stephenw10

Oh, you're right my test box had an older package. Yes apply them unless you have good reason not to.

We moved to FreeBSD current/head because otherwise we were expending significant developer time backporting fixes and features. Effectively. We wrote a blog post about it at the time:
https://www.netgate.com/blog/pfsense-software-is-moving-ahead