Messages

Thanks @Franco:
for the fast patch !

Protectli VP2420 with 16 GB of RAM ......

Intel Celeron J6412
* Quad Core
* 1,5 MB L2-Cache
* 2,0 GHz with burst till 2,6 GHz
* Intel AES-NI hardware acceleration

is really fast enough.
A mismatch with suricata on the same interface ?

100% is in top viewed on cli?
And which are the processes using the whole cpu cores ?

Zenarmor free edition can only use 1 cpu core.

Perhaps a new approach for dns filter lists in unbound:

Here is the breakdown of how AVM optimized the native DNS filter lists introduced in FRITZ!OS 8.40 / 8.50 to minimize RAM and CPU impact.
------------------------------
## 1. RAM Optimization (Memory Efficiency)

* Highly Compressed Data Structures: AVM does not store the imported text files as raw strings. Instead, during the import process, the FRITZ!Box parses and compiles the domains into highly efficient data structures (likely optimized Tries or compressed Bloom Filters). This reduces the memory footprint to a fraction of the raw file size.
* Low Footprint for Millions of Domains: Real-world testing by the community shows that importing heavy lists like HaGeZi Multi PRO combined with TIF (Malware)—totaling around 2.3 million blocked domains—only increases the RAM usage of an older FRITZ!Box 7590 (which only has 512 MB RAM) by a moderate 5% to 10%. There remains plenty of headroom on all supported models.
* No External Storage Required: Unlike early community speculations, you do not need to connect a USB drive or utilize the internal NAS storage to handle large blocklists. The RAM management handles everything internally.

## 2. CPU and Performance Optimization

* Algorithmic Complexity (O(1) / O(log n)): Thanks to the specialized search trees mentioned above, lookup times are mathematically decoupled from the list's size. Whether a list contains 10,000 or 2.5 million entries, the time it takes to check a domain remains nearly identical. The router never performs a slow sequential string search.
* The "Paradoxical" CPU Relief: User reports from the FRITZ! Labor beta phase revealed that the overall CPU load often decreases during normal web browsing when the filter is active.
* Why this happens: When tracking, advertising, or malware domains are instantly blocked at the DNS stage, the FRITZ!Box never has to establish those TCP/UDP connections, route the packets, or handle Network Address Translation (NAT) for them. Less junk traffic means less work for the CPU.
* Integration with Packet Acceleration: The DNS filtering engine is deeply integrated into FRITZ!OS and operates in tandem with AVM's hardware-level routing accelerators. This ensures that filtering does not bottleneck your overall internet throughput.

In short, AVM has successfully implemented this feature directly into the core of their lightweight Linux-based firmware, making it significantly more resource-efficient than running a heavy Docker container or Pi-hole on an external device.

I've been working in this field for over 30 years.
And yes You certainly don't have to include everyone, definitely not.

But upgrade notes are truly industry standards in computer science. Having to gather information individually from Reddit, forums, and the internet is not standard practice. This has nothing to do with open source per se.

A clear document, which can happily incorporate the known issues to be addressed, and cross-links to the forum issues, would be ideal. I greatly appreciate opnsense and everyone's work.

But this is a real blind spot. And again, it's not about robbing agility. But more structure and transparency are also important in computer science.

Otherwise, there would be stable releases with full documentation and testing. But nobody wants that except shortly before major releases.

I would like to support this with the extended release/upgrade notes feature.
Perhaps a form of swarm intelligence is possible for that.

If you take a step back and look at the issue constructively and compare it with how well-known firewall manufacturers handle things there is certainly room for genuine improvement.
Without background knowledge, the release notes are indeed very sparse.

So, here is a suggestion:

Either expand the release notes with more text and explicitly highlight where the admin needs to take action...

...or, alternatively, provide both release notes (the current brief version) and separate "upgrade notes." The upgrade notes would contain the specific details regarding what needs to be considered during the upgrade process.

That would genuinely improve quality for everyone and reduce mishaps.
And yes, simply clicking without reading isn't good practice, but this approach would make the process far more transparent.
It would also save both the user and the manufacturer a lot of support-related effort.

You read the release notes for 26.7 ?

https://forum.opnsense.org/index.php?topic=52375.0

o firewall: legacy rules pages move to plugin

Interesting, a couple weeks ago when I found that the migration broke all my firewall rules, I was told that I shouldn't have used it and there would be years before before anyone would have to migrate.

And now suddenly the migration has apparently become mandatory.  That kind of behaviour means that we can no longer trust the developers in any way ever again, if we ever did.

Good to know that this possibility is not officially supported. Used from time to time in case of problems with the three areas conflicting while updating.

opnsense-update -bkp

gives the possibilities to fine graduated updates


basic system (-b)
kernel (-k)
packets/plugins (-p)

Not updating a firewall system for a year is really unusal.

If you want to try that... fine... but DO NOT report issues with this.  As I said: it is unvetted and potentially incompatible across multiple major versions.

To use a firewall system a reading of release news is mandatory.
Only press update is not the target.

Not "you have no time today", you spent no time in the past to get a clean system.

Why you ignore the rule migration - one of the biggest changes in opnsense - for half a year ?

opnsense-update -bkp

gives the possibilities to fine graduated updates


basic system (-b)
kernel (-k)
packets/plugins (-p)

Not updating a firewall system for a year is really unusal.

Sorry, this is a totally wrong head line.
Nothing you wrote is a general feedback.
It is the specific question of not understanding the update path.
One year behind ? Absolutelly unusal use case.

The problem is a bit the thread starter itself.
Without knowledge of basic network design rules all effort is in reality a waste of time.
It is important to seriously consider the issues and not just start building without a plan.
I have rarely read so many false things.

To tell the truth:
An inspection service these days without spreading to multi threads and multi core is useless.

We have at home fibre connections to the internet with speeds up to 1 Gbps symmetric (300 Mbps, 600 Mbps, 1 Gbps).
At home, as private customer, no special business product and not expensive.

If it is planned
- to profit from a free community for the development
- to benefit from the reputation the product is known in a wider community
- to bind private users free at no cost to a product for a gain in business awareness
it is mandatory that a product not only thinks on the own side of their business plan.

Look at Sophos they disabled f.e. the memory limit of 6 GB memory to unlimited memory usage for their home user community. Why ? Because it is needed.

My opinion on this zenarmor business case:
Open multi core for free to the community.
Otherwise it took not much time and the community users go away like in the pfsense community.

If you want the benefit of a wide testing community you can not make a business with them and demand money. It is the real deal to give the needs back to the community. They are part of your success with the product. So you should be able to reinvest in the community needs.

These words should help to find a solution that is a real win win situation and a healthy basic for the upcoming future of zenarmor.

Look at Sophos they integrate the community on the feature usage completely and do not castrate the community edition to a small piece of their product.

In other words:

Decide if you bridge or route.

What you build is far away from network standards and the reason for the trouble.

Two statements:

1) Bridge:
Yes, like Patrick told you, a network bridge is a layer 2 only and fully transparent device.
Often told "bump in the wire".
Not one with ip addresses on interfaces.
There is only the bridge interface.
And normally a bridge is not a DHCP server or client.
And last thing: A bridge itself is not a routing device. Only the management interface is routed.

2) Management Interface:
Ok, a management interface can have individual routes f.e. to a dedicated out of band management. In the best case as an own routing instance (like virtual router forwarding vrf implementation).

The truth is that he only want a "layer 2 only / traffic shaping box".