Firewall rules in vs out direction and processing order

[clarknova]

OPNsense 24.7.7

This firewall host has a WAN interface (lagg0_vlan17) with a publicly routable IPv4 address and multiple LAN interfaces. I created a floating rule to prevent packets with rfc5735 (local and invalid) destination addresses from being leaked on to the internet. I also created an outbound rule on the WAN as a last-resort catch-all rule for the same purpose. These two rules look like this:

Code: [Select]

block return in inet from any to <rfc5735> label "c66bd7ebe022fedb2fdd2d7bdfbf7ee5"
block drop out log quick on lagg0_vlan17 inet from any to <rfc5735> label "f8905c704b9481e346fca8eebfa98578"
To my surprise, I'm seeing packets logged by the second rule. I believed that packets would be evaluated against 'in' rules as they entered an interface, and against 'out' rules as they exited an interface. If this assumption is correct, then only packets originating from the firewall itself should match the second rule, as any packets from local hosts should have matched the first rule at ingress and been dropped. Yet I'm seeing packets in the log that did not originate from the firewall. So what have I got wrong?

[dseven]

Copying from the WebUI for floating rules:

"Floating rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed) only if the "quick" option is checked on a rule. Otherwise they will only apply if no other rules match."

So I think you need to make your first rule "quick"

[clarknova]

I can make the first rule quick and move it to the bottom of the every interface's ruleset, but this is less elegant and leaves two questions unanswered.

• How can the first rule operate on a packet at egress before the second rule operates on the same packet at ingress?
• Why are some packets dropped by the second rule while others are not? I have verified this by enabling logging on the second rule.

[clarknova]

I discovered another pass rule on the ingress interface that was passing the packets in question, so they never matched the first rule. That explains how they were caught by the egress rule on the WAN, which did its job.