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

[Sinister Pisces]

Hello,

I just set up a management VLAN; the first VLAN and firewall rules I've ever done. I'm almost there, but I could really use a sanity check.

I've included a couple of screenshots. I'd really appreciate any advice on whether these rules actually do what I think they do. Thanks!

Goals

• Allow access to DNS and NTP for all clients on the VLAN.
• Allow access to OPNSense web UI and SSH on custom ports for all clients on the VLAN.
• Do not interrupt hosts on the management VLAN's ability to talk to each other via standard HTTPS/HTTP.
• Allow access only to internet (block all other VLANs).

Questions based on screenshots:

• Do I also need allow rules for Destination: MGMT Address for default HTTPS/HTTP/SSH ports for devices actually on the management network (the firewall has a custom port; most clients use the defaults)? Right now, it's not obvious to me how non-OPNSense hosts on the management VLAN talk to anything on the Management VLAN using default HTTP/HTTPS/SSH ports.
• If yes, should the custom HTTPS/SSH port rules for OPNSense be set to Destination:This Firewall, or Destination: IP address of the OPNSense firewall on this VLAN?
• Thanks!

Current Custom Ruleset (Not Applied Yet)


In the alternative, if the above is incorrect, I think I'd need two additional rules to allow traffic on the default HTTPS and SSH ports.

[viragomann]

I looks all correct.

• Do I also need allow rules for Destination: MGMT Address for default HTTPS/HTTP/SSH ports for devices actually on the management network (the firewall has a custom port; most clients use the defaults)?

For accessing OPNsense? No, since you use alternative ports, you don't need to allow access to standard ports.

On the internal lan interface OPNsense adds the "anti-lockout rule" for WebGUI and SSH automatically.
So if the Management subnet is the lan in fact, manual rules are not necessary for this.

Right now, it's not obvious to me how non-OPNSense hosts on the management VLAN talk to anything on the Management VLAN using default HTTP/HTTPS/SSH ports.[/

Devices within the same subnet?
Communication between them will not pass the router. So you cannot control this traffic on OPNsense and hence no rule needed.

• If yes, should the custom HTTPS/SSH port rules for OPNSense be set to Destination:This Firewall, or Destination: IP address of the OPNSense firewall on this VLAN?

This firewall means any IP on the firewall. If using this alias you can also access the webGUI using the DMZ address for instance.
For the management subnet this will also be safe, but not necessarily needed.

[EricPerl]

Goal #3 has nothing to do with OPN. Machines on the VLAN can talk to each other directly.
This renders Q1 irrelevant.

Q2 is your choice (This Firewall = Set of Interface.Address across all interfaces).
What you have is sufficient IMO.

Unless you've set devices to query NTP on the interface GW (maybe via DHCP advanced option), the 2nd rule is probably not super useful.
Most devices will have internet-based defaults already allowed under the last rule.

[Sinister Pisces]

Thanks! This is what I needed to know. :)

On the internal lan interface OPNsense adds the "anti-lockout rule" for WebGUI and SSH automatically.
So if the Management subnet is the lan in fact, manual rules are not necessary for this.

I want to disable the anti-lockout rule and block access to OPNSense on anything else (the primary LAN interface and other VLANs). Only the management VLAN should be able to access OPNSense via SSH and HTTPS, which is why I wanted to make sure I had this right first.

Devices within the same subnet?
Communication between them will not pass the router. So you cannot control this traffic on OPNsense and hence no rule needed.

Yes, I wanted to make sure I wasn't going to screw up traffic within the management VLAN subnet. In-subnet traffic not passing the firewall is exactly the behavior I want, and how I thought it worked. Then I got paranoid.

So, that's why I also need the DNS and NTP rules, as well, right: because clients will touch the firewall/router for those services.

[viragomann]

I want to disable the anti-lockout rule and block access to OPNSense on anything else

Firewall: Settings: Advanced > Disable anti-lockout

[Sinister Pisces]

I want to disable the anti-lockout rule and block access to OPNSense on anything else

Firewall: Settings: Advanced > Disable anti-lockout

Thanks! I'm about to try this.

I think I have my firewall rules configured correctly at this point. Time to find out.

(I took a snapshot, and no one else will notice if I temporarily lock myself out.)

[Sinister Pisces]

Hello, again.

So, I added the firewall rules to my management VLAN, and restricted the listening ports for SSH and the web GUI to the management VLAN.

No reboot.

Everything seems to be working: I have HTTPS and SSH access on the intended VLAN, and can't access it from other VLANs.

Except, I also can't access SSH or HTTPS via the primary LAN interface, even though I still haven't disabled the anti-lockout rule. What's going on there? My understanding was that the anti-lockout rule would keep the primary LAN interface available via the web and SSH in spite of my firewall rules, but that appears not to be the case.

[viragomann]

Except, I also can't access SSH or HTTPS via the primary LAN interface

Do you mean, from the LAN interface or to the interface address?

As mentioned above, the anti-lockout rule is added to the interface, considered as lan internally. This is not necessarily this one, which you've called LAN.

Check Interfaces: Overview. Internally names are shown in brace in the interface column.

[Sinister Pisces]

Except, I also can't access SSH or HTTPS via the primary LAN interface

Do you mean, from the LAN interface or to the interface address?

As mentioned above, the anti-lockout rule is added to the interface, considered as lan internally. This is not necessarily this one, which you've called LAN.

Check Interfaces: Overview. Internally names are shown in brace in the interface column.

Sorry for the confusion. I cannot access OPNSense's web GUI or SSH daemon via the PrimaryLAN interface. This is the "lan" interface under Interfaces: Overview.

The default anti-lockout rule is still enabled, so my understanding is that I should still be able to access HTTPS and SSH via the lan interface, which leaves me quite confused and suspicious that I've done something wrong.

Here's the output for the lan interface.

Code Select Expand

PrimaryLAN (lan) igc1 static
10.10.100.1/24
10.10.100.0/24
Under Firewall > NAT > Port Forward, the anti-lockout rule is defined as:

PrimaryLAN

TCP

*

*

PrimaryLAN address

8423, 8443

*

*

Anti-Lockout Rule

In Firewall > Settings > Advanced, "Disable Anti-Lockout" is unchecked.
In System > Settings > Administration, SSH and HTTPS are set to only listen on the Management VLAN (VLAN 10/10.10.10.0/24) and a dedicated physical NIC I'm using for emergency out of band management that isn't even plugged in right now.

All that to say, I'm getting the result I want (SSH and HTTPS unavailable on the lan interface, and only available on the interfaces I want it on), but anti-lockout is still enabled. I shouldn't be getting the result I want.

[viragomann]

In Firewall > Settings > Advanced, "Disable Anti-Lockout" is unchecked.

Yes, I'd expect, that accessing is allowed from lan if this is unchecked.

If you go to Firewall: Rules: LAN and tick the button on the upper right to display the automatically generated rules, the anti-lockout rule should be shown up in the list.

As shown, I'm using a custom port for the GUI as well.

[EricPerl]

And you're trying to access the WebGUI and SSH using your custom ports on lan, right?

What does the FW live view show when you try?

[Sinister Pisces]

Good morning,

My apologies; it sounds like I was a bit confusing again.

• Currently, I cannot access the OPNSense web GUI or SSH interface via the default lan interface.
• The behavior above is what I want: I've set OPNSense to only listen to HTTPS and SSH incoming connections on the management VLAN.
• However: the anti-lockout rule is still enabled, so from everything y'all have said and everything I've read, I should still be able to access the web GUI and SSH through the default LAN interface, but cannot.

That is: the system is acting like I've disabled the anti-lockout rule, when I haven't yet done that.

@viragomann: I do see the anti-lockout rule in the firewall list for the default lan interface. There are two of them, coving my custom SSH port and my custom HTTPS port.

@EricPerl Thanks. I didn't realize the firewall live view was a thing. I really need to read the entire manual again as soon as possible. I'm seeing a PASS from my client to the OPNSense HTTPS port on the lan interface, via the anti-lockout rule.

I think this clears up what's happening.

• The anti-lockout rule is still in place, allowing incoming traffic on the default lan interface. This is correct behavior based on the current settings.
• OPNSense is only listening for HTTPS requests on the management VLAN. So, it's not listening on the default lan interface, and will not serve any content there, so even though the request gets through the firewall, it times out because there's nothing there to respond. This is the behavior I'm currently seeing. So, this is the correct behavior based on the current settings.

What threw me was that I assumed that with the anti-lockout rule allowing traffic, OPNSense would serve the web GUI on the lan interface: my instinct said there was no point in keeping the primary lan interface open to web GUI traffic on the firewall if there wasn't a web GUI actually available on the interface.

This isn't how it works, I think. Instead, this is how I think it works now:
The anti-lockout rule just keeps the firewall from blocking traffic on HTTPS and SSH on the lan interface. It can't force SSHd or the HTTP server components to listen on interfaces I've told them not to listen on.

Am I understanding it correctly now?

[EricPerl]

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.

[viragomann]

• Currently, I cannot access the OPNSense web GUI or SSH interface via the default lan interface.
• The behavior above is what I want: I've set OPNSense to only listen to HTTPS and SSH incoming connections on the management VLAN.
• However: the anti-lockout rule is still enabled, so from everything y'all have said and everything I've read, I should still be able to access the web GUI and SSH through the default LAN interface, but cannot.

[/list]

Maybe you're wrong with the last point.

There are two of them, coving my custom SSH port and my custom HTTPS port.

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).

[Deathmage85]

So, something that might help you.

I had a similar issue with getting access to the management port, so what I did was this:

Your port 8443 it seems for the GUI.

So on the firewall:rules[interface] of which I think you want LAN to be the one to access the GUI, then create a firewall rule like:

Pass >> Inbound >>> Protocol: TCP/IP >>>> Source (LAN subnet i.e 192.168.100.0/24) >>> source port (any) >>> Destination (This Firewall) >>> Destination port (8443) >>> gateway (not defined) >>> schedule (not defined)

Hope this helps. ^_^