I am currently running iPerf again with a single gateway defined on ix2 to see if it fails in that configuration. If it does, I will redefine a single gateway on ix3 and test that interface as well to verify whether this is isolated to ix2 or is more reflective of both ix RJ45 combo ports.

In any case, I will probably relegate this specific device to applications where the four igc ports are sufficient as long as it's not a software issue.

Can you still replicate it if you just re-assign the WAN to ix3? If not it sure looks like a hardware issue.

Presently the 4100 expressing this issue is on my lab bench with ix2 connected via a different, short cat 6 cable to a Unifi USW Flex 2.5G. There is a single allow all ipv4 firewall rule for WAN and WAN2.

Short answer is there are four gateways defined in this lab test.

I am conducting the iPerf testing from a Linux box on the same subnet. I factory reset the appliance using the gui and subsequently configured ix2 as a gateway while leaving ix3 also configured as a gateway with no connection. I have left the default gateway set to automatic during testing. However, when it was in service the default gateway was set to WAN2 which was technically ix2.201 due to the fiber requirments while there was also still a defined dhcpv4 gateway for WAN. In service, there was no physical cable connected to the WAN (ix3) normally; however, I left it this way because in the event of catastrophic failure with the fiber ISP I could talk someone through connecting a cable modem to that interface without having administrative access to the software.

Do you have more than one gateways defined?

Spoiler

@stephenw10
It was in the unresponsive state this morning when I read these messages so I can confirm that bouncing the interfaces with ifconfig from a prompt does bring it back online. I think I probably had confirmed that before by using the checkbox for enable in the interrfaces gui.

I ran the double verbose and media flags while it was still locked up as follows:

ix2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
	description: WAN2
	options=4e138bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
	capabilities=4f53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
	ether 90:ec:77:32:ad:6d
	inet 10.14.55.172 netmask 0xfffffe00 broadcast 10.14.55.255
	inet6 fe80::92ec:77ff:fe32:ad6d%ix2 prefixlen 64 scopeid 0x7
	media: Ethernet autoselect (1000baseT <full-duplex,rxpause,txpause>)
	status: active
	supported media:
		media autoselect
		media 10baseT/UTP
		media 100baseTX
		media 1000baseT
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	drivername: ix2

And again, after bouncing the interface back to operational:

ix2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
	description: WAN2
	options=4e138bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
	capabilities=4f53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
	ether 90:ec:77:32:ad:6d
	inet 10.14.55.172 netmask 0xfffffe00 broadcast 10.14.55.255
	inet6 fe80::92ec:77ff:fe32:ad6d%ix2 prefixlen 64 scopeid 0x7
	media: Ethernet autoselect (1000baseT <full-duplex,rxpause,txpause>)
	status: active
	supported media:
		media autoselect
		media 10baseT/UTP
		media 100baseTX
		media 1000baseT
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	drivername: ix2

Finally, I pulled the hardware stats after it locked up as follows, for reference, while I don't have a copy of the before stats, I do recall particularly the local_faults: 10 is the same as before (probably the result of my testing pulling the ethernet cable to see how it recovered from that). Whereas the byte_errs and rx_errs both read 1 when I left it running iperf last night but now rx_errs reads 90.

Spoiler

I should also note the last few entries in the gateway log were as following continuous stream of the sendto errors:

Aug 21 15:45:52	dpinger	4092	WAN2_DHCP 10.14.54.1: sendto error: 50
Aug 21 15:45:53	dpinger	4092	WAN2_DHCP 10.14.54.1: sendto error: 50
Aug 21 15:45:53	dpinger	4092	exiting on signal 15
Aug 21 15:47:13	dpinger	59430	send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% alarm_hold 10000ms dest_addr 10.14.54.1 bind_addr 10.14.55.172 identifier "WAN2_DHCP "

An unrelated observation: Despite choosing the gui's factory default reset before testing the interface the logs after last night's lockup show the vnstat daemon is still concerning itself with vlan interfaces not showing in the present gui from prior configurations by disabling them.

The only halfway rational suggestion I'm getting from Google's AI given the existing evidence is to disable EEE (Energy Efficient Ethernet) with the following rational: "Energy Efficient Ethernet forces the Intel SoC port into low-power states during minor millisecond lulls in traffic. On combo-ports, this feature often triggers the exact singular, false link state changed message you are seeing. Setting this to 0 forces the RJ-45 side to stay powered at 100%." However, it links to a product brief from Intel's I350 server adapters so I'm not sure how likely this "solution" is.

I would also try ifconfig ix2 down; ifconfig ix2 up to see if that restores it.

I propose one more test: console or GUI, chose 'reboot' but use the 'reroot' instead of the 'reboot' option instead.

Thanks for writing up all the test you've done so far.
I've a 4100 myself, and had this weird observation about both (or one of ?) the ix, the two on the left, looking at the back.
I'm using one right now, the ix3 port, for 3+ years now. It's the WAN to my ISP router.
This ISP router has 3 1 Gbit/sec ports and one 2,5 Gbit/sec. If I use this 2.5 port with the pfSense ix3, 'all hell breaks lose'. ix3 setting is :

but this probably says more about the 2,5 Gbit port on the ISP router as the ix3 of the 4100's, which has a max speed of 1 Gbit anyway.
I know the 4 igc's can do 2,5 Gbit.

Where you, imho, nailed it : when fiddling with ix ports, they (or just one of them ?) can get like, let me call it 'stuck' and only a reset, a power reset, or a complete ix driver re init, done while the OS boots, loads the driver etc can bring it back in a working state.
Again, my is theory of what is happing.

As I'm not changing anything right now, and both pfSense as the ISP fiber router are UPS fed, the connection is stable.

I'll remap the ix3 to the right now not used ix2 this weekend as my WAN, to see if its all 'ix' based issue, or, let's give the issue a name : I have, like you, a flaky ix port ? We'll see, I report back.