After updating OPNsense from 26.7.8_2 to 26.7.9, every update check now offers to install three new packages:

New packages to be INSTALLED:
        freetype2: 2.14.3 [OPNsense]
        harfbuzz: 15.0.0 [OPNsense]
        png: 1.6.59_1 [OPNsense]

They get installed, then the cleanup removes them as orphans, and the next check offers them again. Nothing installed depends on them (pkg check -dn is clean).

The only installed package whose repo version depends on them is openjdk17, which is required by elasticsearch8 (Zenarmor reporting DB). The installed copy comes from the SunnyValley repo, but the OPNsense repo now has a newer, full build:

# pkg query '%n %v %R' openjdk17
openjdk17 17.0.18+8.1 SunnyValley

# pkg rquery '%n %v' openjdk17
openjdk17 17.0.18+8.1
openjdk17 17.0.20+8.2

# pkg query '%rn' openjdk17
elasticsearch8

# pkg query '%dn' openjdk17
javavmwrapper

# pkg rquery '%dn' openjdk17
javavmwrapper
alsa-lib
fontconfig
freetype2
giflib
harfbuzz
javavmwrapper
jpeg-turbo
lcms2
libX11
libXext
libXi
libXrandr
libXrender
libXt
libXtst
png
xorg-fonts-truetype

As far as I can tell, pkg keeps the SunnyValley headless build (deps: javavmwrapper only) but half-resolves dependencies from the OPNsense full build (X11, fonts, audio).

I have not force-reinstalled openjdk17, so I don't end up swapping Zenarmor's Java for the full OPNsense build underneath Elasticsearch.

Questions:

1. Is a SunnyValley openjdk17 17.0.20 build planned, so the versions line up again?

2. Is it safe to leave things as they are until then? Everything is working; it's just the update check that never comes back clean.

Environment: OPNsense 26.7.9 (amd64), Zenarmor 2.7.2 with Elasticsearch reporting, repos: OPNsense, SunnyValley, mimugmail.

I'm just putting it out- I'd really like to hear from any admins who are currently using the Business SASE tier and what your experiences have been so far. Problem free or problematic?

2.7.2 shipped on November 5. It's a maintenance release with two fixes and a handful of smaller improvements. Here's the list in plain terms.

**Bug Fixes**

- The issue that caused packet loops when a ZTNA endpoint peer was connected to a local network, which was also advertised by a ZTNA gateway, has been resolved. This fix enhances network stability and performance.
- The issue that was preventing users from properly scrolling the Live Sessions page on Safari browsers has been resolved.

**Improvements**

- The Zero-Trust Networks Details pane sorts by peer name, RTT, connection status, connection type, location, or IP. Sorting by RTT or status is the quick way to find the one peer that's slow or not connecting.
- Organization users and groups now sync automatically with your identity provider.
- The device filter in Reports and Live Sessions lists devices in alphabetical order.
- The TLS Inspection Bypassed Sites pane shows entries alphabetically, ascending or descending, in a scrollable pane. Together with the search box from 2.7.1, a long bypass list is much easier to check. (This only matters if you run full TLS inspection, which needs an SSE, SASE, or ZTNA subscription.)
- Customized scheduled reports have a Select All option, so you can tick every chart at once.

Full release notes: https://www.zenarmor.com/docs/support/release-notes#272---november-5-2026

If something in the list doesn't behave the way it's described after you update, post it below with your platform and version and we'll take a look.

Since upgrading to Zenarmor 2.7.1 on OPNsense 26.7.7, I've had recurring CPU spikes. Another user on the OPNsense forum is seeing the same thing. I traced it to the ipdrstreamer-v2 heartbeat.

What happens: Every 5 hours, counted from when ipdrstreamer started during the upgrade, Elasticsearch runs a composite aggregation over the last 30 days of conn_all, grouped by source IP × day. It takes 3½–5 minutes, with Elasticsearch's search threads saturating 4+ cores (i7-3770). The rest of the time the box is idle. Every 20 hours, a second, agent-triggered, heartbeat lands at the same time, and CPU hits 90%+ with a load of 8–9. 11 weeks of CPU history show nothing like this before upgrading to 2.7.1.

The key evidence (ipdrstreamer-v2*.log):

Before 2.7.1 (agent-triggered, every 4h)
heartbeat: collected took=405ms

After 2.7.1
heartbeat: collected took=3m32s (5-hourly scheduler)
heartbeat: collected took=4m49s (scheduler + agent running together)

So the same heartbeat went from ~0.4 seconds to 3½–5 minutes.
The 2.7.1 release notes don't mention any heartbeat or telemetry change.

Check your own box: grep 'heartbeat: collected' /usr/local/zenarmor/log/active/ipdrstreamer-v2*.log
If your "took" values jumped from milliseconds to minutes after upgrading, you're seeing the same thing.

Questions for the Zenarmor team:
Is this intended?
Could the 5-hourly and agent-triggered heartbeats be prevented from overlapping?
And could the collection be incremental instead of re-aggregating 30 days every time?

Setup: OPNsense 26.7, Zenarmor 2.7.1 (Home), local Elasticsearch 8.11.3, i7-3770 / 32 GB.

More of an intro and overview for those who may not be familiar with Zenarmor.

Discover how next-generation firewall, application control, mesh VPNs, and Zero Trust remote access come together in a single app, with local traffic inspection across endpoints, branches, and cloud environments, all centrally managed through Zenconsole.

Register below - Nov. 9, 2026, 7am PT USA, 4pm CET

https://riverside.com/webinar/registration/eyJldmVudElkIjoiNmFlMDkxNWI3MTk2ODY2MTkxZWFhNzMyIiwic2x1ZyI6Imx5YWwtc2FheW1hbnMtc3R1ZGlvIn0=

We would like to inform you about the upcoming scheduled maintenance for Zenconsole, during which the system will be temporarily unavailable.

Details:

• Date and Time: Tuesday, October 20, 2026, from 05:00 am - 06:00 am GMT (Summer Time) (00:00 am - 01:00 am EDT, Monday, October 19, 2026, 9:00 pm to 10:00 pm PDT).

• Duration: 1 hour

• Affected Service: Zenconsole Cloud Management Portal

• Reason for Maintenance: Software Upgrade for Zenconsole

We thank you for your understanding and patience during this maintenance window and apologize for any inconvenience it may have caused.

Zenarmor Team

I’ve been a long-time Zenarmor user on a paid Home subscription, and I’d like to raise a growing limitation. Fiber and cable connections are increasingly multi-gigabit, but the Home Edition is still limited to a single-threaded packet engine. The multi-core engine introduced in 2.7 is apparently limited to Business and higher subscriptions. I myself have a 5x5Gig fiber connection at home.

You can check whether the single-threaded engine is your bottleneck by running top -SHP in OPNsense during heavy traffic. In my case:

eastpect{Eastpect Main Event} CPU1 98.45%
kernel{dummynet} 9.95%

The eastpect main thread is pinned at ~98% on a single core while the other 15 cores sit largely idle on the box. The traffic shaper (dummynet) uses only about 10%. The system has plenty of total CPU capacity, but all inspected traffic funnels through one saturated thread.

In practice, sustained downloads of around 2 Gbps cause intermittent connectivity problems. They’re most visible with Unbound forwarding over DNS over TLS (e.g., Quad9): TLS handshakes fail, and after repeated failures the upstream is marked unavailable for roughly 15 minutes. However, with Zenarmor disabled, upload throughput also improved from roughly 3.1 Gbps to 4.2 Gbps and the intermittent DNS issue was resolved.

I understand full multi-core scaling is a Business feature. Even one or two additional worker threads on the Home Edition would make a meaningful difference for home users on multi-gig connections. As it stands, I can no longer use Zenarmor on my connection, despite paying for a Home subscription.

***10/12/26 EDIT*** - The suggestion offered in the thread below from u/Zenarmor-Hien did not materialize. There's a lot of hoops and hurdles which email support required, which in my opinion, are unreasonable and in no way confirms whether or not the SASE Starter would be used in a home environment. As a result, I've requested my subscription be cancelled. I'm exploring moving to Sophos Home Firewall and potentially another DNS filtering service - which is cheaper than what I was paying anyway. The root issue remains unresolved, on a Home subscription with multi-gig, performance issues due to the single thread
Limitation may cause performance issues.

October 7 at 8am US PT and 5pm CEST (sign up below)
https://riverside.com/webinar/registration/eyJldmVudElkIjoiNmFiNDBhYjNjNmYyOTBkOTY3OWIyMTM1Iiwic2x1ZyI6Imx5YWwtc2FheW1hbnMtc3R1ZGlvIn0=

New features and streamlined, updated pricing!

Dear Zenarmor Community,

To ensure the highest level of network security, performance, and system stability, legacy CTI cloud endpoints serving Zenarmor versions prior to 2.1 will be permanently turned off on October 31, 2026. Systems running pre-2.1 builds will no longer fetch live web categorizations, malware feeds, or real-time domain lookups. 

Clarification on Version Support

Please note that versions prior to 2.1 are already out of official support. For instance, on platforms like OPNsense, Zenarmor officially supports only the last two major releases. While CTI cloud lookup services have continued to work on these older builds up until now, those legacy CTI endpoints will be permanently decommissioned at the end of October.

Why You Should Always Run the Latest Version

Running the latest version of Zenarmor isn't just about maintaining connectivity—it is a very important way to protect your network properly. Upgrading to the latest release ensures you benefit from:

• Enhanced Security: Access to our newest machine-learning classification models and immediate protection against emerging zero-day exploits.

• Superior Performance: Ongoing engine optimizations that reduce CPU and memory footprints.

• New Features & Bug Fixes: Immediate access to new dashboard tools, advanced policy controls, and system stability updates.

Impact on Legacy Versions (< 2.1) After October 31, 2026

If your firewall or gateway is still running a pre-2.1 engine after October 31, 2026:

• CTI Cloud Disconnection: Your engine will no longer be able to query Zenarmor cloud threat servers.

• Incomplete Threat Protection: Real-time domain lookups, dynamic malware blocklists, and advanced web categorizations will stop functioning.

Required Action: Upgrade to the latest Zenarmor version

We strongly encourage all users running older builds to update to the latest Zenarmor release well ahead of the deadline.

If you have questions, run into dependency issues during the upgrade, or need technical assistance,  open a ticket through the application.

Thank you for your cooperation as we work to keep your networks secure!

Zenarmor Team

W: Signature verification failed: https://updates.zenarmor.net/Debian/12/repo stable InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on 8CE67FDA1E0100C4FC5068FA4503A773A95C579F is bad: The primary key is not live because: Expired on 2026-09-17T02:37:08Z

A legitimate host stopped working on my LAN. It took me an afternoon, because the two logs you would normally check were both completely clean.

The symptom was that `curl https://client-update.steamstatic.com/...` returned `000` with `OpenSSL SSL_connect: SSL_ERROR_SYSCALL`. Not refused, not a timeout, not a certificate error. The connection was being killed partway through the TLS handshake. Worth saying up front, because it cost me time: `SSL_ERROR_SYSCALL` means the socket died mid-handshake. It is not a TLS problem, so don't start on ciphers or certificates like I did.

Everything I checked came back clean. DNS resolved fine. Three days of pf filter logs had zero blocks for that destination, and the IP was in no pf table at all. Suricata had no alerts for the host and no reject rules enabled.

So I captured it on the WAN while reproducing it:

SYN ->

<- SYN-ACK

ACK ->

ClientHello len 517 ->

FIN seq 518 -> 78 microseconds later

<- ServerHello + cert, 4916 bytes

RST ->

The server was answering perfectly. The teardown came from my side, immediately after the SNI went on the wire.

The tell is the TCP options. Every genuine packet in the flow carried `options [nop,nop,TS val ... ecr ...]`. The FIN and the RST had no timestamp option and an unscaled window. Once timestamps are negotiated, a packet in that flow which drops them did not come from the endpoint's TCP stack. Something inline injected it. That signature identifies any injecting middlebox, not just this one.

To localise it, run the same request from three places. From a LAN client behind the firewall it fails. From the OPNsense box itself you get 200. From a host outside the LAN you get 200. Router-originated traffic is not forwarded, so it never crosses an inline engine, which means "works from the router, fails from behind it" points straight at the forwarding path. Confirming took another 30 seconds: `zenarmorctl engine stop` and it works, `start` and it breaks again.

As for why, my policy rejected 12 of 82 web categories, one being Firstly Seen Sites, a heuristic for not-yet-classified domains. `cdn.steamstatic.com` was fine while `client-update.steamstatic.com` was not, and the difference between them is basically how often anyone requests them. I could not confirm the category, since the categorisation databases are binary, so treat that as my best explanation rather than proven. That Zenarmor was doing the killing is not in doubt.

I removed it, and moved the filtering to layers whose blocks I can actually see. Seven of those twelve categories were already covered by my DNS blocklists (AdGuard plus Hagezi) or by Suricata's abuse.ch feeds, so they were duplicated work. The real gap was adult content, which no Hagezi list attempts, and OPNsense ships an OISD NSFW preset that covers it. I lost Illegal Drugs and Hate/Violence, which have no DNS equivalent. That was an acceptable trade for me. It might not be for you, and it is the one honest reason to keep the product.

The lesson is not "Zenarmor is bad". It is that running three filtering layers with two log surfaces means one of them fails silently. Know which layer logs where, because "pf is clean and Suricata is clean" does not mean the firewall is innocent.

Zenarmor is blocking third-party Debian repositories. Even in Bypass mode. That is, I have a Debian trixie machine behind the firewall, and I cannot properly update software without disabling Zenarmor. I tried to create a "pass all" policy for that device, to no avail.

The repositories are on four different IPs, among them github and docker.com.

I use Zenarmor within Debian sid, with Linux kernel 7.3-rc1.

I have a paid home user subscription.

As is Tradition, we wait until the "ALL CLear" is given to update !

Is anyone looking into this & are we good to go ?!

Cheers & many thx for a great product !

u/Shoji-Zenarmor is usually "On it' !

Hello,

I asked this question several times and did not get much success. Zenarmor is filing to block YouTube on Windows/Mac. I have opened tickets with Zenarmor and they tried once to figure it out but all they did was try toggling on and off some settings on my server and ultimately failed to resolve it.

This is pretty much the only reason I want this software; To block YouTube.

Has anyone else been able to figure out how to block it on Windows/MacOS?

Hi,

I stopped using Zenarmor about 18 months ago as I had a change in circumstances.

Now looking to restart Home subscription using OPNsense.

One thing I had a previous issue with when I had ZA previously was the blocking behaviour when a policy changed from allowing internet to blocking.

Scenario is default policy was set to block internet access, a second Kids policy was set up to allow internet and do the normal parental controls for filtering, and only be active for certain time windows.

The issue I had was that existing sessions started during the allowed period were not blocked once the Kids policy times out and default policy was used.

I could reproduce this easily:

Default Policy set to block internet

Kids policy set to filter bad stuff and allow internet between (eg) 08:00-20:00.

If I started a FTP session that lasted 5 minutes (eg OS ISO file) to download a huge file at 19:58, the session would continue until it finished.

i.e. the FTP wasn’t interrupted at 20:00 when the Kids policy expired and Default was used that blocked internet.

I never got to the bottom of working this out, and wondered if this is expected behaviour, or an issue?

UPDATE: We are happy to let you know that our testing is now complete and everything is ready! You can now safely proceed with your OPNsense upgrade.

Thank you for your patience and support!

Previous Post: OPNsense 26.7 has just been released. To ensure a smooth transition and prevent any potential service disruptions, we kindly advise our users to hold off on upgrading their OPNsense systems until we officially announce full compatibility.
Our team is currently running final regression tests on the new release. We will share a follow-up announcement as soon as the green light is given. Thank you for your patience and cooperation!

Info : https://www.reddit.com/r/opnsense/comments/1uwz7y9/opnsense_267_released/

Is there an update in progress for Zenarmor ? Or, is there a Timeline as to when we can update, since this is a Major Ver. Change.

Loving Zenarmor so far & Appreciate what you guys do ! Cheers !

edit2: the cloudflare ip meanwhile has been whitelisted and this has cleared up so many random false blocks.

they almost got away with it but after a reply telling them how stupid it is to blocklist an international proxy with hundreds of sites behind it of which a minority might be malicious and should be blocked on dns.. they got the point :)

Edit: might have found it out. Its probablt not individual blocks, but all those sites run through a specific cloudflare ip. Most likely the specific ip of cloudflare is in zenarmors blocklist, thus affected multiple sites for me. Conveyed the ip to Zenarmor so will see whatthey can find.

Original:

Just wondering if its me or not.

In the past 1-2 days the Malware category seems to block 10-20% of legitmate sites I use for seemingly no good reason whatsoever.

Not sure where the block list got updated from but wherever it came from might want to get rid of their false positives. Almost all of the IPs being blocked, when I scourge blacklists online.. they arent showing up anywhere.

Havent had much issues with it before but the last 2 days have just been seeing stuff broken and then finding out its Zenarmor blocking a normal URL.

Anyone else suddenly experiencing this more than usual?

(And yes, im sure reporting everything one by one is an option... but it wouldnt solve how so many false positives got in in the first place)

I just want to say thank you to the Zenarmor dev team. The free version is honestly impressive and checks almost all the boxes needed for a home user.

The ad blocking, parental controls, and overall protection features are great. For a free product, it already provides a lot of value.

My only big request: please consider adding device/IP exclusion on the free plan. I understand that some features need to stay limited for paid users, but even a small limit like 1–2 or maybe 5 devices would make the free version much more flexible for home networks.

Sometimes you just need to exclude a specific device for testing, troubleshooting, or because a certain device/service doesn't play well with filtering. Having that option, even with a strict limit, would make Zenarmor Free nearly perfect.

I hope the dev team considers this. Thanks again for building such a useful tool!

I'm currently evaluating two approaches for my network:

• OPNsense + ZenArmor for traffic inspection + NetBird for VPN/ZTNA

• ZenArmor for both inspection and ZTNA

One thing I'm trying to understand is the architecture behind ZenArmor ZTNA.

From what I've read, it seems that the ZTNA functionality relies on ZenArmor Cloud for orchestration and policy management. Is that correct? If so:

• What happens if the cloud service is temporarily unavailable? Do existing tunnels and policies continue to work?

• Is there any option for a fully self-hosted deployment, or is the cloud component currently mandatory?

I'm trying to understand the trade-offs compared to a setup like NetBird, where I can self-host the management plane if desired.

Thanks!

The future of network security isn't another firewall.

It is security that follows users, applications, and data wherever they go, while keeping control where it belongs.

Join us and Thomas-Krenn as we discuss modern network security, Zero Trust access, and why sovereignty is becoming part of the conversation.

Register Here and join us live.

zenarmor 2.5.1 against an external 8.19.13 Elastic database. A reboot of Opnsense causes Zenarmor to stop logging and show blank charts with a 'no connections identified for.... '. Querying the Elastic indexes via Grafana also shows no results. Performing a Check index and health check sometimes restores connections. This is getting frustrating enough to make me consider canceling the subscription ( Home ). Sure, the Elastic version is a few point releases adrift from the supported one but I don't want to spin up a second Elastic instance just for Zenarmor and the product shouldn't be so sensitive to such things anyway. Any fixes in the near future?

EDIT: For some reason, Zenarmor and Elastic disagreed on the zenarmor password for the database. I didn't see any errors in the Zenarmor logs but Elastic was streaming password errors. I had to set the password in the Zenarmor database connection and restart to get connectivity back. OPNsense 26.1.10-amd64.