Management VLAN Firewall Rules: First Custom Rule Set, a Few Questions

[Sinister Pisces]

AFAIK, yes, your understanding is correct. In absence of a listener, the FW rule isn't doing much.
The recommendation is to let the GUI listen on all interfaces and control access via rules.

Anti-lockout ports follow the settings in the GUI (HTTPS & SSL ports, 80 redirect enabled).
You don't get the choice of the interface. lan if it exists, opt1 if it does not, wan as fallback if it's the only interface.
It's a safeguard so it's designed to be resilient to interface removal and additions. As is, if you remove your management interface, you're SOL.

Now that I've seen it in action, the bolded part makes more sense. If the Firewall is configured properly, nothing gets to the listeners on the interfaces I don't want to be listening, right? So, there's no benefit to disabling the listeners in addition to setting correct firewall rules, correct?

Just so I can understand better, when would you want to disable some interfaces from being able to listen for HTTPS/SSH connections? I can understand why it's not recommended now, but I'm now curious when it would be useful.

Please, recheck this.
Normally you see a single rule for both, SSH and webGUI.
But there are separated block rules for both services for the source "sshlock" (or similiar).

Sorry for not posting more screenshots. The forum really doesn't like the screenshots I paste in here, and usually refuses to upload them. It was a bit of effort to get this one down to 256 KB.

Here's the current ruleset on my management VLAN. I've disabled the anti-lockout rule in Firewall > Settings > Advanced: the anti-lockout rule no longer appears in the auto-generated rules for the management VLAN or under Firewall > NAT.

[EricPerl]

You need both the server to listen and allow the client to reach the server...
The savings of disabling the listeners seem minimal.
Personally, I strive for minimal configuration to get the job done...
Disabling failsafe defaults is not my thing.

I imagine that if you wanted to use web proxies on some interfaces while keeping the WebGUI on the standard ports, then such functionality is required.
I haven't used the platform long enough to have history. Conjecturing on possible use of functionality is not really my thing either...

And yes, it's sshlockout (only blocks things) that's split across 2 rules.
Anti-lockout is ONE rule (Port forward) for 2 or 3 ports.

[viragomann]

So the screenshot shows, what I'd expected.

The red marked rules are the sshlockout block rules. This are automatically added and are meant to block certain source addresses, which tried to login with wrong credentials or similiar attacks.
The wand indicates automatic rules.

The green marked rules are manually added to the VLAN10 interface, wich obviously is management.

But there is nothing odd at all.

[Sinister Pisces]

Thank you both. Glad to hear this looks basically correct for what I'm trying to do. I'm sure there are better, easier-to-manage ways to go about it, but hopefully I can learn those later. (I am aware that Security Zones exist and are something that would probably simplify my life long-term, but figuring out how to get started with them is a bit intimidating for now.)

I did restore the listeners on the SSH and HTTPS web GUI ports to All Interfaces. Like y'all said, if it doesn't really make things any more secure than just using proper firewall rules, there's no reason to change the defaults. The Anti-Lockout Rule is still disabled, since I don't want OPNSense administration happening on the default LAN.

In the meantime, I just wanted to get my management interfaces isolated (and the rest of my VLANs isolated, which will be simpler), so I can move on to setting up other things. I've got a pile of half-set up projects (including OPNSense, Proxmox, and TrueNAS) and really need to get them all into a basically fully configured state before my computer eats my notes or something. :P