Messages

Hello,

I'm tracking this as well, as my firewall refused to boot after I accidentally upgraded to 25.7 when trying to grab the EOL 25.1.12 release.
I've since rolled back, but I did notice the BOOTLOADER TOO OLD message in the serial console.

I've got the intel-microcode package installed.
I'm running on ZFS (which is how I was able to fix my broken system so quickly--thank god for snapshots).

OPNSense 27.1.12 reports:

Code Select Expand

# uname -a
FreeBSD Uhura.finchisland.net 14.2-RELEASE-p4 FreeBSD 14.2-RELEASE-p4 stable/25.1-n269832-6addeda7db20 SMP amd64

root@Uhura:~ # cat /etc/fstab
# Device             Mountpoint      FStype     Options         Dump    Pass#
/dev/gpt/efiboot0    /boot/efi       msdosfs     rw             2       2
/dev/nvd0p3          none            swap        sw             0       0

root@Uhura:~ # gpart show
=>        6  122096635  nda0  GPT  (466G)
          6      66560     1  efi  (260M)
      66566        128     2  freebsd-boot  (512K)
      66694        122        - free -  (488K)
      66816    2097152     3  freebsd-swap  (8.0G)
    2163968  119932672     4  freebsd-zfs  (458G)
  122096640          1        - free -  (4.0K)

@Patrick, I'd appreciate any advice on how to actually update the bootloader without a clean install.
Or, in the alternative, confirmation that I might as well just do a clean install. :P

[Benefit of Zones�]

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

[What I've got:]

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?

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

[The recommendation is to let the GUI listen on all interfaces and control access via rules.]

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.

[I think this clears up what's happening.]

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?

[Interfaces: Overview]

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.

[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.]

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.

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

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.

[Goals]

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.

Thanks, everyone. I think I've got a pretty solid handle on this now. I'm working on my first-non-default set of firewall rules for my management VLAN--I need to get that done correctly before I go further messing with what ports OPNSense is listening on.

So, I'm going to make a separate thread about that and make sure I understand what I'm doing before I push forward with this.

So far, I haven't broken anything. :P

[still enabled]

Thanks!

(Aside: This sounds like the sort of thing where I want to take a snapshot before fooling around ... :P )

Just to make sure I'm correctly understanding:
Right now:

• The default anti-lockout rule is still enabled (I haven't touched this yet).
• I have restricted SSH to two interfaces using the GUI.
• SSH is accessible on those interfaces.
• Attempts to connect via other interfaces, including the Primary LAN interface, currently fail.
• I have not added any allow rules for SSH to the management VLAN or the out of band management interface (physical NIC).

I suspect, based on what y'all wrote, that the default anti-lockout rules are allowing me to access SSH on my chosen interfaces right now, and if I disabled the anti-lockout without putting in firewall rules, I'd be locked out.

Is that right?

EDIT: I think what tripped me up here is that the two interfaces I've designated are a VLAN whose parent is the primary LAN interface, and a physical NIC that isn't my primary LAN interface, but rather is a secondary LAN.

So, I read the warning on the disable anti-lockout option and saw "the LAN interface," and assumed it meant that access is always available specifically on the Primary LAN physical interface. I think I was being too literal, and instead, when anti-lockout is on, any LAN interface (including the two physical LAN interfaces I have, and any VLAN children they have) are covered. That would explain why my current setup is working without any firewall rules in place.

Is that correct?

Really appreciate the quick fix on this one. :)

Was definitely a bit alarming to see a bunch of 100 C warnings at 2 AM. But since the box wasn't bursting into flames, I figured it was a cosmetic thing.

[I already successfully adjusted the SSH listen interfaces (Settings > Administration) to only listen on the two interfaces I want, and I've tested that it works: clients attempting to connect via SSH to the firewall's IP address on other VLANs and the actual parent LAN interface cannot connect via SSH. Success.]

Hello,

I'm working on hardening my OPNSense installation. I have a management VLAN set up, and an out of band management port with its own dedicated ethernet interface, so essentially I have two management networks. My goal is to have the firewall accessible via SSH and HTTPS only on those two networks.

The guide I was using described the process of manually writing rules in the VLANs to accomplish this, but after starting on this, I'm seeing SSH rules being auto-generated and now I'm confused. I want to make sure I understand what's going on before going further.

I've only adjusted the SSH service so far, which has led to confusion, so I'll start with that.

I already successfully adjusted the SSH listen interfaces (Settings > Administration) to only listen on the two interfaces I want, and I've tested that it works: clients attempting to connect via SSH to the firewall's IP address on other VLANs and the actual parent LAN interface cannot connect via SSH. Success.

However, all the VLANs still have a pair of sshlockout auto-generated rules on them: one for my custom SSH port and one, oddly, for my custom HTTPS port for the web GUI. There's also a matching floating rule. They look like this:

Code Select Expand

Source: * ; [Source] Port: *; Destination: Self; [Destination] Port: As Configured; Gateway: *; Schedule: *; Number of Interfaces Rule Applies to: *; Description: sshlockout

The part that's really confusing me is that these auto-generated rules look the same on interfaces where SSH is allowed as where it's blocked, so I can't tell the difference. Since I successfully restricted SSH access in the GUI, shouldn't I be seeing different auto-generated rules on the interfaces that allow SSH to OPNSense versus those that don't?

This little adventure is making me feel like I misunderstand something fundamental.