"Quote from: greY on Today at 05:52:39 AMHiyeah i had that same idea today.... its like when i switch the assignment something remains em0
I'd try to export configuration, do the replacements/re-mappings (simply search and replace) there and import it back.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages1
#1
25.7, 25.10 Series / Re: LAN breaks when moving from onboard em0 to i350 (igb1), WAN fine- what did i mis
Today at 07:31:59 AM #2
25.7, 25.10 Series / LAN breaks when moving from onboard em0 to i350 (igb1), WAN fine- what did i mis
Today at 02:26:36 AM
Hardware:
Supermicro X10SLM 1U
OPNsense
Onboard NICs: originally igb0 + em0
Added Intel i350-T4 (now shows as igb0–igb3)
After install, the onboard NIC that used to be igb0 is now igb4
No VLANs
AdGuard for DNS (including IPv6 filtering)
A few static IPv6 assignments
Background:
I installed an Intel i350-T4 because the onboard NICs seemed flaky occasionally, and several threads recommended the i350 as a solid choice.
Once installed, the first port on the i350 became the new igb0, so I reassigned WAN to that (since WAN was originally on igb0). WAN worked fine.
LAN was previously on em0, so I went into Interfaces → Assignments and changed LAN to igb1.
That's where things fell apart.
Symptoms after moving LAN to igb1:
Wi-Fi devices appeared to still work
Wired computers could not reach the internet
Some local hosts resolving through AdGuard rewrites still worked
DNS logs showed queries hitting AdGuard, but browsing failed
Reboots changed behavior (sometimes slightly different failure)
I don't use VLANs, bridging, or anything exotic — just standard LAN/WAN plus AdGuard and some static IPv6.
After several hours of troubleshooting, I changed LAN back to em0, and everything immediately worked again.
Current working setup:
WAN = i350 (igb0)
LAN = onboard (em0)
Network stable again
My question:
What would cause LAN to break simply by moving it from em0 to igb1, especially considering the onboard NIC renumbering (igb0 → igb4)?
Possible culprits I'm wondering about:
stale interface bindings left behind
spoof-checking behavior tied to old interface identity
NAT expectations based on the previous LAN interface
IPv6/RA/static address behavior still tied to em0
FreeBSD driver/ordering oddities when NIC indexes change
I expected this to be a straightforward interface move, but clearly something subtle is happening. I'd like to understand why before trying again.
Thanks for any insight — especially from folks who have swapped NICs on existing installs.
Supermicro X10SLM 1U
OPNsense
Onboard NICs: originally igb0 + em0
Added Intel i350-T4 (now shows as igb0–igb3)
After install, the onboard NIC that used to be igb0 is now igb4
No VLANs
AdGuard for DNS (including IPv6 filtering)
A few static IPv6 assignments
Background:
I installed an Intel i350-T4 because the onboard NICs seemed flaky occasionally, and several threads recommended the i350 as a solid choice.
Once installed, the first port on the i350 became the new igb0, so I reassigned WAN to that (since WAN was originally on igb0). WAN worked fine.
LAN was previously on em0, so I went into Interfaces → Assignments and changed LAN to igb1.
That's where things fell apart.
Symptoms after moving LAN to igb1:
Wi-Fi devices appeared to still work
Wired computers could not reach the internet
Some local hosts resolving through AdGuard rewrites still worked
DNS logs showed queries hitting AdGuard, but browsing failed
Reboots changed behavior (sometimes slightly different failure)
I don't use VLANs, bridging, or anything exotic — just standard LAN/WAN plus AdGuard and some static IPv6.
After several hours of troubleshooting, I changed LAN back to em0, and everything immediately worked again.
Current working setup:
WAN = i350 (igb0)
LAN = onboard (em0)
Network stable again
My question:
What would cause LAN to break simply by moving it from em0 to igb1, especially considering the onboard NIC renumbering (igb0 → igb4)?
Possible culprits I'm wondering about:
stale interface bindings left behind
spoof-checking behavior tied to old interface identity
NAT expectations based on the previous LAN interface
IPv6/RA/static address behavior still tied to em0
FreeBSD driver/ordering oddities when NIC indexes change
I expected this to be a straightforward interface move, but clearly something subtle is happening. I'd like to understand why before trying again.
Thanks for any insight — especially from folks who have swapped NICs on existing installs.
Pages1
