Best Firewall Feature to Implement (V)LAN Interface Isolation? Security Zones?

[Sinister Pisces]

Hello,

New user here; I'm a bit overwhelmed with all of OPNSense's features at the moment, and not sure which feature is the best to use in my situation. So, I'm not asking exactly how to do this, but rather what feature(s) are best suited to do it, so that I can focus on learning them.

What I've got:

• Default, primary LAN interface;
• multiple VLANs that are children of the default LAN interface;
• The default LAN interface's "pass all traffic" rules on the default LAN and all the VLANs.

What I know how to do now:

• Manually create desired rules on a specific interface;
• Clone those rules to another interface; and
• Manage each interface's rule set separately.

That's not ideal with more than a couple of (V)LAN interfaces.

What I want to do:

• Set up a default set of rules for all internal networks (e.g., (1) block inter-(V)LAN interface traffic, allow access to WAN interface);
• Easily/automatically apply those rules to all (V)LAN interfaces so they're isolated but able to access the internet until I decide what, if anything, more specific I need to do with the firewall rules on those interfaces.
• Be able to modify the default rule set in a single, centralized location and have the changes apply to all interfaces using those rules.

Question: I think the solution here is to use Groups to create Security Zones per the manual, but before I jump down that rabbit hole, I wanted to make sure I wasn't missing some other more appropriate feature, or otherwise deviating from recommended practice. I'd rather not teach myself the wrong way to do something. :)

tl;dr Is this the recommended way to get started with zone-based firewall stuff, or am I missing something?

[Monviech (Cedrik)]

Id recommend trying, youre on the right track.

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

[julsssark]

I found this a very helpful setup guide for configuring VLANs and interface groups (ignore the parts about VPN if you don't need that):

https://schnerring.net/blog/opnsense-baseline-guide-with-vpn-guest-and-vlan-support/

It may not be the optimal way if you have a large number of VLANs, but it works great for my 6 VLAN home network.

[Monviech (Cedrik)]

I recommend using the opnsense guides instead since there have been new features implemented in 25.1. They are the most up to date.

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

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

[pfry]

Agreed (with all).

Is this a practical exercise for personal use, or are you looking into firewall philosophy in a more general sense?

[EricPerl]

In my case, the physical network topology was entirely driven by the house wiring (fan-out from comm panel, further fan-out in some rooms).
So I relied heavily on VLANs for segmentation/isolation.

I just took a look at the security zones guide.
All I see is another layer of indirection (and thus complexity) with questionable benefits (for my use case).
I wonder why there were so many VLANs in the first place and which principle was used to determine their existence and which devices belonged in each.

Personally, I chose a ring approach (along the lines of network, management, productivity, fun, guest, iot...).
Less trusted stuff is not allowed to access more trusted stuff.
The opposite is not necessarily true (e.g. fun, guest and IOT are largely isolated).
I allowed things on a need to basis, more or less granularly.
During the initial setup, I relied heavily on the FW live view to identify blocked traffic and created rules as appropriate.

By default, nothing is allowed IN the firewall from a VLAN. I decided what to let IN. Allow rules only. No block rules for me.
And yes, there's a bit of cloning involved, but that's a one-time effort.

I understand the benefits of grouping in general with regards to management in general. I just don't have enough things to group to bother.
I believe it could be useful in a commercial setting. It seems overkill in a home setting.
Unraveling group memberships when rules no longer apply to the entire group is not fun.
And I really hope the group rules are visible at the interface level (like floating rules)...

YMMV

[Sinister Pisces]

@Monviech: Thanks for the links to the guides. Those were very helpful; the re-write on the Security Zones one in-particular really clears up what they are and how they work ...

... and makes me realize they're not really what I want.

Benefit of Zones�
Defining uniform policies between zones reduces the number of rules and the complexity of the ruleset. For example, allowing all networks in Trust to access HTTPS services in Untrust can be achieved with a single rule.
Without Zones (6 Rules):

• Allow HTTPS from igc0 to igc3
• Allow HTTPS from igc0 to igc4
• Allow HTTPS from igc1 to igc3
• Allow HTTPS from igc1 to igc4
• Allow HTTPS from igc2 to igc3
• Allow HTTPS from igc2 to igc4

With Zones (1 Rule):

• Allow HTTPS from Trust to Untrust

Additionally, a zone-based ruleset allows new interfaces to be added without requiring additional rules, reducing administrative overhead. This approach also enhances configuration clarity, simplifies troubleshooting, and streamlines audits.

That's incredibly powerful ... if you're doing Level 3/inter-VLAN routing all over the place.

I don't have a 10 GbE uplink from my core switch to my OPNSense box, for one, and I'm also designing my network to route traffic across VLANs as little as possible and maybe never if I can get away with it. My core switch isn't a level 3 switch, and I think only one of my edge switches might be.

I could still see it being useful for me if I had a lot of VLANs with identical rules, but that's not exactly how my network is coming together. I think this is almost the feature I wanted.

@pfry , I had intended to put this in production, but to make it easier to manage interface firewall rulesets with a lot of repeating rules, but I don't really think that's what this is actually meant for. It's a way to harmonize interfaces in the same logical zone (trusted, untrusted, wifi, etc.).

I think the feature I want doesn't exist yet. I'm not concerned with managing "zones" of interfaces; I want to maintain a library of rule templates grouped by function. What I was really wanting was not a way to organize my network topology, but to makemake linked clones of a base set of firewall rules.

This feature doesn't seem to exist yet, so everything that follows is a fantasy feature request. :P

Something like this:

• Define a Template Rule Group that contains all the rules an isolated LAN interface needs (e.g., allow DNS lookup, etc.), with a placeholder for interface name;
• Define an Internet Access Template Rule Group that contains all the rules an interface needs to get out to the WAN.
• Define other Template Rule Groups as needed.
• When configuring an interface's firewall rules, tell it to link to the Template Rule Groups that it needs, and then add rules specific to that interface.
• The interface pulls in the templates and just substitutes the name of the interface for the placeholders in the Template Rule Group.
• Updating the template updates those rules everywhere the template is used.
• So, in effect, only one copy of each rule set exists, and rule sets can be combined at the interface level, including with non-template rules.
• That way, as I grew my knowledge of, e.g., security for incoming connections, and refined the "interface security - incoming connections" rule set that was linked to all my (V)LAN interfaces by adding, for example, Spamhaus DROP IP blocking, I'd only have to maintain a single set of rules in a single place to have the new rule applied across as few or as many (V)LAN interfaces as are linked to that template set.

My original motivation was to make maintenance easier. Initial setup isn't so bad, but realizing you can do something better and then having to change the same rule every place it exists (and remembering every place it exists) seems like it could get overwhelming fast. Or at least be an error-prone process.

I think, especially as I'm learning and will be refining my firewall rule templates, the best manual way to do this is to maintain an organized list of firewall rules based on function, and a list of interfaces with what rules should apply to them, and periodically update those lists with my latest knowledge and then go through and make sure I've actually got the firewall rules set to what my documentation says they are.