Messages

From what did you update? I notice you mentioned reboot, which does not happen in a 26.1.3 to 26.1.4 upgrade unless you do it yourself or have it set as an automatic action.

... whether an upgrade would noticeably improve protection

That is not something I am able to test specifically. Improved protection through increased frequency of update is something I have to assume without measurement of practical difference. However, I have found that the ability to look up IPs can be useful, including getting a site unblocked by qfeeds after some review. I subscribed to qfeeds Plus at an early stage, and have uninstalled crowdsec.

PPS is measured with 100B size, this is to measure the performance and include small sized packets. Basically to see how much MAX pps you can route/switch before you see a performance degradation.

Throughput does not have mentioned what packet size or tool was used for measurement. But I would guess they used default L3 MTU size (1500B).

Regards,
S.

I see it says different things in different brochures from different periods. This came from a DEC 700 Series brochure:

Maximum PPS is measured using 100 byte sized packages. All throughput numbers are based upon maximum packets per second multiplied by standard 1514byte frame size minus additional overhead where applicable

the clear implication being that they took the 100 byte rate and multiplied it by ~1500. I mentioned 500 bytes because that rather than 100 is in the DEC 600 Series brochure.

This is generally consistent with what is being reported here.

I had a look at the brochure. In the fine print it appears to me to say that packets per second are measured with 500 byte packets but this number is multiplied by 1500 [byte packets] to get throughput. Ergo, it cannot be achieved. Did I misread?

That depends on your security setup for Opnsense. HTTP or HTTPS access? From which [v]LANs? Quality of pass word or phrase? 2FA? SSH access? Password or passkey for that? Much of that is discussed here.

You can also run a security audit.

Reservations remain as you would expect.

Are your reservations outside your dynamic pools?

Did you miss an Apply somewhere along the line?

Do you mean an AP to attach to an interface on an existing Opnsense box?

At face value you are asking to run Opnsense on an ARM A53. How would you propose to do that with proven software?

There are no special considerations I have seen mentioned, use of ISC or Kea or DNSmasq being essentially independent from the upgrade. ISC changes to being a plugin but still transitions as expected, or so I read because I had switched to Kea prior. Use snapshots and upgrade stuff in the order that pleases you. If you are not already using ZFS then consider seriously a reinstallation to employ it, before other work.

I don't use everything in the menu, ... for example stuff like ... services->ISC DHCP ...
It would be great if it was possible to click a button to hide

Without detracting from your general point with which I agree, if you are on 26.1 and not using ISC DHCP then go to -->firmware-->plugins and bin it. The menu vanishes.

Migrated the main firewall and rules successfully, today. The new rules view is a structural improvement for me, making it easer to perceive and potentially change these configurations.

I have upgraded a test bed and an internal router, including successful migration of rules (yes Franco, we all charge in). I will probably do the critical edge firewall today. Being able to snapshot the working 25.7 and then the base 26.1 before rule migration provides nice security, or encourages diving in.

Just to mention, on one test box and two operational boxes, all bare metal Intel and AMD, hostwatch trots along quietly with no untoward CPU spikes or log writes. Three principal subnets (no vlans), all IPv4, around 25 devices.

So how can I rollback or switch to a point where the new firmware was not installed, if the operations are persisted

This is, in terms of my explanation, a configuration change. It is not part of the snapshot, so you can still roll back to the prior configuration.

This appears to be the question:

My problem of understanding is why and when will a snapshot in OPNsense start to persist data? When I make it active for the first time? If so, this means I cannot use (rollback to) a snapshot more than once. e.g. how do I rollback to Sept. 2025 when the "default" snapshot was created?
Somehow there is a disconnect I cannot reconcile.

and this is a lay answer from my use of snapshots: essentially, you do not roll back to a date but to a version.

If I take a snapshot then I am preserving a (presumably) stable version. All normal operations of the router will continue to be reflected in that snapshot version as well as in the active. That is, it continues to update for operations ... but not for configuration.

Any configuration changes will be reflected in the Active version but not in the Snapshot version. If you like the changes and they are stable, you can make that the master simply by continuing to use it while optionally deleting the Snapshot. If you do not like the changes then revert to the Snapshot in which case your configuration changes will vanish yet the router will be operationally up to date. If your changes crash the router then you can recover safely to your snapshot on boot.

Snapshots reflect a configuration point, not a time point.

I will be interested to see whether my understanding is confirmed.

Given the base is working software, not a development from scratch, I can understand that the release pattern does not follow a conventional cycle such as one might read in Wikipedia. I interpret development as a form of beta which is yet changing for reasons other than bugs. Community I accept as an advanced stable release which may yet have bugs which are fixed under _NN releases. Business is a supported stable release which might be called long term except that its term is not long.

Opnsense is not the only operation to follow a pattern like this, nor the only forum in which it is argued. I think that the conventional namings from alpha through gold, including the word beta, confuse the issue by their prior connotations.

We have a stable base product. On that there is a development offshoot. When that is feature-complete (for this phase) and stable it becomes Community, field testing more advanced features ahead of the low-risk business edition.

The clear implication is that there are three levels of risk for the consumers who must themselves share the risk management as discussed, firstly by selecting in which level they will join and secondly by their own testing and timing of upgrades on one or more of their own systems. Personally I use select Community then upgrade (always with snapshots) through "Does it work for a few hours?" on a reserve box to "Does it work for a few days?" on an internal production box to "Here we go" on the edge router.