Messages

Why are you using two NICs on the same subnet with different IPs? If you want to load-balance traffic, use a LAGG.

Out-of-state traffic is almost always a sign of asymmetric routing. That means, the response packets do not take the same route (or in this case, NIC) as the request packets. Thus, OpnSense dismisses them.

That would not be a problem if one of your NICs was passed through to VMs on your Unraid, because in that case, Unraid itself would own one IP/MAC and the VM would own another. But that does not seem to be the case.

It's because Unraid doesn't encourage modifying its internal config, particularly nginx. So to avoid messing with the base system, I'm running the relevant Docker containers and binding them explicitly to the second NIC (eth1, IP 192.168.1.41).

This setup has nothing to do with redundancy, failover, or load balancing — it's purely to expose services via subdomains with clearer separation at the network level.

That said, Unraid itself only listens on eth0 (192.168.1.40). I've explicitly removed the route through eth1, so the system has no reason to respond via the wrong interface (I think).

In theory, all system-level responses — including the ones being flagged as out-of-state — should only be coming from eth0. That's why this situation makes no sense from a routing perspective.

Context
I have a device running Unraid with two physical NICs, both connected to my OPNsense LAN network (192.168.1.0/24). Each NIC is assigned a unique static IP within the same subnet:

* 192.168.1.40
* 192.168.1.41

These addresses are correctly listed in:

* DHCPv4 leases
* ARP table

I've locked both IP–MAC mappings using static ARP entries in OPNsense to ensure there's no flapping or spoofing.

The Problem
Despite all of this, OPNsense blocks all packets coming from the Unraid device, regardless of which NIC/interface it uses.

Firewall log shows:
Default deny / state violation rule \[02f4bab031b57d1e30553ce08e0ec131]

This includes:

* 192.168.1.40:22 → 192.168.1.109:5388 (SSH response)
* Accessing the OPNsense Web UI from Unraid (192.168.1.1:80/443)
* All LAN-to-LAN traffic involving the Unraid IPs

What I've tried:

* Shutting down Docker completely on Unraid (no containers running)
* Manually adding pass-all rules on the LAN interface (IPv4/IPv6)
* Creating specific port allow rules (e.g., port 22)
* Moving allow rules to the top of the list
* Rebooting OPNsense and flushing the ARP table

None of this works. The only way to get traffic flowing is to disable the firewall entirely, which defeats the point.

What I suspect
Something deeper is breaking connection state tracking or classification. It seems like OPNsense is seeing return traffic from Unraid as out-of-state, even when it's part of a direct LAN connection with no NAT or interface boundary.

I cannot move to separate subnets per NIC; that's not an option.
Asymmetric routing is not the issue — I cannot even reach the OPNsense web UI from Unraid (port 80/443).
Binding containers to a NIC is out of scope — this is strictly an OPNsense LAN routing problem.

Any ideas or theories would be deeply appreciated.

Considering what is known about fried 14th gen Intel series now, it is well possible that Intel "fixed" something to further lower voltages or frequencies and botched stability during that the process.

Also, normally, CPU manufacturers intend to distribute their microcode updates to the mainboard and computer manufacturers, which can / should also adapt their BIOS settings accordingly. If you change the microcode only, it might break things.

So while you can patch security issues by applying microcode updates, you obviously can get more than you bargained for, when a CPU manufacturer "fixes" something else along they way...

Thanks — I had the impression that the "fried 14th-gen" issue mainly affected unlocked chips (i7/i9 K-series) under extreme overclocking or with unstable BIOS power delivery settings. I didn't think a locked i3 like mine would be impacted, especially since it's running at stock settings on a basic router board with no XMP or tuning options.

But I get your point — if Intel snuck in microcode changes to globally reduce voltage or clock margins, even locked chips could get hit by instability, especially if the BIOS wasn't updated to compensate.

Just wanted to chime in — I was getting sporadic full kernel crashes (trap 13 general protection faults) on boot with an i3-14100 and recent DDR5 setup. It wasn't consistent, but happened often enough to be a major issue.

After some digging, I traced it back to the os-cpu-microcode-intel plugin. Once I removed the plugin, the crashes completely stopped (at least so far).

Also worth noting: when I reinstalled the plugin just now to confirm, I got this message:

Message from x86info-1.31.s03_1:

===> NOTICE:

This port is deprecated; you may wish to reconsider installing it:

Abandoned upstream, fails to identify anything remotely new according to upstream issue reports.

It is scheduled to be removed on or after 2025-06-30.

===

Not sure if that was always there, but I suspect the included tooling might not play nice with newer 13th/14th-gen CPUs. If you're running modern Intel hardware and seeing weird instability, try removing the microcode plugin and see if it helps.

Hi all,

I'm running OPNsense 25.1.9-amd64, and I've installed the os-clamav (1.8_3) firmware plugin.

However, when I try to use it, I get the following message:

No signature database found, please download before use. The download will take several minutes and this message will disappear when it has been completed.

I clicked on "Download Signatures", but nothing happens. It's been stuck showing "Download Signatures [spinner]" for over 3 hours now with no progress or logs.

So far I have:

    Removed the ClamAV plugin and reinstalled it twice

    Rebooted after reinstall

    Tried triggering the download again — same result

Still stuck with no signatures downloaded.

Is there a known issue or workaround for this? Any CLI method to force the signature download or check what's going wrong?

Thanks in advance.