Messages

I followed the instructions in the Reddit thread that Franco posted and the issue was resolved. This issue has been resolved.

Okay. Thanks Franco. I removed the default_min_port=1024 and friendly_name=OPNsense UPnP IGD & PCP from the configuration file and the service started. I'm not sure if this will negatively impact anything. I'll wait to hear back from the Opnsense team.

Errorminiupnpd Error reading configuration file /var/etc/miniupnpd.conf
2026-11-11T10:16:53-05:00Errorminiupnpd invalid option in file /var/etc/miniupnpd.conf line 9 : friendly_name=OPNsense UPnP IGD & PCP
2026-11-11T10:15:53-05:00Errorminiupnpd Error reading configuration file /var/etc/miniupnpd.conf
2026-11-11T10:15:53-05:00Errorminiupnpd invalid option in file /var/etc/miniupnpd.conf line 9 : friendly_name=OPNsense UPnP IGD & PCP

Now the service does not start.

I disabled ZA free edition and didn't subscribe to the home tier because of lack of multi-threaded support. I found it was indeed bottle-necking my 10G network. While I did enjoy the extra layer of controls, it wasn't worth limiting my network traffic. 

same here. Zenarmor introduces latency due to its architecture. In this day and age of 2.5 gbps + internet, Zenarmor has lost it's utility. There are other ways to secure a network without having to "pay" for multi-core support.

No, RSS does not work properly with Zenarmor. In fact, there is little reason to use RSS alongside Zenarmor because Zenarmor pins its processing to individual CPU cores. This is why Zenarmor presents this "warning"

If you check the status (vmstat -i | grep rx) with both RSS and Zenarmor enabled, you can see that the majority of the packets end up being processed by a single queue (CPU core), effectively negating the benefits of RSS.

Zenarmor also introduces bufferbloat because of its single-core architecture. This becomes particularly apparent when you move beyond 1 Gbps. After upgrading to a 2.5 Gbps symmetrical Internet connection, the limitations and inefficiencies of the Zenarmor architecture became much more obvious.

There are more efficient alternatives that utilize true multi-core/multi-threaded architectures without putting that functionality behind a "business" tier.

In my experience, Zenarmor was designed around—and is really only able to efficiently handle connections up to around 1 Gbps. Even if you can achieve higher throughput, you often pay for it with increased latency and bufferbloat. So while it may technically push more than 1 Gbps, the overall performance and latency characteristics are not particularly efficient at those speeds. I suspect that part of the issue is Netmap.

I'm experiencing the same issue. Is this plugin still supported?

Has Zenarmor given any real explanation for why multi‑core support still hasn't been delivered, and why they're now trying to position it as a "business"‑tier feature? Multi‑core processing is a baseline expectation in modern software, not a premium capability, and tying it to an upsell feels hard to justify. Without it, the product simply doesn't scale in any meaningful way. Their roadmap is here if you want to review it: [https://www.zenarmor.com/roadmap](https://www.zenarmor.com/roadmap)

I upgraded as well and it went smoothly. Additionally, the latest version of hostwatch is a massive improvement in terms of disk writes. I can leave it enabled now.

I think that it might be beneficial to remove this capability. The issue with the disk writes is a major problem and introduces instability. I had it enabled and the disk writes are higher than my production elastic search instance by a factor 700%

For those looking for a more robust QOS solution for large network look into LibreQoS. The product is primarily for ISP's, but there are are use cases for other types of networks with high number of clients that require reliable service. It works well with OPNsense and its QOS implementatiom provides superior performance over OPNsense built-in traffic shaping/AQM solution. I find that FreeBSD's QOS solution doesn't work well for my use cases and the performance is not as stable. LibreQoS is more reliable.

Upgrading to 2.0.1 addressed my issues as well.

RSS isn't the issue. The problem remains if it's disabled. Something changed with eastpect.

For those that it's failing are you configured for RSS? I see a warning in the console regarding RSS, but it worked in the past.

Same here 2048 is to large. This problem has not been resolved ZA team.

The dev.netmap.ring_num = 1024 recommendation also did not work for me. Setting the value to 2048 addressed my issue. I'm no longer seeing this error: Critical   eastpect stack overflow detected; terminated.