Messages

I was able to fix it by deleting the certificate and re-creating in the ACME config.
Seems like only changing the provider from hetzner to hetznercloud does not apply for the existing configuration.

Meanwhile I checked the files and the version seems the new one (that I deployed, mentioned in my last post)

It looks more like strange behaviour in the GUI / Configuration.


In the OPNsense ACME GUI, the DNS provider hetznercloud is explicitly selected. Despite that, ACME behaves like the legacy hetzner provider.

This is clearly visible in the acme.sh logs, which show usage of the legacy DNS API endpoint:

2026-01-10T22:20:58 acme.sh[Sat Jan 10 22:20:58 CET 2026]
url='https://dns.hetzner.com/api/v1/zones?name=org';


The same behavior occurs in both Business and Community editions of OPNsense.

I compared the file dns_hetznercloud.sh against the upstream version from the acme.sh GitHub repository, and it looks correct and up to date.


When hetznercloud is selected in the GUI, acme.sh should use the Hetzner Cloud DNS API via: https://api.hetzner.cloud/v1 as documented in the current Hetzner Cloud DNS API reference.

Is it possible that there is an issue in the OPNsense ACME GUI mapping, where selecting hetznercloud still triggers the legacy hetzner provider internally (or passes the wrong parameters to acme.sh)?

Thanks Franco!

I followed your suggestion and the upgrade itself worked fine (installed the CE packages via pkg add -f and the ACME client is now on the newer version).

However, the DNS-01 flow still fails and the logs show that acme.sh is still using the old Hetzner DNS API endpoint:

it calls https://dns.hetzner.com/api/v1/zones?...

resulting in Error adding TXT record ... Invalid domain

From what I can see, the upstream acme.sh implementation for Hetzner Cloud DNS uses the new Cloud API (https://api.hetzner.cloud/v1/...) in dns_hetznercloud.sh, e.g.:  https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_hetznercloud.sh

So it looks like the plugin update did not bring in the expected dns_hetznercloud behavior (or the OPNsense-packaged acme.sh dnsapi scripts differ from upstream / are not updated accordingly).

Hi,
I'm running OPNsense Business Edition 25.10.1_2 and noticed that the Community Edition already ships os-acme-client 4.11, which includes additional DNS providers (Hetzner Cloud).

On Business, the plugin is still on an older version and the provider is therefore not available.

My question:
Is there any supported way to pull os-acme-client 4.11 into the current Business release (25.10.1_2), or is this strictly tied to the Business plugin freeze and only possible with a future Business update?

ended up, having all WAN (1G) ports at queues=1 and all LAN (10G) ports at queues=2. I guess LAN ports could be set to 4 or 8, I just currently have no time for deeper tests and performance seems to be the same as before.

It made all working again. Especially having WAN ports at 4 I also had weird issues with gateway groups. Doesn't matter if load balancing or failover mode, there were connection issues (instable) to SSH targets.

Hi
I'd try to export configuration, do the replacements/re-mappings (simply search and replace) there and import it back.

[Setup (simplified)]

Hello,

I am running OPNsense 25.10.1_2 (Business) as a virtual machine (KVM/Proxmox) and am experiencing a reproducible issue with Suricata IPS in combination with Insight (flowd_aggregate).

Setup (simplified)

• OPNsense running as a VM in ProxMox (9.1)
• Multiple WAN interfaces (Multi-WAN setup)
• Suricata enabled (for WAN interfaces only)
• Insight / Traffic graphs enabled

Observed behavior

• With Suricata disabled → Insight and traffic graphs work normally.
• With IPS enabled + Promiscuous mode OFF → Insight works.
• With IPS enabled + Promiscuous mode ON →

          Traffic graphs stop updating after ~1 minute
          Insight data disappears
          flowd_aggregate fails to start

I see that flowd_aggregate service does not start with:
"WARNING: failed to start flowd_aggregate
Unable to lock on the pidfile"



Is this a known limitation of Suricata IPS + Promiscuous mode on Multi-WAN, especially in virtualized environments?

Is there an official recommendation or roadmap regarding Insight compatibility with netmap/IPS in such setups?


Thanks in advance for any clarification or confirmation


*update*
Looks like it has something to do with the queues setting on the configured VM interfaces in ProxMox. Still investigating...

[Packet Loss or High Latency]

Hi

there is a difference between documentation and the implementation of the trigger levels in gateway groups.
Maybe somebody can confirm how it is implemented, I'm talking here about the Packet Loss or High Latency trigger.

The documentations says, there is a OR - but in the current UI there is a AND. I did some tests and it seems to be a AND operator how it is being ipmlemented.

*added related screenshots

have the same challenge, not wanting to go with additional router in front of the OPNSENSEs. Not sure how to monitor the WAN gateway insead of using CARP, as I have only one WAN address.

hey

I'm currently running OPNsense on my Proxmox cluster and have encountered an issue where the Suricata service stops after a failover. While I can restart the service manually without any problems, I'd like to fix it - or at least to automate this. I believe that Monit could do that.

I've attempted to set up Monit to monitor the Suricata service I'm not certain about the correct configuration parameters, especially regarding the PID file and the appropriate start/stop commands.

Has anyone ideas how to fix it, or anyone has successfully configured Monit to monitor and automatically restart the Suricata service in OPNsense?

thx

hey

I see some packets are being blocked coming from a S2S wireguard tunnel to the OPNSENSE. On the other side (also OPNSENSE) I don's see any device that is talking on that port.

Does anybody have an idea how to investigate that?

Topology is:
OPNSENSE1 <---S2S WG-->OPNSENSE2

thx

Hi

is there a general difference in using static routes configuration vs configuring routes using FW rules and pointing them to the right gateway?

I did some tests and both works, I see more flexibility in using FW rules. Would like to ask if there is a general case when static routes should be used?

thx

figured out it was an issue within the zenarmor installation. I was not able to save any change without a error message about the configuration.
In the end I had to reset the config and re-install zenarmor to get it back to work.

Hi

the service stopped working after updating to 22.10 business edition. This is what I can see in the logs, tried to activate on different interfaces, all the same issue.
Any ideas?

Code Select Expand


2022-10-31T11:39:31 Error suricata [107141] <Error> -- [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - opening devname netmap:ix0/R failed: Cannot allocate memory
2022-10-31T11:39:02 Error suricata [107014] <Error> -- [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - opening devname netmap:igb5^ failed: Cannot allocate memory
2022-10-31T11:38:35 Error suricata [106896] <Error> -- [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - opening devname netmap:igb5^ failed: Cannot allocate memory
2022-10-31T11:38:08 Error suricata [106796] <Error> -- [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - opening devname netmap:igb5^ failed: Cannot allocate memory
2022-10-31T11:12:50 Error suricata [101682] <Error> -- [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - opening devname netmap:igb6^ failed: Cannot allocate memory
2022-10-31T11:10:00 Error suricata [100664] <Error> -- [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - opening devname netmap:igb6^ failed: Cannot allocate memory

greY

Hi @mb
yes I'm referring to th OPNsense Business Edition.

Versions   
OPNsense 22.4.3_1-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1q 5 Jul 2022

Zenarmor
Engine Version:   1.11.5
UI Version: 22.9.22
Database Version: 1.11.22092202