Messages

Thank you, Franco.  After applying that opnsense-patch I was able to import my ACME certificate into the Trust store once again.  It looks like it has solved my problem.

Cheers,

Paul.

Those two internal CAs were created quite a while ago (2018)---long enough ago that I don't remember whether they were created in OPNsense or created externally and imported into OPNsense.  It sounds from what you are saying that the latter might have happened, though it looks like the list of key and digest types is shorter now than I remember in the dialogues for creating certificates.

Is my hypothesis that this exception is preventing the import of the ACME certificate into the Trust store plausible?  From the stack trace, it looks like it is being provoked by "OPNsense\AcmeClient\LeCertificate->import(true)".

If so, it looks like the ACME plugin won't work for me so long as these non-validating CAs remain in the Trust store?  (Or, until they can be validated.)

Cheers,

Paul.

I seem to be having problems with 7680-bit RSA certificates now, so I am wondering if that length of key is still supported.

I noticed recently that my ACME certificate was no longer being renewed---at least in the Trust store.  The ACME logs would show a successful renewal via LetsEncrypt, but it would not update the certificate in the Trust store that eventually expired (July 11, 2026, shortly after which this came to my attention).

I was running 26.1.11 when this came to my notice, so today I upgraded to 26.7.1_1 in the hope this might "fix" whatever problems I was having with ACME and the Trust store.  It didn't.

I removed the ACME plugin; reset its configuration; deleted related certificates from the Trust store; and even deleted ACME files and directories from the file system before reinstalling the ACME plugin and setting up a new ACME config again.  This still didn't work, but the ACME part seemed to work (like before) inasmuch as it would obtain and download a certificate---just not import it into the Trust store.

I've noticed a new message in System -> Firmware -> Reporter since trying to get a new ACME certificate today.  Here are the PHP Errors:

Code Select Expand

[23-Jul-2026 18:09:38 Etc/UTC] PHP Fatal error:  Uncaught OPNsense\Base\ValidationException: [OPNsense\Trust\Ca:ca.fe3168a9-3e2e-49c3-a581-be1edfef2952.key_type] Option [] not in list.{7680}
[OPNsense\Trust\Ca:ca.ec78b5a8-75a8-4758-988a-87a22d4a9fc3.key_type] Option [] not in list.{7680}
 in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:822
Stack trace:
#0 /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php(193): OPNsense\Base\BaseModel->serializeToConfig()
#1 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(175): OPNsense\AcmeClient\LeCertificate->import(true)
#2 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(198): main()
#3 {main}
  thrown in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php on line 822
[23-Jul-2026 19:21:25 Etc/UTC] PHP Fatal error:  Uncaught OPNsense\Base\ValidationException: [OPNsense\Trust\Ca:ca.fe3168a9-3e2e-49c3-a581-be1edfef2952.key_type] Option [] not in list.{7680}
[OPNsense\Trust\Ca:ca.ec78b5a8-75a8-4758-988a-87a22d4a9fc3.key_type] Option [] not in list.{7680}
 in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:822
Stack trace:
#0 /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php(193): OPNsense\Base\BaseModel->serializeToConfig()
#1 /usr/local/opnsense/mvc/app/library/OPNsense/AcmeClient/LeCertificate.php(381): OPNsense\AcmeClient\LeCertificate->import(true)
#2 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(164): OPNsense\AcmeClient\LeCertificate->issue()
#3 /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php(198): main()
#4 {main}
  thrown in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php on line 822
The "Option [] not in list.{7680}" made me wonder whether it was referring to a RSA-7680 certificate.  My OPNsense installation is rather old, and I do have two internal certificate authorities in the Trust -> Authorities section, created in 2018, that are RSA-7680, at least according to the certificate info ("Public-Key: (7680 bit)").  (The ACME certificate I am obtaining has an ec-384 key length.)

Is that type of 7680-bit certificate supported any more?  When I looked at the key types when creating a new CA, 7680-bit is not listed as an option (it goes RSA-4096 and then RSA-8192).

I'm wondering whether this exception being thrown is what is causing the import into the Trust store to fail.

Cheers,

Paul.

Just had another OPNSense crash, just over a day from the last, right in the middle of watching a film with the family. The wife acceptance factor has reduced even further. OPNSense recovered and rebooted itself, though it took a while.

The RAM and SSD has been re-seated again, just in case. Memtest64 shows no issues.

I use LibreNMS to monitor my house equipment, and OPNSense has lots of free memory, disk space and wasn't very warm at the time of the crash. The OPNSense was near(ish) to a WiFi AP, but I moved this a few days ago in case EMI was an issue, but this hasn't helped. OPNSense seemed to be fine until I upgraded to 24.7.11, though this could be a coincidence. I've just run a "opnsense-revert -r 24.7.10 opnsense" with a reboot to see if this helps. I'm not sure if I need to run more commands to fully revert to 24.7.10. Any suggestions would be appreciated, or the number of a good divorce lawyer ;-)

I am also using OPNsense on a Protectli system (though I'm not using the exact same hardware as you; I'm using a Protectli Vault FW6A), and I also experienced random crash/reboots like you describe.  In my case, I updated the kernel via "opnsense-update -fk" to get a newer, fixed one.  That stopped the random crash/reboot behaviour for me.

I've recently updated to OPNsense 24.7.12-amd64, and I hope the behaviour remains fixed.

I post this hopefully to let you know this is probably not a hardware problem for you.

If you reapply Unbound it should be ok again? If yes it's a race condition because these constructs are fragile, but people keep asking for them. I think we discussed exactly this when including these or at least a few times now on similar subjects.

Thank you for the response.  Restarting the Unbound service has resulted in correctly-expanded IPv6 addresses.  Good to know for next time, if this happens again.

In my IPv6 setup I have IPv6 on WAN configured as DHCPv6 and all the local interfaces configured as "Track Interface". I have several ISC DHCPv6 static mappings configured for these "Track Interface" interfaces, using the "::1:2:3:4" suffix notation accordingly.

Since upgrading to 24.7.10 I've noticed that DHCPv6 static mapping hostnames are not resolved correctly by Unbound. Instead of prepending the DHCPv6-PD prefix to the suffix, it simply returns the suffix as-is. Looking at /var/unbound/host_entries.conf I see both local-data: and local-data-ptr: using just the suffix and not the full prefix+suffix one.

When I view the DHCPv6 static mappings in "Services: ISC DHCPv6: Leases" the correct, full IPv6 addresses are displayed.

Is this a regression in 24.7.10?

Since about release 23.1.2 I have been getting complaints from the Monit service about the RootFs service not working.  The e-mail is as follows:

Code Select Expand

Does not exist Service RootFs

Date:        Wed, 29 Mar 2023 17:07:23
Action:      restart
Host:        my.opnsense.host
Description: unable to read filesystem '/' state

Your faithful employee,
Monit


This still doesn't work as of the recent 23.1.5 update.

I am running OPNsense 23.1.5 on a ZFS-based install.  The install was bootstrapped from a FreeBSD install via opnsense-bootstrap.  It does have a ZFS file system mounted on /, so I'm not sure how to interpret the "unable to read filesystem '/' state" message.

Is anyone else experiencing this?  If so, is there a fix?  For now, I have disabled the service check so I don't get spammed with Monit e-mails about this service failing.  I would like to have the check working, though.

That could be it, but 23.1.5 would address that. Previously we recommended removing these tunables or moving them to /boot/loader.conf.local where they are not being triggered after bootup.

I checked the LAG configuration in my switch and note that everything checks out on both ends.  All the ports are set to Long timeout on the switch and I have Fast timeout unchecked.  Also, the default for Administrative Flow Control is Disable in the switch, which actually matches the tunable setting of dev.em.X.fc being 0 for the LAGG members on the OPNsense side.  I've changed the switch to Auto Negotiation and removed the tunables and will see if that helps matters when I do a test reboot of OPNsense later today.

Unless something else changed between 22.7.x and 23.1.x, I can't think what might have caused the OPNsense LAGG to fail to come up after a reboot.  None of the workarounds mentioned in the thread work for me.  The only thing seems to be rebooting my managed switch.

Just updated to 23.1.5.   LAG stays up after reboot.

See the information from reddit. 

https://www.reddit.com/r/opnsense/comments/1255xr8/2314_lagg_wont_come_up_after_reboot/

The Reddit link is very useful, thanks.

In my case, updating to 23.1.5 today did not fix the problem of the LAGG coming up: I still had to reboot my switch.  But, one of the Reddit replies says, "It seems to be a driver issue and custom eee/fc tunables set for your NIC," and I have dev.em.0.fc set to 0 for my NICs.  Maybe that is the cause of the problem?  I will test and report back.

BTW, this is still happening for me with the latest 23.1.3 update.  Rebooting my managed switch is the easiest way for the LAGG to be established at the OPNsense end, otherwise the LAGG does not come up properly at the OPNsense end.  :(

I have a 3-port LACP LAGG configured on my OPNsense system that is connected to a Cisco SG350 managed switch.  This has worked fine in previous versions of OPNsense going back years but since upgrading to 23.1 it gives problems.  Specifically, it has trouble becoming active (configured) after boot.  The individual laggports will change in status, with the flags moving through various states such as <>, <COLLECTING>, <ACTIVE, COLLECTING>, and even with some (but not all) in the desired <ACTIVE, COLLECTING, DISTRIBUTING> state.

This is what it looks like when it is properly configured:

Code Select Expand

$ ifconfig lagg0
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4812098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
ether 00:eb:ca:c0:05:c5
laggproto lacp lagghash l2,l3,l4
laggport: em1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: em2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: em3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
groups: lagg
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


It seems that even after 10 minutes or so that the LAGG is still cycling through various states with the member laggports and the interfaces built on this LAGG going UP and DOWN accordingly as it tries to configure.  The easiest way to fix it is to restart the Cisco switch.  ???

Has the way LAGG interfaces are configured changed in 23.1?  I see these two entries in the Changelog for 23.1:

• interfaces: register LAGG, PPP, VLAN and wireless devices as plugins
• src: assorted FreeBSD 13 stable fixes for e.g. bpf, bridge, bsdinstall ifconfig, iflib, ipfw, ipsec, lagg, netmap, pf, route and vlan components

I don't understand the import of either of those statements.  This setup worked flawlessly up to 22.7.11 and so whatever the problem is now appears to have crept in with 23.1.

Any hints or suggestions on how to get the LAGG to activate reliably are most appreciated.

I don't know whether it's a "best practice" or not but in our setup we use explicit Unbound domain overrides to do forward and reverse lookups for IPv4 private addresses not handled explicitly by the local Unbound.

We have two sites joined via a site-to-site IPSec VPN.  Each site has local (non-overlapping) IPv4 subnets and a local domain name for the addresses its Unbound manages.  In the Domain Overrides for each site, there is an N.N.N.in-addr.arpa override that sends the queries to the other site's Unbound for PTR (reverse) lookups, as well as a site.local.domain. entry that forwards queries for forward lookups.  It's done vice-versa at the other site.

I guess you could use a similar approach to forward all the local IPv4 ranges you're interested in to the outer network's DNS servers.

Does this do the job? https://github.com/opnsense/plugins/commit/16cbe99ebf

# opnsense-patch -c plugins 16cbe99ebf


Cheers,
Franco

This patch fixes the problem for me and allows NUT to start up.

Thank you.  I added the setting to /etc/periodic.conf.local.  I just updated to 22.7.8 and the file persisted across that update.

The official OPNsense documentation about tunables (https://docs.opnsense.org/manual/settingsmenu.html) says they are for loader.conf and sysctl.conf tunables. I have a ZFS setup on which I would like to enable a periodic scrub. FreeBSD has a built-in /etc/periodic/daily/800.scrub-zfs task that is disabled by default. I'd like to enable this via the daily_scrub_zfs_enable setting.

Assuming this can't be added as a tunable to the "System: Settings: Tunables" section, the normal way in FreeBSD would be to add it to /etc/periodic.conf or /etc/periodic.conf.local. Will the latter persist across updates?

(Are there any plans to add periodic settings to "System: Settings: Tunables"?)