Messages

Ok, so the ARP issue was due to OPNsense bridge I had configured on 3 ports getting all confused where to forward the ARP reply to it seems. As soon as I removed the bridge and used a single port instead, it all went away. Best to stay away from bridging and use a separate switch instead I'd say. Perhaps this may help someone in the future.

Somehow I have a sneaky suspicion this has something to do with the bridge being set up on 3 ports in OPNsense.

Hi,
I'm hoping anyone here might be able to give me some pointers. I'm trying to debug an ARP issue I'm seeing between an OPNsense box and an OpenWrt router. Without going into too much detail yet, when I run "tcpdump -ennqti igc2 arp" on the OPNsense box ("igc2" is where one end of an ethernet cable is connected to) and I also run "tcpdump -ennqti lan4 arp" on the OpenWrt router ("lan4" is where the other end of the ethernet cable is connected to), I can see ARP requests and responses passing through on both ends. Except for some, and only for some specific clients, I can see the ARP request on the OpenWrt leaving, then on the OPNsense arriving, then the reply on the OPNsense going back, but nothing else on the OpenWrt. As if the response gets dropped after logging the reply on the OPNsense. And this is only for clients that connect via wifi on the OpenWrt router (dumb AP) and it seems to be only requests for the interface gateway IP, which in my case is the bridge0 device that bridges a few ports (including igc2).

What else is in play between tcpdump on OPNsense and tcpdump on OpenWrt?

Any help would be appreciated.

Indeed you are correct sir. Much appreciated.

It's the top "Automatically generated rules", notice it's "last match".

I am really baffled by this. I have a firewall rule that sometimes gets missed, screenshots attached. What am I missing? Why does it sometimes endup with the standard floating rule "Default deny / state violation rule"?