Messages

You might want to mention :
- PPPoE
- IPTV = Yes/No ?
- UFS or ZFS ?

PPoE = yes
IPTV = yes
ZFS = yes (obviously ;-))

There are new capabilities to define vlan filtering and per port untagged vlan settings but they will not be implemented in OPNsense since a router is not a managed switch.

Agree. ;-)

So if you need some untagged stuff you might still need the old bridge setup where you bridge single vlans with a single port or whatever you did there.

Thanks for looking into it :)

I'll probably move my IPTV VLAN (now a local VLAN 40 on igb0 physical port, which is the trunk to a managed switch near my TV) to the bridge (now multiple igbXX, including igb0) which is the LAN (basically combining multiple ports into a single interface (i.e. a switch ;-)). Current setup chosen since I also need the normal LAN (connected to internet) on the managed switch.

With the IPTV VLAN (interface) moved to the bridge (or a new VLAN for testing), it should work out of the box... IGMP proxy etc works on IPs and interfaces. This was not possible earlier.

EDIT: on the other hand... thinking about it.... This might cause a lot of crap on the bridge ports other than igb0... While the IGMP Proxy is obviously on OPNSense, IGMP snooping is not... That is a switch thing.... Need to think some more.

Just to note, my IPv4 based setup on KPN FttH in NLD works great on 26.7.1. Upgrade from latest 26.1 worked in one go from GUI. I use a Qotom i5-8G box with 8x intel 211 NIC.

I use DNSMasq (DHCP, DNS) and Unbound for upstream recurrence DNS (from DNSMasq) with blocklists. Also have HAProxy reverse proxy with multiple services behind it. SSL is done with wildcard certificate on ACME (plugin).

Compliments for the smooth transition. :)

It was merged today, if you want to use it right away you can try it on 26.7.1 with the following command

Tests welcome :)

PS:

My test setup looked like this:

Attention: I only used tagged vlans.

Thanks! I will try and get some time to test it. Not all my physical ports on the OPNsense box are connected to a VLAN capable switch. Some bridge ports are connected to clients directly, such as IoT devices (bridge used there as IOT LAN interface).

On the tagged VLANs... Isn't tagged the only way to process correctly in OPNsense. Untagged would not really make sense to separate stuff, right? From the looks of it, an untagged VLAN cannot be defined in the VLAN interface setup. :)

https://github.com/opnsense/core/issues/10576

https://github.com/opnsense/core/pull/10584

Thanks for the update. Just to make sure, it is not in OPNSense 26.7.1, correct? While I do not require this feature at this time (currently bridging VLANs), I have upgraded to 26.7.1 and I checked the VLAN setup page in Interfaces/Devices/VLANs and was unable to add a VLAN to a bridge interface.

I started this topic from a genuine interest in getting the whole certification chain "secure". Not a rigid requirement as I am in a happy place, I trust the network behind my OPNSense. Therefore I am happy to do end the "correct" certificate chain at the firewall and have self-signed stuff behind my reverse-proxy. this works fine and achieves the goal of having the SSL checks and balances on the internet correct (also in the browser), all the way to the backend services.

midclt, https://github.com/truenas/api_client, is required for using TrueNAS websocket API.
The script may work after installing it.

Also, midclt isn't what you linked on github. You linked to a script that calls `midclt` LOCALLY, which in turn is present by default on any TrueNAS install.

Now, this is incorrect. fragrance744 is correct. midctl is designed for remote use. midcli (t=i) (https://github.com/truenas/midcli) is local tool and in ALPHA state. Single letter difference, both on GitHub.

I'll ask again: why not use SSH with public key authentication to execute the midclt command on TrueNAS from OPNsense?

Personally, I am unable to get this working (maybe I can spin up my Claude AI... ;)). While midclt is installed by default on TrueNAS, it should be possible to also use the Websocket API from plugin code, right? This is imho the most elegant solution its per-design way of doing thing.

Bummer is that I am not a developer, am not sure if my aforementioned ideal solution is possible, but let's play nice to each other. I am very happy with the community to build the plugins with all the cool options that OPNSense is bringing to the table. I would contribute if able, and vibe-coding something without understanding its full working is something that creates shortcircuits in my head.

Bottom-line and summarizing there are five viable options:
1) Do not complete the cert chain all the way to the backend services, stop it at the reverse proxy and use selfsigned from there to the backend (my current solution, fine for my home network)
2) Use the SSH option that Patrick suggests and run midclt on the TrueNAS box locally. Basically this also uses the Websocket API, but only through the localhost. The API on TrueNAS apparently listens on localhost as well.
3) Use the ACME client automation with the older implementation. This works for TrueNAS 25.x.x and older.
4) Install the midclt on the OPNSense box. Hopefully this would make ACME client plugin automation (Websocket API) work again and use that. If not, this would require (shell) coding eveything on the OPNSense box. I would say "revert to 2)"
5) Update the ACME client plugin and code something that does not rely on midclt. Basically, remove the apparent bug from this piece of plugin.

The bigger change might actually be openssl 3.5.x in 26.7 for the packages

Arent't pf changes like VLAN on bridges a massive change as well? Can imagine that this would require a substantial change in the opnsense logic etc.

Shouldn't the automation "simply" use SSH to execute whatever is necessary on the TrueNAS system, including midclt?

I am not skilled enough to check what the acme client and plugin does on OPNSense (use local midctl OR remote calling through SSH or something else HTTP calls etc.). What I understand is that midctl is/was intended to make calling the TrueNAS API as easy as possible.

[Thu May 14 14:56:38 CEST 2026] Checking TrueNAS health...
/usr/local/sbin/acme.sh: midclt: not found

It seems to be a part of this:
https://github.com/truenas/api_client

Thanks for finding this apparently missing API client. I reproduced this missing midclt also from a shell. Not sure why it does not show up in the system logs though. ;-)

In either case it looks like it expects TrueNAS as OS, not OPNsense.

Cheers,
Franco

What's in a name... the TrueNAS client apparently called midcli and the one ceel references (https://github.com/truenas/api_client) is midclt. To make it more confusing both the clients seem to be preinstalled on a TrueNAS box according to the GitHub documentation.

Anyway,

• the midcli is the NAS cli interface —> that is preinstalled and can only be used (in my understanding) on the TrueNAS box.
• The midclt is not installed by default, at least not on my TrueNAS scale box (25.10.3.1). It is compatible with TrueNAS SCALE (Debian based) according to the docs both also to run from non-TrueNAS clients. "TrueNAS comes with this client preinstalled, but it is also possible to use the TrueNAS websocket client from a non-TrueNAS host."

Hence, imho the midclt could be used (assumption here, if the code works on FreeBSD...) to complete the deployment task.

If you want to dive even deeper: try to query the TrueNAS API endpoint "system.ready" using `curl` and your API key. The API documentation is available here:
https://www.truenas.com/docs/api/scale_websocket_api.html
It should make the root cause more obvious, but crafting the `curl` command might be a challenge.

I'll start by fiddling with cli on the TrueNAS box, the api client. See where I end up there

Hmmm... okay.. wasn't aware that TrueNAS API needed any configuration, but I'll dive into that one next. Thanks! I'll report back when I find something.

[Does this has something to do with setenv being done once (at the HTTPS scheme that worked) and that the system now has an API key but with older value..? I tested the old scheme first today to check my understanding before retrying the Websocket with new key. So, initialization thing?]

OK... So, I flicked open my iPad and tried again, as suggested.

Firstly I tested the deprecated API system. That worked as expected when filling in the values and with a new API-key. Used the HTTPS scheme and it exported the certificate as it should. No errors. Ohh, and leaving out the "X-" integer index does break the API and generated an API key error. Tested both, so answered my own question.

ACME log working:
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] Success
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] Reloading TrueNAS web UI
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] Deleting old certificate
2026-05-05T20:59:25acme.sh [Tue May 5 20:59:25 CEST 2026] FTP certificate is not configured or is not the same as TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Checking if FTP certificate is the same as the TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] S3 certificate is not configured or is not the same as TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Checking if S3 certificate is the same as the TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] WebDAV certificate is not configured or is not the same as TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Checking if WebDAV certificate is the same as the TrueNAS web UI
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Current activate certificate ID: 5
2026-05-05T20:59:24acme.sh [Tue May 5 20:59:24 CEST 2026] Fetching list of installed certificates
2026-05-05T20:59:21acme.sh [Tue May 5 20:59:21 CEST 2026] Uploading new certificate to TrueNAS
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Getting current active certificate from TrueNAS
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Detected TrueNAS system version: unknown
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Detected TrueNAS system os: unknown
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Getting TrueNAS version
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] TrueNAS system state: "READY".
2026-05-05T20:59:20acme.sh [Tue May 5 20:59:20 CEST 2026] Testing Connection TrueNAS

Knowing that the deprecated API HTTPS scheme works gives confidence in the input fields. Using the same API key, but now with the websocket (ws, wss, none) results in a different error now. The environment variables seem OK, but it is 100% the same API key that works in HTTPS scheme. I cloned the working HTTPS one. And double checked.

The ACME log:
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Error encountered while deploying.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Error deploying for domain: *.<REDACTED>.nl
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Verify API key.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Please check environment variables DEPLOY_TRUENAS_APIKEY, DEPLOY_TRUENAS_HOSTNAME and DEPLOY_TRUENAS_PROTOCOL.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] TrueNAS is not ready.
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Checking TrueNAS health...
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Environment variables: OK
2026-05-05T21:12:22acme.sh [Tue May 5 21:12:22 CEST 2026] Checking environment variables...

System log in ACME client:
2026-05-05T21:12:22opnsense AcmeClient: running acme.sh deploy hook failed (acme_truenas_ws)
2026-05-05T21:12:22opnsense AcmeClient: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --deploy --syslog 6 --log-level 1 --server 'letsencrypt' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/67e6acd371dce3.58753914' --certpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/cert.pem' --keypath '/var/etc/acme-client/keys/67e6acd371dce3.58753914/private.key' --capath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/chain.pem' --fullchainpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/fullchain.pem' --domain '*.<REDACTED>.nl' --ecc --deploy-hook truenas_ws --insecure'
2026-05-05T21:12:22opnsense AcmeClient: running automation (acme.sh): TrueNAS-export
2026-05-05T21:12:22opnsense AcmeClient: running automations for certificate: *.<REDACTED>.nl

Yesterday the ACME logs were different doing the same. Does this has something to do with setenv being done once (at the HTTPS scheme that worked) and that the system now has an API key but with older value..? I tested the old scheme first today to check my understanding before retrying the Websocket with new key. So, initialization thing?

AMCE logs yesterday:
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] Error encountered while deploying.
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] Error deploying for domain: *.<REDACTED>.nl
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] TrueNAS API key not found, please set the DEPLOY_TRUENAS_APIKEY environment variable.
2026-05-04T20:48:12acme.sh [Mon May 4 20:48:12 CEST 2026] Checking environment variables...

System logs yesterday:
2026-05-04T20:48:12opnsense AcmeClient: running acme.sh deploy hook failed (acme_truenas_ws)
2026-05-04T20:48:12opnsense AcmeClient: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --deploy --syslog 6 --log-level 1 --server 'letsencrypt' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/67e6acd371dce3.58753914' --certpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/cert.pem' --keypath '/var/etc/acme-client/keys/67e6acd371dce3.58753914/private.key' --capath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/chain.pem' --fullchainpath '/var/etc/acme-client/certs/67e6acd371dce3.58753914/fullchain.pem' --domain '*.<REDACTED>.nl' --ecc --deploy-hook truenas_ws --insecure'
2026-05-04T20:48:12opnsense AcmeClient: running automation (acme.sh): TrueNAS_cert
2026-05-04T20:48:12opnsense AcmeClient: running automations for certificate: *.<REDACTED>.nl

But if Frankie says it's not that, he is correct.

Copy all. I'll try and get all the logs on the forum asap.

I have tested this and was unable to reproduce this issue.
Please try again and provide the full ACME Log and all "AcmeClient" entries from the System Log.

I can do this when I have computer access again in a few days.

However, sopex mentions it will be fixed in the next version.... This indicates bug...

Maybe the setenv variable had been set in your case earlier and therefore it works? Is that possible?

Regardless, i'll dig into it in a few days time and help out isolating any issue. Thanks

Hi,

I have a working ACME client setup with a wildcard Let's Encrypt certificate for my domain. Also have a working nginx based reverse proxy to three services. Those services are running on a TrueNAS SCALE 25.10.3 (latest patch) system.

While all https access to the services is working fine through nginx with A+ trusted HTTPS (reverse proxy handles upstream stuff on the LAN to TrueNAS) the services on the TrueNAS system still use selfsigned certs from the TrueNAS box.

Now, while not essential (I trust my home lan ;-)) I am trying to get the whole certificate chain proper. Just a hobby thing.

Therefore I made an API key (root) on my TrueNAS and created the automation in the ACME client. Used the websocket (not deprecated one). Filled in all the fields, which are self explanatory. Reran the automations from the commands in OPNsense but the upload errors out.

[Mon May 4 18:02:46 CEST 2026] TrueNAS API key not found, please set the DEPLOY_TRUENAS_APIKEY environment variable.

I tried all automation modes (none, ws and wss) but error remains. The API key is really in the appropriate field. The plugin however does not seem to set the value from the field in the environment variable.

I am a little at hand (no ssh) from my phone currently so no CLI attempt possible.

Anybody recognize this? Seems a bug...