Firewall default deny rule blocking LAN traffic?

[molnart]

Why is the Default deny rule blocking traffic between two hosts on my local network? I have no VLANs configured.

see screenshot below:
https://pasteboard.co/JnTcw6g.png

I pretty much suck at basic networking, but i don't see a reason why an unremovable firewall rule blocking LAN traffic should even exist...

Can please anyone explain it to me?

Not sure if this is relevant, but the host on x.20 is my working desktop computer and x.11 is an LXC container running on Proxmox.

[Styx13]

Hello,

I do observe the same issue.
Currently running OPNSense 20.7.6

I started observing the issue when I connected a docker container to one of the Linux bridge that is also used by my OPNSense VM.

I suspect that when some LAN traffic that goes through that bridge, both OPNSense (in a VM with a virtual interface using that bridge) and the containers see all the packets, weather it's LAN traffic or not.

And for some reason, OPNSense drops those packets using the default deny rule, which has no effect to the container because the container still received the packet directly through the bridge.

Now, I tried to add several rules in OPN sense to prevent blocking this packet (so the default deny rule does not fill my logs for those packets), but impossible. I tried to put a rule in the interface, in floating, i even tried a rule to allow everything temporarily just to test, and those packets are still caught by the default deny rule.

So my question would be:  is it possible to either:
 - add a feature on the interfaces in OPNsense in order to tell the interface to ignore LAN traffic ?
 - make the firewall rule be able to match on those packets so they don't get caught by the default deny rule ?

[chemlud]

...or simply disable logging for the default deny rule?

[Styx13]

...or simply disable logging for the default deny rule?

Well, It is not possible to disable logging for that rule.

Also it would not be a good idea if it was possible because now you would not be able to see what else your firewall blocked ..

[Styx13]

I finally found a solution to this here: https://pfsense-docs.readthedocs.io/en/latest/firewall/troubleshooting-blocked-log-entries-due-to-asymmetric-routing.html
While this is not really an asymmetric routing issue in my case (just that the OPNSense VM is connected to the same bridge as other VM/containers that causes it to see packets that do not need to go through OPNSense (i.e packets with source and destination on the same subnet)), it does cause the same symptoms and thus this solution works.

The manual fix they indicate consist in adding 2 rules: one in the interface of the network where the issue occur and one in floating. In my case just 1 rule was enough in the interface of the network I had the issue.
Make sure to select TCP protocol so you can check "any" for the TCP flags  in the advanced and set the state to sloppy.
Finally it does not matter if you make it a pass or block rule if you are in the same situation as me where the OPNSense host (KVM guest in my case) shares the same linux bridge as other VMs or containers as those other VM/containers will still receive the packets as long as they are on the same subnet.

Interestingly, while this fixes the issue, I do not see any log for this added rule even if I checked "Log packets that are handled by this rule". Not a big deal for me as my goal was to stop being flooded by it. However it is weird that while obviously the rule does something, it does not get logged somehow.

[elduderino]

I finally found a solution to this here: https://pfsense-docs.readthedocs.io/en/latest/firewall/troubleshooting-blocked-log-entries-due-to-asymmetric-routing.html
While this is not really an asymmetric routing issue in my case (just that the OPNSense VM is connected to the same bridge as other VM/containers that causes it to see packets that do not need to go through OPNSense (i.e packets with source and destination on the same subnet)), it does cause the same symptoms and thus this solution works.

The manual fix they indicate consist in adding 2 rules: one in the interface of the network where the issue occur and one in floating. In my case just 1 rule was enough in the interface of the network I had the issue.
Make sure to select TCP protocol so you can check "any" for the TCP flags  in the advanced and set the state to sloppy.
Finally it does not matter if you make it a pass or block rule if you are in the same situation as me where the OPNSense host (KVM guest in my case) shares the same linux bridge as other VMs or containers as those other VM/containers will still receive the packets as long as they are on the same subnet.

Interestingly, while this fixes the issue, I do not see any log for this added rule even if I checked "Log packets that are handled by this rule". Not a big deal for me as my goal was to stop being flooded by it. However it is weird that while obviously the rule does something, it does not get logged somehow.

Thanks for posting the solution, it worked for me, too. I also don't see anything in the log. Of note, the relevant pfsense link has now changed to: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html

[thogru]

Hi molnart,

In my opinion the question should be why (the hell) arrives traffic of your LAN in your OPNsense.

I would expect that the traffic in the LAN is handled by a one or more switches and OPNsense will never see this traffic.

Kind Regards
Thomas