pfSense » pfSense Plus

Currently reproduced on pfSense Plus 26.07-RC.

This is not new to 26.07. I have seen the same failure on earlier pfSense Plus releases for some time, but I have not pinned down the earliest affected release.

WAN1 is configured as Static IPv4 on ixl3:

```
192.168.200.16/24
Gateway: 192.168.200.1
10 GbE
```

The upstream device can occasionally cause a burst of physical carrier transitions on the link. The carrier loss itself is external. The problem is what happens inside pfSense when those transitions occur quickly enough.

During the failure, ixl3 transitions DOWN/UP at roughly one-second intervals:

```
ixl3: link state changed to DOWN
ixl3: Link is up, 10 Gbps Full Duplex
ixl3: link state changed to UP
```

Each transition is picked up by the WAN hotplug path and results in repeated interface processing:

Hotplug event detected for WAN1 (wan) static IP address
DEVD Ethernet attached/detached event for wan
HOTPLUG: Triggering address refresh on wan (ixl3)
rc.newwanip starting ixl3
Reloading filter

While the carrier is flapping, these events continue to accumulate and pfSense repeatedly enters the WAN reconfiguration path.

Unbound is also being stopped and reconfigured during this sequence. Eventually, a start attempt fails with:

```
error: bind: address already in use
fatal error: could not open ports
```

A few seconds later the package subsystem logs:

```
Netgate pfSense Plus package system has detected an IP change or dynamic WAN reconnection - 192.168.200.16 -> 192.168.200.16 - Restarting packages.
```

WAN1 is statically addressed. The address did not change, but the hotplug/newwanip path still results in package restart processing.

Once the physical link settles, the system does not always recover cleanly. In this occurrence DNS remained unavailable, the WebGUI was unusable, and pfBlockerNG did not recover. I had to restart PHP-FPM and the GUI from the console using options 16 and 11, then manually start pfBlockerNG before the firewall returned to a normal state.

I also tested with gateway monitoring actions disabled. There was no change in behavior. These are kernel-reported ixl3 carrier events and don't seem to be dpinger gateway-state transitions.

The interesting part is the service lifecycle around the repeated interface events. The logs show rc.newwanip/filter processing being entered repeatedly, followed by an Unbound start failing because the DNS socket is already in use. I do not have process tracing from the failure, so I cannot say whether multiple rc.newwanip instances are executing concurrently or whether the collision is occurring farther down the service reconfiguration path.

Either way, the interface event path appears capable of being re-entered faster than the associated service state can settle. Once that happens, the system can remain partially broken even after ixl3 has returned to a stable UP state.

Full sanitized logs with timestamps are attached.