Messages

Can you add a plugin ticket on GitHub?

Will do, thank you for the link. I'll wait for it to do it again, and see about getting a log. It was doing it regularly. Perhaps it's fixed (fingers crossed)

Unfortunately I'm not sure at what point this started, but at some point apcupsd stopped functioning properly. I believe it to be relatively recently. It works perfectly fine, but at some point I end up with a "LCK.." file in /var/spool/lock. If I delete this file I can restart the apcupsd and everything functions normally again.

Is this a known issue, or is there something I can do to prevent this?

I'm running:
OPNsense 26.1.4-amd64
FreeBSD 14.3-RELEASE-p9
OpenSSL 3.0.19

Speaking of lightbulbs ;D - https://docs.opnsense.org/manual/hacarp.html

Doh... It's literally in the first couple sentences...

Two or more firewalls can be configured as a failover group.

I looked through there quickly, and saw the traditional diagram that I would expect, with the two ONT style. Reading fail on my part. Thank you.

Thanks to everyone for their responses!

Yes. See documentation. If you are on fiber, you could even use two redundant ONTs on the same fiber.

I'm not thinking two ONTs (WANs), I'm thinking two opnSense boxes (Firewalls). Backwards of the way I normally think of HA working.

I think it might be important to remind what the in/out direction for rules means - i.e. the direction of the traffic with respect to the firewall at the point where it's being inspected (on the given interface). An attempted connection from IOT_VLAN to KID_VLAN will arrive at the firewall (*inbound*) on the IOT_VLAN interface. If there was a rule that allows it (an *inbound* rule on the IOT_VLAN interface), it would pass through the firewall and then be sent *outbound* (from the firwall) on the KID_VLAN interface. In this case, it would have been blocked before it got that far, so there's really no point in having another rule to block it outbound.

Rules to allow/block are usually done on the inbound interface because it's more efficient to make those decisions as early as possible, rather than waste time processing the traffic only to decide to block it later.

Outbound rules are generally used to apply some policy to traffic originating from the firewall itself.

Thank you so much for this explanation. This was sort of my "light bulb" moment. What I needed to actually understand it.

So I know just enough to be dangerous. I've had this box up and running for a while now and I've come across a few questions. Hopefully these are easy enough someone can point me in the correct direction:

• Login to the actual device? I disabled the root account, and made a new account for login to the GUI. Now I seem to have no available logins to the actual device itself. I disabled the root account originally, as an extra layer of security. However perhaps now looking at my new user account, it doesn't have the same exact permissions as root. I can do everything from the GUI, I just can't seem to log into the shell at the device itself. Should I care?


• The devices I use do actually get frequent BIOS updates. Do I still need the os-cpu-microcode-intel / Intel microcode updates Plugin?
• I've been messing with one of my opnsense boxes recently, and so that's been leading my to swap in my backup. This got me to thinking is there a "HA" type setup for the opnsense box that I can setup? Rather than swapping the boxes physically, if one went down, the other would take over?
• From reading, it appears usually only inbound stuff is blocked. When I did all my rules, I blocked stuff in both directions. For example
  
  
  
  • Block INCOMING Traffic from IOT_VLAN to KID_VLAN
  • Block OUTGOING Tracffic from IOT_VLAN to KID_VLAN
  I figured I didn't want any traffic going in either direction between these networks. Did I do something wrong?