opnsense
Clarification on Recommended Update Policies for OPNsense
We use OPNsense Community Edition within the @GlobaLeaks project, and we are opening this ticket because we believe these questions are relevant not only to us but also to many users whose OPNsense appliances are managed by external organizations. Clear guidance can help reduce operational costs and avoid the risks of updating too early from a stable setup, or staying too long on a version that is no longer adequately supported.
Our questions:
-
Does OPNsense have a formal LTS or extended-support policy, or is only the latest major CE release supported with security updates? For example, if 25.12 is the last release of the 25.x series and is presumably more stable than an early 26.1 release, when should users consider upgrading to 26.x?
-
Is a “security-only” or frozen-stable branch available, or are all CE users expected to follow the regular feature + security update cycle? We understand the latter is currently the case. From an end-user perspective, it would be helpful if each release clearly indicated whether it includes security fixes, for example via a “security-update” tag.
-
What update cadence or version-selection strategy do you recommend for CE users seeking maximum security and stability, while avoiding premature upgrades or outdated releases?
We hope the answers will help both our project and the wider OPNsense community adopt safer, more predictable deployment practices.
Thank you!
Hi @evilaliv3,
- No LTS. The business edition bridges the gap by 3 months since it is offset from the community edition, but from experience businesses are also ok with major upgrades both in community and business editions.
- There is no security-only patching in community releases and this includes intermittent hotfixes. The business edition is a bit more responsive when needed, also offering out of band package updates of third party software when the need arises. In theory you can patch your stable branch EoL with core security patches from newer releases or build updated third party software using the ports tree since all of it is open source. In practice OS upgrades can hinder prolonged efforts as we've seen ourselves while struggling to maintain releases on older FreeBSD versions for longer than what their EoL policies offer. In that sense we don't have much choice offering LTS anyway (see FreeBSD life cycles for comparison).
- In plain terms? The business edition does what you ask. If you run community the responsibility to defer an update goes to you and in most cases that's perfectly fine given that not all new features, fixes and security advisories apply to all use cases all the time.
Initial major tend to always have the most issues and an EoL stable release the least amount. Personally I recommend cautious users to wait for a .1 or .2 release before updating. The best case for users would be to help with RC testing or run a development version in a test environment, but I'm aware that's too much to ask in most cases.
Hotfixes in community releases (major or minor) often have reaction times of a few hours to 24 hours in urgent cases. So if you wait two days before applying an upgrade you would likely avoid initial headaches, but in my opinion that should go without saying. Nobody can really update on release day and tell me that their test environment was testing ok too. ;)
I hope that helps! :)
Cheers, Franco
Thank you so much @fichtner for the clear and complete clarification.
I just have one follow-up question regarding point 2.
I understand that maintaining a true security-only patch stream is difficult, and that’s not what I am asking for. Instead, would it be possible for releases to clearly indicate when they include security fixes?
A simple marker or tag would make it much easier for users to understand the urgency of an update and to prioritize upgrades accordingly. This would also help reduce costs for organizations that rely on managed security updates, since they could focus their efforts on updates that actually address security issues. Likewise, when a release does not contain security-relevant changes, administrators could safely remain on the previous version a bit longer, avoiding unnecessary updates and reducing the operational risks associated with frequent change cycles.
Thank you again for your time and the detailed explanations; this small clarification in release notes would greatly help many community users plan safer and more predictable update strategies.
I understand that maintaining a true security-only patch stream is difficult, and that’s not what I am asking for. Instead, would it be possible for releases to clearly indicate when they include security fixes?
Defining the scope to core itself for simplicity we've begun to annotate CVEs handed out recently in the changelog at https://github.com/opnsense/changelog
% git grep CVE:
business/25.4/25.4.3:[3] CVE:CVE-2025-34182
community/25.7/25.7.4:[1] CVE:CVE-2025-34182
community/25.7/25.7.7:[1] CVE:CVE-2025-13698
This isn't a solution that is highly exposed in the published changelogs apart from the repository itself and likely never will be as the main intent is to create a web link to the CVE, but it's an easy pattern to scan for.
The other problem is what you define as security issue (scope creep mentioned above relating to plugins or third party software or the main OS) and not all security issues have a CVE and roughly half the CVEs are shipped before the number is assigned when the process and communication is precise enough.
Practically every release could be filled with a CVE even on a weekly release schedule. But as stated before a lot of those also do not apply for a multitude of reasons.
Cheers, Franco
Thank you . I really appreciate your effort and explanation.
Talking by examples is it difficulty for an end user to identifying for example if the last release https://docs.opnsense.org/releases/CE_25.7.html is or not be prioritized.
Try to read the change log with me from ab end user perspective.
25.7.9 is for example not specifically made for surety reason, seems a general update including some bugfixing. It highlights that something about security has been tackled but without being explicit: "The saga around safe command execution continues in this release as well. Otherwise it is a rather quiet release and 2025 is almost over. Happy holidays!'"
The last statement is not even clear if there will or not will be an other release of the series 25.7 or this is already the last.
25.7.9 is for example not specifically made for surety reason, seems a general update including some bugfixing
In community releases you can almost always be certain these are not strictly aimed at security alone, the community version also acts as a testbed for our commercial version, which is more conservative when it comes to adding features.
The last statement is not even clear if there will or not will be an other release of the series 25.7 or this is already the last.
Two major releases are marking "fixed" moments in time, intermediate releases depend on a lot of things, security, bug fixes, features ready to ship.
Also keep in mind, knowing about a CVE and the impact on your use is something completely different (in all fairness, I think over 80% of CVE's these's days are difficult or impossible to exploit in the wild, which makes these journeys even harder).
If you want the safest version, looking at CVE's and other markers, always install the latest version, if you're afraid of regressions or changes, you can obviously wait, but there is a cost in that too.
Than you @AdSchellevis
My concern is about typical IaaS infrastructure providers. They give you a firewall with whatever software version is available when you purchase it, but they don’t allow you to update it yourself. Instead, they charge you every time you ask them to perform an update.
If OPNsense end users need to update the firewall every month, they end up paying a high cost, not just in money (which is not the main issue), but also in time and operational risk (because they need to ask, wait, and incurr in all the overhead of the communication every month)
Does this feedback make sense from an operations perspective?
Sure, this is also one of the reasons why our business edition exist, to ease the operation. Eventually everything costs time (and money), when time is less problematic than money, you can run your own show, if it's the other way around, better invest in the product (also making it possible free users exist).
The better cloud providers pay for the software they use and help keeping their customers safe.