pfSense

pfSense version

2.8.1-RELEASE (build 20250909-1629), Community Edition (Note: this build already includes the fix for #12947 / 2.8.0 / 25.07 -- see "Related issues" below)

Environment

• WAN: PPPoE, IPv6 Configuration Type = DHCP6 (DHCPv6 Prefix Delegation)
• LAN (igc1): IPv6 Configuration Type = Track Interface, parent = WAN, track6-prefix-id 0
• OPT1 (igc2): IPv6 Configuration Type = Track Interface, parent = WAN, track6-prefix-id 1
• OPT2 (igc3): IPv6 Configuration Type = Track Interface, parent = WAN, track6-prefix-id 2

Summary

Power-cycling a device directly cabled to a LAN-type interface that is configured for IPv6 "Track Interface" (track6) causes a brief physical link DOWN/UP on that interface. This triggers rc.linkup to process a track6 hotplug reconfiguration event for that interface.

As a side effect, IPv6 forwarding breaks -- not only on the interface that flapped, but on OTHER, unrelated track6 interfaces as well. The kernel repeatedly logs "cannot forward ... outif pppoe0" for traffic sourced from a completely different LAN segment than the one that flapped. The condition does not self-heal: WAN_DHCP6 gateway monitoring eventually reports 100% loss. The only way found to recover is a full teardown and rebuild of the WAN PPPoE/DHCPv6 session -- in our case triggered accidentally by re-saving the WAN interface settings in the GUI, which forces interface_dhcpv6_configure().

Steps to reproduce

1. Configure WAN as PPPoE with IPv6 Configuration Type = DHCP6 (Prefix Delegation).
2. Configure at least two other interfaces (e.g. LAN and OPT1) with IPv6 Configuration Type = Track Interface, parent = WAN, each with a distinct track6-prefix-id.
3. Physically power-cycle (or briefly unplug/replug) a device directly cabled to one of the track6 interfaces (e.g. LAN/igc1), so its physical link goes DOWN then UP within a few seconds -- this is a normal event, e.g. rebooting a directly-attached server.
4. Watch /var/log/system.log and IPv6 connectivity on the OTHER track6 interfaces (that were not touched).

Observed behavior (log excerpt, relative timestamps from T0 = first link DOWN)

T+0s kernel: igc1: link state changed to DOWN
T+0s /rc.linkup: Hotplug event detected for LAN dynamic IP address (4: ..., 6: track6)
T+58s kernel: igc1: link state changed to UP
T+59s /rc.linkup: Hotplug event detected for LAN dynamic IP address (4: ..., 6: track6)
T+59s /rc.linkup: HOTPLUG: Configuring interface lan
T+87s kernel: cannot forward src fe80:<zoneid>::<addr>, dst <GUA>, nxt 58, rcvif igc3, outif pppoe0
(repeats intermittently for about 3 minutes -- note rcvif is igc3 (OPT2),
a DIFFERENT track6 interface than the one that flapped, igc1)
T+91s kernel: igc1: link state changed to DOWN (second flap, same power-cycle event)
T+92s /rc.linkup: Hotplug event detected for LAN dynamic IP address (4: ..., 6: track6)
T+102s kernel: igc1: link state changed to UP
T+103s /rc.linkup: Hotplug event detected for LAN dynamic IP address (4: ..., 6: track6)
T+103s /rc.linkup: HOTPLUG: Configuring interface lan
... "cannot forward ... rcvif igc3, outif pppoe0" continues intermittently until ~T+264s ...
-- no further relevant log activity for about 6 minutes; outage persists on igc3's clients --
T+639s php-fpm: /interfaces.php: Configuration Change: admin ... Interfaces settings changed
T+643s php-fpm: /interfaces.php: calling interface_dhcpv6_configure.
T+645s ppp[PID1]: caught fatal signal TERM (existing WAN PPPoE session torn down)
T+647s ppp[PID1]: [wan] IPV6CP: Close event / LayerDown ...
T+648s ppp[PID2]: process started ... waiting for process PID1 to die...
T+648s ppp[PID2]: PPPoE: connection successful (WAN PPPoE session rebuilt from scratch)
T+652s check_reload_status: rc.newwanipv6 starting pppoe0
T+652s check_reload_status: rc.newwanip starting pppoe0
T+656s rc.gateway_alarm: WAN_DHCP6 Alarm:1 Loss:100% (transient, clears once new PD is in place)
-- after this point, IPv6 forwarding recovers on all track6 interfaces, including igc3 --

The delegated IPv6 prefix visible on the interfaces was also observed to be different before and after the WAN rebuild, confirming a fresh DHCPv6-PD exchange took place.

Expected behavior

A link-state change on one track6 interface should not corrupt IPv6 forwarding state for other, unrelated track6 interfaces, and recovery should not require a full WAN PPPoE/DHCPv6 session rebuild (nor manual admin intervention).

Workaround found

Re-save the WAN interface configuration in the GUI (Interfaces > WAN > Save) to force interface_dhcpv6_configure() and rebuild the PPPoE/DHCPv6 session. This reliably resolves the outage in about 15-20 seconds, but requires noticing the problem and taking manual action.

Related issues

• #12947 ("Old IPv6 addresses may continue to be used after DHCP or RA changes") looks like the closest relative -- same broad symptom class (stale IPv6 state persists until a manual release/renew or rc.newwanipv6 run). It was fixed for the case of the ISP silently renewing/changing the delegated prefix (fixed in 2.8.0 / 25.07). This report is running 2.8.1, which already includes that fix, but the problem still occurs here via a different trigger: a LAN-side link flap causing a track6 hotplug reconfiguration. This suggests the "stale IPv6 forwarding state until a full WAN rebuild" class of bug has more than one entry point into the same underlying condition.
• #15906 ("IPv6 delegated prefix changes upstream do not immediately update track6 interfaces") was closed as "Not a bug" for the ISP-renumber case, but the general symptom pattern (tracked interfaces not updating, requiring manual intervention or a long wait) matches what is described here, just on a much shorter time-scale and with a different trigger.

Additional notes

• The interface that flapped (igc1/LAN) recovered its own IPv6 configuration fine; the broken forwarding was observed on igc3 (OPT2), which was never touched.
• No dhcp6c/rtsold process crash was observed; dhcp6c remained running throughout under its original PID, which suggests the corrupted state is in the kernel routing/forwarding tables or in the interface-to-prefix tracking bookkeeping, rather than in the dhcp6c/rtsold daemons themselves.