Messages

If this message is being revisited, it would help to also add some form of rate-limiting to it. At the moment it re-appears every session, which gets old fast. Showing it once a week (or once per change to the RSS setting) would be plenty.

I already raised this via helpdesk request #14474 (April 2026).

Recently, I have encountered an issue where OPNsense more often than not stops progressing during boot. In most cases, it stalls at the "Setting up gateway monitoring" step. My WAN uses PPPoE over VLAN, with DHCPv6 prefix delegation enabled. It remains stuck indefinitely until I manually trigger a network-related action in the GUI, after which startup continues normally.
As a precaution, I reset the gateway monitoring part of the configuration files to defaults, but this didn't make any difference.

Disabling the DHCPv6 rapid commit option appears to make the issue occur less frequently. However, it is unclear whether rapid commit is the underlying cause or whether disabling it merely masks the problem by changing the timing of the boot and interface configuration sequence.
If I disable IPV6 completely in the WAN interface, the system always boots normally.

The logs suggest that dhcp6c, PPPoE link events, and rc.newwanipv6 may be running concurrently. I see repeated interface reconfiguration and Can't assign requested address errors, which makes me wonder whether this could be a timing or ordering issue during boot.

I am running OPNsense 26.7.2_2 (amd64). Is there any way I can assist in solving this by providing logs or try out things?

Code Select Expand

18:49:46 rc.bootup: plugins_configure bootup (execute task : unbound_configure_do(1))
18:49:51 dhcp6c: rtsold_script: starting dhcp6c
18:49:51 dhcp6c: Sending Solicit on pppoe1
18:49:52 dhcp6c: Received REPLY for REQUEST
18:49:52 dhcp6c: create a prefix .../48
18:49:53 rc.newwanipv6: IP renewal deferred during boot on 'pppoe1'
18:50:54 /interfaces.php: plugins_configure dhcp (,inet6,[lan])
18:50:54 dhcp6c: restarting
18:50:54 dhcp6c: Start address release
18:50:54 dhcp6c: Sending Release on pppoe1
18:50:54 dhcp6c: remove a site prefix .../48
18:50:54 ppp: caught fatal signal TERM
18:50:54 ppp: [opt1] IFACE: Close event
18:50:54 ppp: [opt1_link0] PPPoE: connection closed
18:50:54 rc.newwanip: IP renewal deferred during boot on 'pppoe1'
18:50:55 dhcp6c: Sending Solicit on pppoe1
18:50:55 dhcp6c: transmit failed: Can't assign requested address

rc.newwanipv6: IP renewal starting (reason: request, ... device: pppoe1)
rc.newwanipv6: plugins_configure dhcp (,inet6)
rc.newwanipv6: ROUTING: entering configure using opt1, lan
rc.newwanipv6: plugins_configure monitor (... INTERNET_DHCP6)

/interfaces.php: The required INTERNET_DHCP6 IPv6 interface address could not be found, skipping.
dhcp6c: Sending Solicit on pppoe1
dhcp6c: transmit failed: Can't assign requested address
rc.newwanipv6: IP renewal starting (reason: force, address: misconfigured, ...)



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.