Messages

In Firewall > Aliases you can create a "URL Table (IPs)" alias that periodically re-fetches its contents from a remote source (e.g. Cloudflare's official IP ranges), so the alias stays current without manual maintenance.

The Caddy plugin's Access Lists (Services > Caddy > Access) only support static, manually entered CIDR blocks. For something like a Cloudflare IP list, this means every range change on Cloudflare's end has to be applied by hand, otherwise the list silently drifts out of sync.

Would it be possible to either:

• let an Access List reference an existing Firewall alias, or
• give Access Lists their own periodic remote-fetch option, similar to URL Table aliases

so lists like this stay in sync automatically instead of requiring manual upkeep?

Not exactly the same issue, but this has bitten me before.

Unbound has a hardcoded list of "special-use" zones that are treated as local and won't be resolved normally unless you explicitly override them in the configuration. Unfortunately, this cannot be configured through the OPNsense GUI, only through a manual Unbound config override.

The examples in the OPNsense documentation don't use any of these special-use domain names, which is why the forward lookup examples work as expected. The reverse lookup examples, however, do not work if they point to RFC 1918 address space. As soon as you use one of the domains listed below, the documented examples no longer behave as intended unless you add an explicit `local-zone: "<domain>." nodefault` override.

The list includes:

Code Select Expand

localhost.
127.in-addr.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
home.arpa.
resolver.arpa.
service.arpa.
onion.
test.
invalid.
10.in-addr.arpa.
16.172.in-addr.arpa.
17.172.in-addr.arpa.
18.172.in-addr.arpa.
19.172.in-addr.arpa.
20.172.in-addr.arpa.
21.172.in-addr.arpa.
22.172.in-addr.arpa.
23.172.in-addr.arpa.
24.172.in-addr.arpa.
25.172.in-addr.arpa.
26.172.in-addr.arpa.
27.172.in-addr.arpa.
28.172.in-addr.arpa.
29.172.in-addr.arpa.
30.172.in-addr.arpa.
31.172.in-addr.arpa.
168.192.in-addr.arpa.
0.in-addr.arpa.
254.169.in-addr.arpa.
2.0.192.in-addr.arpa.
100.51.198.in-addr.arpa.
113.0.203.in-addr.arpa.
255.255.255.255.in-addr.arpa.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
d.f.ip6.arpa.
8.e.f.ip6.arpa.
9.e.f.ip6.arpa.
a.e.f.ip6.arpa.
b.e.f.ip6.arpa.
8.b.d.0.1.0.0.2.ip6.arpa.
This is upstream Unbound behavior rather than something specific to OPNsense.

Are you still using Elasticsearch 5? It's deprecated and no longer supported. You should switch to Elasticsearch 8 which is the currently supported version.

I've noticed xxx.xxx.xxx.xxx is flagged as suspicious in Q-Feeds.

On top of that, the OPNsense GUI doesn't currently offer a way to whitelist an IP address for either the firewall blocklist or the Unbound blocklist. Combined with the free tier's 24-hour update frequency, this leaves me with two unappealing options: run a manual override at the firewall rule or Unbound config level, or disable Q-Feeds altogether until the update has propagated to my system. Neither feels like the right tool for what should be a simple exception case.

Edit: redacted because this has been resolved through a report in the Q-Feeds portal.

Done, it's here: https://github.com/opnsense/core/issues/10547

Nice feature, thanks. I did however run into a GUI issue with it: the drop-down itself scrolls fine, but the row above it that displays the selected entries as tags keeps expanding horizontally as you add more selections, until it overflows the viewport. Once that happens, the reset button is pushed off-screen and becomes unreachable.
Expected behavior: the selected-entries row should wrap onto multiple lines once it reaches the container width, so the reset button stays visible regardless of how many entries are selected.

Worth adding some context here: MongoDB support in Zenarmor isn't pending deprecation, it's already gone. As of Zenarmor 2.5 (September 2025), both MongoDB and Elasticsearch 5 were dropped as reporting backends, and new installs no longer offer MongoDB as an option at all. That's probably why this warning shows up on some 26.7 upgrades: php83-pecl-mongodb is a leftover dependency from an older Zenarmor version that used to require it, not something anyone installs on purpose (as Franco noted, OPNsense never installs it directly). Anyone still running the old MongoDB backend should migrate to SQLite for small setups or Elasticsearch 8 for larger ones (8GB+ RAM recommended for ES).

Worth keeping in mind: with quick-match rule evaluation (the pf default), the first blocklist rule that matches gets the hit, and the packet never reaches the rules below it. So whichever list sits highest in your rule order absorbs most of the hits for any IP that's on multiple lists, regardless of which list is actually better. Comparing hit counts across blocklists to judge quality is therefore skewed by rule order, not just list coverage. For a fair comparison, log all lists in parallel (pass-with-log instead of block) or rotate the rule order periodically.

I've run Zenarmor for 5 years now, and I've decided to cancel my subscription (turned off auto-renewal). The form on the website only allows 200 characters, so wanted to lay out the reasoning properly here, partly as feedback, partly because I suspect other home/SOHO users are weighing the same trade-off.

The core issue is that the value-for-money for a non-commercial, single-site deployment has eroded over time. Each release seems to move more functionality behind premium tiers priced for businesses, not individuals. That's a reasonable strategy if the target market is enterprise, but it leaves home users increasingly squeezed: paying for capability that used to be standard, or going without.

The development roadmap also reads as enterprise-first. Centralized management, multi-tenant features, advanced reporting: all sensible for MSPs and larger deployments, but largely irrelevant to a single firewall at home.

What tipped this from "frustrating" to "not worth it" is multi-core support being restricted to paid subscriptions. For anyone running OPNsense on older or budget hardware, that's not a nice-to-have, it's the difference between Zenarmor being usable at all and pegging a single core under load. Gating it behind a premium plan effectively prices out the exact hardware profile where the feature matters most.

For context: as a home/SOHO user I've never minded being treated as a kind of beta tester. I appreciate the direct line to the developers through the forum and email, and genuinely enjoy contributing to the product's development. That's actually what makes this decision sting more than a simple price complaint would: paying for what is, in practice, a deliberately limited version of the product feels at odds with that relationship.

I don't doubt the engineering effort behind the product, and I understand a company needs a sustainable business model. But the current tiering no longer makes sense for my use case, so I'll be switching back to a lighter inline IDS/IPS setup. Curious whether others here have reached the same conclusion or found a tier that still works for home use.

Where can I find this list of softcoded tunables? I would very much like to compare these to what is currently in my tunables list, to weed out any old cruft.

I'm seeing a consistent delay of ~9.6 seconds when opening the Events page for the first time in a session. Subsequent loads within the same session are near-instantaneous.
This pattern strongly suggests a timeout or cold-start issue on initial load (lazy initialization, an idle backend connection being re-established, or a network call with a long timeout before fallback). I haven't been able to confirm the root cause from the client side.
Could you look into what's happening on first access? Happy to provide additional diagnostics if useful.

If default tunables have been removed from the codebase for some time now, why does my current config still show roughly 60 entries without a delete icon?
Are these considered user-defined tunables that OPNsense simply cannot distinguish from defaults, or is the missing bin icon a UI bug / a sign that they are still treated as system-owned?

The output displayed in System > Firmware > Updates (both firmware upgrade output and audit results) is not streamed line-by-line. Instead, output appears to be buffered and flushed in large chunks, causing long pauses followed by sudden bursts of text. Live streaming would give better visibility into progress.

[Promo for existing users]

Clicking on my account name on the top-right gives me these menu options: Dashboard, Orders, Subscriptions, Downloads, Address, Payment methods, Account details, Log out

In none of these I'm able to enter a license code for the trial. The Orders, Subscriptions and Download page only point to a generic 'Browse products' link.

Promo for existing users

If you've already used your premium trial, you can test the new functionality for 7 days with this code:

Code Select Expand

1-WEEK-THREAT-LOOKUP
You can activate this code by clicking on your account name on the top-right and then go to licenses -> activate licenses.

Same here. I'm using the community version, and I noticed it only updates every 48 hours. After cleaning the aforementioned directory, the interval dropped to 24 hours. I also noticed that the newly downloaded malware_domains file is nearly twice as large.

Code Select Expand

# ls -la
drwxr-x---   2 root wheel       5 Apr  7 19:27 .
drwxr-xr-x  24 root wheel      31 May  5 16:22 ..
-rw-r-----   1 root wheel    1874 May  8 02:38 index.json
-rw-r-----   1 root wheel 2567937 May  7 02:38 malware_domains.txt
-rw-r-----   1 root wheel 6028981 May  7 02:38 malware_ip.txt
# ls -la
drwxr-x---   2 root wheel       5 May  8 20:40 .
drwxr-xr-x  24 root wheel      31 May  5 16:22 ..
-rw-r-----   1 root wheel    1874 May  8 20:40 index.json
-rw-r-----   1 root wheel 4586976 May  8 02:38 malware_domains.txt
-rw-r-----   1 root wheel 5998330 May  8 02:38 malware_ip.txt