I’ve been playing around with 3rd Gen Intel platforms for a little while now and trying to get a WAN address on my pfSense but I cannot seem to manage to get any sort of response from my ISP when the modem/router combo is set to bridge mode.
I can get an IP no issue on the WAN when I connect an end-user device, and have been able to get pfSense working with the SAME NIC on my Ryzen PC (Virtualized even with PCIe Passthrough) but for some reason, the 3rd gen Intel machines I have just…aren’t supporting it?
The MAC address shouldn’t be the issue because of course, this is the same PCIe NIC used in all the configurations I’ve tried (Xeon processor even).
Basically, pfSense comes up, when it attempts to configure the WAN, the NIC will flap off then on once, and then just get NOTHING from the ISP.
Is the machine uefi trying to pxeboot from a WAN port by any chance?
The initial/accidental pxe DHCP request might be confusing whatever is supposed to hand out the IP to pfsense once it gets to the os.
Other than that, you could grab a pair of USB Ethernet adapters, bridge them and mitm the DHCP requests from your working device vs pfsense. And store them in a file, then open in Wireshark and compare what you see.
And for capturing the DHCP requests, pfSense has its own packet capture tool and what I see from the capture is that there’s just literally no ACK returned.
I see tons of DHCPDISCOVER but never receive a DHCPACK in return on the WAN interface.
From what I can tell, the difference is literally just the UEFI version. I can get the same NIC working fine on the modem using a newer Ryzen-based motherboard, using a laptop with a USB NIC gets a WAN address too but with the NIC connected to an older motherboard, no go.
Though I’ve noticed a common behaviour across 3rd gen intel whether it’s a Xeon or a Core i5/i7. Every time, the NIC will turn off and then back on when it’s time to get an address, but only once. It’s as if it’s putting the NIC into some specific mode when performing negotiation?
Not sure what I would be looking for in that situation.
Hmm, that could be interesting to inspect. I suspect that the packets themselves have different flags activated, but won’t know without an actual wireshark capture rather than relying on pfSense’s packet capture tool I think.