Messages

Since I use Zabbix in this environment, I crafted a trigger to watch for changes to /tmp/pkg_upgrade.json, which check.sh creates. (We'll see how fragile that turns out to be.)

This addresses the notification requirement, but the lifecycle management problem remains.

I'll leave this as a plea for Deciso: as your commercial support offering matures, please prioritize moving to a more typical release model which provides a short period of security updates for the previous release after a potentially breaking update drops. A minimum of 6 months is usually reasonable, to allow for scheduling and testing.

The current situation dilutes the stability value of the subscription model, as it creates a scramble and an unavoidable gap in compliance and exposure twice a year.

If you put this as cron job parameter it will also do major upgrades automatically:

https://github.com/opnsense/core/blob/eb2800a9bd76060fa17937840e3498c31e4081d2/src/etc/rc.firmware.subr#L34

ALLOW_RISKY_MAJOR_UPGRADE

That's potentially useful, thank you.

So I don't get what you mean by silently stranded.

Right, and by "silently" I mean it simply stopped getting updates. What I was asking is where I should have tuned in to be warned that the version I'm running was about to be EOL.

I wasn't aware that it's simply scheduled semiannually, so thank you.

I would really like to see an LTS release with some dwell time / overlap. Forcing commercial customers to upgrade twice a year at a specific time isn't great.

Hello -

I have been using the business edition for about a year.

I have noted that minor version bumps happen automatically and smoothly via the cron job "Automatic firmware updates".

Major version updates aren't automatic, and I'm not clear on what is the correct way to engage with those to avoid being silently stranded in a dead-end branch and not getting updates.

I also have a cron job for "Firmware update check", but it doesn't notify me of its results. Because of this, it appears I missed the security updates for CVE-2026-44194 & 45158 due to being on 25.10.2, and the host was waiting for manual intervention to upgrade to 26.4.

I see a couple of things I could do:

• Since monit does email its output, I could create a custom monit task to run or wrap /usr/local/opnsense/scripts/firmware/check.sh.
• I can subscribe to notifications for https://github.com/opnsense/core/security/advisories, but that requires me to verify that each is addressed, whereas I'd like to simply know that it's automated.

Is there a better or more supported way to manage the transition to new major versions without surprises or gaps? (Even better, is an LTS version on the roadmap someday?)

Thank you, and apologies for my ignorance.

Thanks for the confirmation here. I was snooping around hoping to find something like this thread. Not only do the device names look strange, but temps over 100C are generally "unrecoverable critical" (as in, "We should be dead, my friend"), so seeing the box humming along happily with those readings struck me as a red herring.

On the plus side, the updated interface in 25.1 looks great - thank you.

Not much to see. DNS settings are all blank (using unbound at localhost, which works fine when tested at Interfaces->Diagnostics->DNS).

The observed issues went away when I removed the os-sunnyvalley (after the Plugins page finally repopulated).

[Update]

I have this issue currently on 24.1.8-amd64.

After adding the sunnyvalley repo (because I intended to add so-sensei), attempting to check for updates hangs for a long period on this:

Code Select Expand

Updating SunnyValley repository catalogue...
Waiting for another process to update repository SunnyValley

Update check does complete after a long time.

Worse, the Packages and Plugins tabs are blank, so I cannot manage software.

I have:

* rebooted
* verified that DNS works (Interfaces -> Diagnostics)
* verified that all services are running (except iperf, which is normal)
* verified that all attached networks are working correctly
* Tried the suggestion above, with this result:

Code Select Expand

# pkg remove py37-pymongo
No packages matched for pattern 'py37-pymongo'

Checking integrity... done (0 conflicting)
1 packages requested for removal: 0 locked, 1 missing

Out of ideas. I'm down to the last resort option of reinstalling and restoring a config backup.

Update:

Right after I submitted this, the plugins page suddenly populated. The last time I was able to view it (right after adding the sunnyvalley repo), the installed plugins showed "(orphaned)" instead of "(installed)". Now, they say "(installed)".

I would guess there's a problem with the sunnyvalley repo (slow to respond? a dead mirror?) that is causing issues.

Just wanted to note here that adding the firewall's IP addresses to the "Listen Address" directive (and adding appropriate firewall rules) is sufficient to turn a standalone instance into a server. It isn't necessary to mess around with port forwards.

BUT - I don't recommend that. You are limited to accessing only the most basic configuration items, which is not adequate for a server instance. For one fun example, in this port's configuration, I found 'monuser' is "hardcoded" with "upsmon = master" in upsd.users, which gave my nut clients the ability to turn off my firewall. I sorta doubt most people want that.   :)

You can override anything you want manually in the configuration files, of course, but they will get clobbered sooner or later.

The Opnsense NUT port is fine (and appreciated) as a client, but I'd stick to a Raspberry Pi for the NUT server, until/unless the full suite of NUT configuration parameters is made available in the port.

Well, I'll be darned. Thank you!

So, the end result is that I can simplify my configuration, since I won't need unblock-lan-zones. Win-win.

Cheers, and thanks again.

Well. That's puzzling. Or I have no idea what I'm doing.

On a hunch, I UNchecked "Disable DNS rebinding check" in System->Settings->Administration, and sure enough, reverse lookups for overridden zones now work correctly without unblock-lan-zones. That is the opposite of what I'd expect the effect of "Disable DNS rebinding check" to be, based on the help text:

"When this is unchecked, your system is protected against DNS Rebinding attacks. This blocks private IP responses from your configured DNS servers. Check this box to disable this protection if it interferes with web GUI access or name resolution in your environment."

I'm not sure I understand why unchecking that allows PTR queries for private addresses, and selecting it causes them to fail.

Re: IPv6 addresses - PTR lookups for those were not affected in my case, because mine are publicly routed (I have an HE tunnel allocation). The IPv4 addresses are all in 192.168/16.

Thank you very much for the info.

Thank you for your note. Yes, the reverse zones are in the overrides (168.192.in-addr.arpa, as well as a v6 net block). PTR lookups from attached clients definitely don't work unless unblock-lan-zones is specified. I'm not anyone's expert on DNS, so I may misunderstand what is meant by "upstream", but the authoritative server is on a different network from the client, beyond the unbound resolver (via another LAN route, not the WAN).

What stands out to me is stability. Given the consistency of design and behavior, clear documentation of changes, and reliability of the update process over time, it seems clear that your development practices are very disciplined.

I ensure that I have configuration backups and a copy of the previous image before each upgrade, but I've never needed them. The same cannot be said for a lot of commercial software.

Salutations --

Just thought I'd note, as we close in on the drop-dead date for "Custom options" in the unbound GUI, that my use for this feature is to add this section:

server:
   unblock-lan-zones: yes

I forward requests for my own domain to an internal authoritative server using overrides, and the above declaration is needed to make the PTR lookups work for RFC1918 addresses. If you felt like adding a toggle for that in the GUI someday, that'd be appreciated; else I'm fine with adding it manually in /var/unbound/etc in future.

Thanks again for an outstanding piece of software.

Hmm ... I don't think that's it, because the same behavior is seen with IPv6, which is a simple firewall rule where port forwarding is not involved.  As with the v4 rule, if I change 'GEO_US_IPv6' to 'All', then traffic is passed.

I encountered this, and in my case, it's because the IPv6 gateway was not actually working. 

There is a setting under System->Settings->General which says "Prefer IPv4 over IPv6".  If you select that, and updates start working again, my guess would be that IPv6 is not correctly configured or is otherwise broken. 

Just a thought.