Best Practice for Blocking Cross LAN Traffic by Default

[rkubes]

I have multiple LAN networks spread between different physical interfaces, VPNs, and VLANs.

I should also call out that I have WAN Failover configured, so all my "allow all outbound" (after all my block rules) are configured to use that Failover Gateway which only goes to either WAN device.

When I first started configuring my OPNsense device several years ago, I would go to each LAN and make a list of rules on each LAN that was "block all This LAN to That LAN." Then as I'd add new LANs over time, I'd need to remember to add another rule to every LAN to default block access to the other LANs. I'm realizing this is becoming a maintenance hassle to keep accurate.


Part of me is thinking, since my default "allow out" rules use the WAN gateway, they probably can't talk to the other LANs by default anyway (other than my explicit allow rules). But I don't know if it's "safe" to rely on that.

I'm also thinking I could make an alias that includes all IPs in the private ranges (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/? I can look that last CIDR up). Then just make a block rule on each LAN to catch anything that wasn't explicitly allowed, and then no longer have to remember to manually add each new Interface/net as I add more LAN segments.

I tried searching this topic, but a lot of the results were people wanting to figure out a way to filter traffic between devices WITHIN the same LAN (which don't make it past switches to the OPNsense instance anyway).

Still before I potentially send myself down another "bad" path, I wanted to understand what others are doing and what recommendations there are.

Thanks

[Monviech (Cedrik)]

https://docs.opnsense.org/manual/how-tos/security-zones.html

[rkubes]

The examples that document show are for "pass" rules, which the "quick" makes sense, since it's not a 'defaulting'/catch all else type rule.

I believe the order of operations will be "Floating Rules First", then within floating rules "Interface Group Rules first", and then getting down to individual Interface group rules, then individual interface rules.

Would it be 'correct' for me to make a "block" rule for the interface group of interfaces that I generally don't want having cross communication - but mark that rule as not "quick." And then within the individual interfaces, I'd still then be able to use "pass" rules to allow specific IPs/ports between those interfaces?

I want to avoid the "block all" rule being hit first and then not being able to get to the 'pass' rules within the individual interface.

Edit:
I realize a more efficient approach might be to edit my "allow all outbound" rule on each interface to exclude the Group's net - but I'm trying to avoid having to set the default block rules on a per interface basis to avoid forgetting.

[Monviech (Cedrik)]

I would avoid using non quick rules as they make the ruleset harder to understand. You can create the whole ruleset in floating. Just put the block rule at a spot you want it.

If everything is in floating you never forget.

You might also not need block rules if you avoid using "desitination any" firewall rules, but use an RFC1918 alias and invert it as destination. Inverting all private nets = the internet and never the local networks.

[rkubes]

Thanks for the follow up.

I did originally test the floating rule to "block all to private networks (via alias)" and not quick, but then found my per-interface "allow all to any" was basically overriding it. So I already adjusted my "allow all" rules to "allow all to !Private_Networks".

I agree, to your point, that's making the floating block (not quick) rule redundant at this point - since it would then just fall to the default block anyway. I may just disable it after I'm done reviewing logs for a few days to make sure everything's working as intended. For now, the specific logging is just helping me identify if there's any potential "allows" I missed.

In the future, I may rework my rules to all be floating, if that is indeed considered efficient. It would just be a bit of a migration effort initially. I can see how that would be easier to manage, long-term, though.

[Monviech (Cedrik)]

If you are on 25.7.3 and want to see where the future goes check out Firewall - Automation - Filter.