LAN traffic blocked by "state violation rule" — even with static ARP, allow-all

[DespairServices]

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.

[meyergru]

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.

[DespairServices]

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.

[meyergru]

On the same subnet, there will be no routes, but you cannot be sure which NIC will process packets when both are listening on the same wire. For example, broadcasts will be received by both interfaces.

I am quite sure the problem will go away when you unplug one interface. A more permanent solution would be to assign two separate IPs to the same NIC and bind the docker container to the virtual IP. Usually, this should not be a problem at all, because you can assign docker containers to any port you like, you do not have to use another IP for that. You must only ensure that no otherwise used ports are mapped to the containers.

The other option would be to separate the two NICs by putting them on different VLANs.