"Recent posts
#31
German - Deutsch / Re: Absoluter Anfänger hat Ver...
Last post by cola247 - June 26, 2026, 02:39:08 PM4
#32
German - Deutsch / Re: Absoluter Anfänger hat Ver...
Last post by cola247 - June 26, 2026, 02:38:50 PM3
#33
German - Deutsch / Re: Absoluter Anfänger hat Ver...
Last post by cola247 - June 26, 2026, 02:38:01 PM2
#34
German - Deutsch / Re: Absoluter Anfänger hat Ver...
Last post by cola247 - June 26, 2026, 02:37:10 PMDoT funktioniert auch nicht. Echt frustrierend so langsam. Weißheitszähne ziehen lassen und Kinder nebenbei, ich komme nur selten dazu und dann frisst es mir die Zeit auf und ich fange immer wieder von vorne an. Absolutes Hirnmus.
#35
Tutorials and FAQs / Re: What to do and what to avo...
Last post by sopex - June 26, 2026, 02:02:14 PMGreat guide, as always!
#36
26.1, 26,4 Series / Re: Import rules [new] dialog ...
Last post by dseven - June 26, 2026, 01:46:40 PMDue to a recent change, the Rules [new] interface shows all rules that are in effect, not just those that are configured there. This was (IIUC) done so that automatically generated rules are shown, but unfortunately it also draws in rules that came from the legacy interface. There's a thread about it in here somewhere, but the forum search interface is exceeding my patience threshold :/
Silly question - you did check that your CSV file actually has content, right? ;)
Silly question - you did check that your CSV file actually has content, right? ;)
#37
26.1, 26,4 Series / Re: 26.1.7_2: issue with ACME ...
Last post by Rene78 - June 26, 2026, 01:08:04 PMI 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.
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.
Quote from: fragrance744 on June 23, 2026, 07:34:55 AMmidclt, https://github.com/truenas/api_client, is required for using TrueNAS websocket API.
The script may work after installing it.
Quote from: Creat on June 26, 2026, 10:42:47 AMAlso, 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.
Quote from: Patrick M. Hausen on June 23, 2026, 08:56:28 AMI'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.
#38
26.1, 26,4 Series / Re: noob here, TLS unbound iss...
Last post by matthewacbroad - June 26, 2026, 01:06:45 PMTopology
Internet
│
Rogers XB6 (Technicolor CGM4140COM)
DMZ → OPNsense WAN (10.0.0.247 via DHCP)
│
OPNsense
│
LAN
│
Single Linux laptop
The Rogers gateway is configured to place my OPNsense WAN IP (10.0.0.247) in the DMZ with reserved IP.
Symptoms
DNS resolution works.
TCP connection establishes successfully.
curl https://wikipedia.org hangs immediately after sending the TLS ClientHello.
openssl s_client also connects but never receives a ServerHello.
The same behavior occurs with multiple sites.
Example:
curl -4 -v https://wikipedia.org
* Host wikipedia.org:443 was resolved.
* Trying 198.35.26.224:443...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
It never progresses beyond that point.
openssl s_client shows:
Connecting to 198.35.26.224
CONNECTED(00000003)
and then waits indefinitely.
Things I've already checked
MTU path tested with ping -M do and large packets succeed.
Disabled IDS/IPS completely.
Disabled hardware offloading.
Cleared firewall states.
WAN MTU override issue was corrected (I had accidentally enabled "Override MTU" on the DHCP client previously).
DNS works correctly.
Packet capture
Packet captures on both the WAN and LAN interfaces while reproducing the problem.
The interesting observation was:
The WAN interface showed the TLS connection attempt.
The LAN interface did not show the expected traffic for that same connection.
I'm not sure whether this indicates I captured on the wrong interface, whether hardware/driver behavior is affecting the capture, or whether it suggests bad configuration
Internet
│
Rogers XB6 (Technicolor CGM4140COM)
DMZ → OPNsense WAN (10.0.0.247 via DHCP)
│
OPNsense
│
LAN
│
Single Linux laptop
The Rogers gateway is configured to place my OPNsense WAN IP (10.0.0.247) in the DMZ with reserved IP.
Symptoms
DNS resolution works.
TCP connection establishes successfully.
curl https://wikipedia.org hangs immediately after sending the TLS ClientHello.
openssl s_client also connects but never receives a ServerHello.
The same behavior occurs with multiple sites.
Example:
curl -4 -v https://wikipedia.org
* Host wikipedia.org:443 was resolved.
* Trying 198.35.26.224:443...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
It never progresses beyond that point.
openssl s_client shows:
Connecting to 198.35.26.224
CONNECTED(00000003)
and then waits indefinitely.
Things I've already checked
MTU path tested with ping -M do and large packets succeed.
Disabled IDS/IPS completely.
Disabled hardware offloading.
Cleared firewall states.
WAN MTU override issue was corrected (I had accidentally enabled "Override MTU" on the DHCP client previously).
DNS works correctly.
Packet capture
Packet captures on both the WAN and LAN interfaces while reproducing the problem.
The interesting observation was:
The WAN interface showed the TLS connection attempt.
The LAN interface did not show the expected traffic for that same connection.
I'm not sure whether this indicates I captured on the wrong interface, whether hardware/driver behavior is affecting the capture, or whether it suggests bad configuration
#39
Tutorials and FAQs / Re: What to do and what to avo...
Last post by Patrick M. Hausen - June 26, 2026, 12:28:46 PMI'm fine with 825 days and warnings from Uptime Kuma. Of course automation will take care of all the public ones.
I'm planning to get some beer and popcorn ready when our enterprise customers' IT departments finally notice the 47 day change. 😬 I don't understand why so many insist to send us their "official" certs for their web sites instead of switching on ACME which we include free of charge in our hosting platform in the form of Dehydrated.
I'm planning to get some beer and popcorn ready when our enterprise customers' IT departments finally notice the 47 day change. 😬 I don't understand why so many insist to send us their "official" certs for their web sites instead of switching on ACME which we include free of charge in our hosting platform in the form of Dehydrated.
#40
Tutorials and FAQs / Re: What to do and what to avo...
Last post by meyergru - June 26, 2026, 12:22:00 PMQuote from: newsense on June 26, 2026, 11:09:21 AMActually I think @meyergru forgot we're already down to 199 days for public certificates and come next March the value will be 100 days, and 45 days in another year.
What I wanted to stress is the fact that you cannot use your own long-lived certificates unless you use a trick that OpnSense has not got under its sleeve (maybe that would be a good feature request): namely, you cannot set the start date of an issued certificate to "-startdate 20190630120000Z", which I always do with my own CA. This is because "old" certificates can last arbitrarily long. I tend to issue them for at least 10 years, which is way longer than 825, 397, 199, 100 or even 47 days - and 10 years definitely does not work when the "Not Before" date is not manipulated. I changed my CA script to use that "Not Before" date and never looked back because that eliminates the need to ever think about this again ("i.e. "have your cake and eat it").
On the other hand, it simply does not matter how long ACME certificates can last, just because OpnSense can (and will) also reissue them at the respective appropriate intervals, even when the duration changes in the future.
I updated the guide to make this even more obvious.
