I have a very simple setup which consists of a supermicro 1he appliance with intel nics running opnsense. It has an intel j1900 cpu.
I always run updates when they are released by opnsense and never had any issues, until now.
After updating to 25.7.2 my wan interface suddenly can't make an fysical network link to my cable modem. The link-led flashes on and of on my modem. When i fixate the speed to 100mbit fullduplex the link works again. But on autosense , which normally results in 1000base full duplex the link fails. I disabled all hardware offloading for the nic but that seemed to make no difference. In order to keep access to the internet i now have to run on 100mbit otherwise the link fails.
The nics in my appliance are two intel i210 nics, which until now never have gave my any problems. Can this please be fixed so that i can use full bandwith of my internet connection again?
I have what is probably a similar board - Supermicro X10SBA, J1900 with 2 Intel 210 NICs. I just did the upgrade to 25.7.2, and my NICs are both showing connection at 1 Gbps (the link indicator LEDs are glowing amber, which the user's manual says means 1 Gbps), and I am getting well over 100 Mbps even over an old wifi N connection. So I don't think there's anything inherent about the upgrade that would cause your issue. I'd look at configuration issues (start with factory defaults and see if that gets you full speed?) and maybe even a bad ethernet cable (I had one of those recently tie me to 100 Mbps). Good luck with your troubleshooting...
A new kernel was installed, but I don't suspect that's your issue.
I just went 25.7.1.x to 25.7.2, no issues.
I run one of the chinese N150 mini pc's that have intel 2.5G copper and two sfp+.
Pasting the notes for 25.7.2 here
QuoteHere are the full patch notes:
system: increase log file download timeout to prevent exit before data has returned
system: HTML decode entities when generating new QR code for user
system: add missing timestamp formatter in snapshots
system: prevent the root user from changing its name
interfaces: capture netmap ring when listening on interfaces in netmap mode
firewall: skip reply-to for inversion rules
firewall: remove unused "set loginterface" clause
firewall: additional statistics for alias grid
firewall: fix shaper reset button
captive portal: preparations for SSO identification support
dnsmasq: swap hosts and domains tab for consistency reasons
dnsmasq: allow disabling local for DHCP domains
firmware: abort on what appear to be partial updates due to obscure file errors
firmware: store update and upgrade logs in edge cases
firmware: opnsense-version: support file based -R option
firmware: opnsense-update: support -g for update log view
firmware: remove tier 2 workaround for Zenarmor plugins
firmware: add date to modal header
kea-dhcp: ignore encoding errors in lease parser
intrusion detection: fix and simplify grid search in download tab
ipsec: passthrough networks setting missed "allow new" flag
ipsec: add firewall rules skip option for VTIs
ipsec: deprecate legacy stroke and implement swanctl for overview
isc-dhcp: allow static mapping export for disabled entries
openvpn: add nopool directive
unbound: configurable top domain list length in reporting view (contributed by sopex)
unbound: remove unknown model reference and protect/simplify remaining one
wireguard: move backend scripts to proper location
backend: added IPv6 bracket helper for templates (contributed by BPplays)
lang: updates for Chinese, Czech, German and Greek
mvc: improve resilience of VPNIdField and LinkAddressField
mvc: repair side affect of getDescription() change causing performance regressions
mvc: modify existing and add missing descriptions in models
mvc: set default validation message for CertificateField
rc: make changes to php,var,tmp bootstrap
ui: fix language selection for low vertical resolution screens (contributed by sopex)
ui: hide header of the picture widget on the dashboard (contributed by sopex)
plugins: os-clamav 1.8.1[1]
plugins: os-crowdsec 1.0.12[2]
plugins: os-frr 1.46[3]
plugins: os-shadowsocks 1.2 switches to shadowsocks-rust
plugins: os-smart 2.4 adds extended info option (contributed by poisonbl)
plugins: os-telegraf 1.12.13[4]
plugins: os-theme-advanced updates logos (contributed by Raushan Patel)
src: route: fix "route -n monitor" when its output is redirected[5]
src: add a new sysctl in order to differentiate UEFI architectures[6]
src: libarchive: merge version 3.8.1[7]
src: lagg: fix if_hw_tsomax_update() not being called
src: wg: add support for removing allowed-ip entries and assorted cleanups
src: ovpn: support multihomed server configurations and assorted cleanups
src: netlink: fully clear parser state between messages
src: udp: fix a inpcb refcount leak in the tunnel receive path
src: p9fs: assorted fixes
ports: ca_root_nss / nss 3.115[8]
ports: krb5 1.22[9]
ports: libpfctl 0.16
ports: lighttpd 1.4.81[10]
ports: perl 5.40.3[11]
ports: php 8.3.24[12]
ports: py-jq 1.10.0[13]
Stay safe,
Your OPNsense team
Quote from: jjelliott on August 22, 2025, 02:17:28 AMt 1 Gbps (the link indicator LEDs are glowing amber, which the user's manual says means 1 Gbps),
You say it's 1G. Should it be different?
QuoteYou say it's 1G. Should it be different?
No, the OP said his links only worked at 100M, and my response was simply that mine are working at a higher speed than that. On an old wifi N laptop I'm getting about 160 Mbps, and the amber LEDs on the ports themselves indicate 1 Gbps connections. (The user manual for my board says if the connection were 100 Mbps, the LEDs would be green.)
Quote from: lebowski on August 21, 2025, 10:53:44 PMThe nics in my appliance are two intel i210 nics, which until now never have gave my any problems. Can this please be fixed so that i can use full bandwith of my internet connection again?
I would try to unplug and then plug in the network cable from both your OPNsense and the cable modem. If that does not fix it, then try with fully powering off (may need to unplug the power cable) both devices. If the SuperMicro does have an BMC module, wait for one or two minutes until it is fully off (NIC LED may be an indicator).
Hopefully this helps and the NIC will be able again to properly do autosense and sync with 100 Mbit/s.
I did unplug the ethernet cable from my cable modem. This resulted in having an 100mbit link (after i set the nic speed manually to 100mbit). On autosense , even after unplugging the cable, it keeps negotiating link speed, the green nic led keeps flashing on and of slowly, but there is no final link. I can't replace cables because my cablemodem and opnsense firewall are on different floors and i use fixed cables (cat6/7 pimf high quality shielded). I did power cycle the cable modem, i did reboot my opnsense appliance but did not give it a cold reboot.
It's ok for me to do a reinstall, it should be a nice oppurtunity to do a fresh install after years of updating existings installs, replacing its ssd at the same time. My only concern is that i use dnscrypt-proxy and i dont know how to backup the whitelist that i manually made. When i backup my current opnsense config and restore it to a new installation, will all this be reinstalled correctly in the new install, including the dnscrypt-proxy whitelist?
What about hard setting the iface? Sometime auto-neg no worky.
You said you set it manually to 100Mb, what about setting to 1G FD?
Quote from: lebowski on August 21, 2025, 10:53:44 PMWhen i fixate the speed to 100mbit fullduplex the link works again.
Daft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
Quote from: hedders on August 23, 2025, 07:07:24 AMQuote from: lebowski on August 21, 2025, 10:53:44 PMWhen i fixate the speed to 100mbit fullduplex the link works again.
Daft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
It would be very odd coincidence though. I think OP just did an upgrade from GUI, then link was bad, then messed around with the cable. So if it was good from the start then it should be good after the upgrade........ would be my expectation.
Maybe look at dmesg to see if there's any driver complaint. kldstat to see what's loaded now, etc. (your if driver may not be a klm, etc).
Also check if the proper driver is listed from kernel (the if_ items, etc), because there was a kernel update.
ls /boot/kernel | grep -v kernel
My ifconfig -a shows me "igc" for the coppers, so in kernel list i see "if_igc.ko", etc.
Sometimes its a cable, many times its the nic driver.
Quote from: hedders on August 23, 2025, 07:07:24 AMDaft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
It only takes a break (or a stuck pin, or some dirt) in pins 4, 5, 7 or 8 and the connection willl never go above 100Mbps.
Changing the cable would always be my first check. A quick look in the two sockets with a torch would be my next quick check!
Quote from: tofflock on August 24, 2025, 12:00:43 AMQuote from: hedders on August 23, 2025, 07:07:24 AMDaft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
It only takes a break (or a stuck pin, or some dirt) in pins 4, 5, 7 or 8 and the connection willl never go above 100Mbps.
Changing the cable would always be my first check. A quick look in the two sockets with a torch would be my next quick check!
Yes, the 1 Gbit/s does need all 8 wires in the cable to be fine. In case your Ethernet cable may have a sharp bend (or had one in the past) one of the wires in it could be partially or fully broken, which will give you loose connection and so the auto negotiation does fail.
It could be an issue with the network driver, but I don't think that this minor OPNsense update has any NIC driver updates, as the underlying FreeBSD did not have even a minor update (I think).
If you did not touch the system or cable during the update / reboot to 25.7.2, then some thermal issue cause from the update (e.g. higher CPU / Network traffic) could have caused that an already damaged cable now broke completely.
At least I would also try with a different Ethernet cable, and also check that the sockets on both ends do not have any dust in it and still look fine.
If I upgrade form the GUI sitting in my den and the fw is in the computer room, how would a cable suddenly go bad? Could it be just from the vibration of a reboot, maybe from the BIOS sound if turned on? It's not adding up for me, but try another cable since the original was already touched.
Well, i haven't sit still, tried a lot of things. I pulled my supermicro opnsense appliance from its rack, cleaned it, replaced it's ssd, noticed there was a bios firmware upgrade for the supermicro appliance so upgraded that too, did a complete fresh zfs reinstall of opnsense.
After that, pulled most network cables from their sockets going from and to the cablemodem and cleaned them with contact spray (i think this is called deoxit in the states), tried a different network cable going from cablemodem to the wall network socket (from there my wan cable goes to my rack which sits in my attick), and after all of this: still no luck. My wan interface only works if i put it on fixed 100mbit rate.
To clearify my situation: before and after updating to 25.7.2, i did nothing to my network cables, they all are nicely installed in regulation tubes in my walls, going from (shielded) socket to (shielded) socket. Never had any issues with these cables.
I also noticed i was previously running opnsense in bios csm mode, now i disabled all legacy stuff and are running in native uefi mode. Also changes nothing.
from dmesg:
Quote[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff,0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: ##:##:##:##:##:##
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
Same goes for igb1
It appears that if_igc.ko is loaded.
Now i got this brilliant idea 😂 of placing a small ethernet switch inbetween the cablemodem and the network cable going to the firewall. Maybe this will help shed some light to the current situation. Haven't done it yet, but if it will result in a solid stable 1gbit link going all the way from my opnsense firewall to my cablemodem, then i would know that my opnsense box and the network cables arent the culprit. I didnt have the time to try it yet, but this will be my next "test". I have had some downtime from my isp recently where they where working on their network, and i want to rule out that they pushed a dodgy firmware to my cablemodem.