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)(https://preview.redd.it/firewall-rules-for-opnsense-management-interface-sanity-v0-3i94qgnwcsge1.png?width=2242&format=png&auto=webp&s=77ffbd0d9dcc27360571d12a7e1c8218dd011f1a)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.
I looks all correct.
Quote from: Sinister Pisces on February 02, 2025, 09:44:13 PM- 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.
QuoteRight 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.
Quote from: Sinister Pisces on February 02, 2025, 09:44:13 PM- 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.
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.
Thanks! This is what I needed to know. :)
QuoteOn 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.
QuoteDevices 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.
Quote from: Sinister Pisces on February 02, 2025, 10:50:11 PMI want to disable the anti-lockout rule and block access to OPNSense on anything else
Firewall: Settings: Advanced > Disable anti-lockout
Quote from: viragomann on February 02, 2025, 10:57:05 PMQuote from: Sinister Pisces on February 02, 2025, 10:50:11 PMI 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.)
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.
Quote from: Sinister Pisces on February 03, 2025, 12:54:17 AMExcept, 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.
Quote from: viragomann on February 03, 2025, 12:55:12 PMQuote from: Sinister Pisces on February 03, 2025, 12:54:17 AMExcept, 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.
PrimaryLAN (lan) igc1 static
10.10.100.1/24
10.10.100.0/24Under
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.
Quote from: Sinister Pisces on February 03, 2025, 06:01:57 PMIn 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.
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?
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?
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.
Quote from: Sinister Pisces on February 04, 2025, 06:57:42 PM- 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.
QuoteThere 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).
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. ^_^
Quote from: EricPerl on February 04, 2025, 08:20:55 PMAFAIK, 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.
Quote from: viragomann on February 04, 2025, 08:32:01 PMPlease, 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.
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.
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.
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