Messages

I haven't updated to v26.1 yet, but can I lock the plug-in before to prevent it upgrading when I do get around to v26.1?

I woke up this morning to my firewall on 100% cpu after upgrading to 25.7.11_1 last night, and a reboot seemed to fix it but then I came across this thread and also the _2 hotfix which I have now applied. I have tried to configure it to limit to only my LAN interface, but anything other than All keeps the service running. In the logs I see:

Code Select Expand

2026-01-19T11:18:57Noticekernel<6>[18592] pid 77296 (hostwatch), jid 0, uid 0: exited on signal 6 (no core dump - bad address)
2026-01-19T11:18:56Noticeroot/usr/local/etc/rc.d/hostwatch: WARNING: failed to start hostwatch
For now I have just disabled it.

Hey, we are facing the same issue.

Did you manage to solve this for good?

Yes, adjusting the conf files under /var/etc/acme-client/cert-home for each certificate, and so far it's been fine

I think I found the problem. Every single conf file for the certificates has a value 

Code Select Expand

Le_OCSP_Staple='1'
even though the GUI clearly shows it's disabled

When I force a renewal it works, but when I check the file it's still enabled

If I change the value in the file to 0 and then renew it also works, but it remains 0

I've just had this happen once again to all my certificates this morning

Code Select Expand

2025-11-04T00:05:55acme.sh[Tue Nov 4 00:05:55 CET 2025] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
2025-11-04T00:05:55acme.sh[Tue Nov 4 00:05:55 CET 2025] Please add '--debug' or '--log' to see more information.
}
"status": 403
"detail": "Error finalizing order :: OCSP must-staple extension is no longer available: see https://letsencrypt.org/2024/12/05/ending-ocsp",
"type": "urn:ietf:params:acme:error:unauthorized",
2025-11-04T00:05:55acme.sh[Tue Nov 4 00:05:55 CET 2025] {
2025-11-04T00:05:55acme.sh[Tue Nov 4 00:05:55 CET 2025] Signing failed. Finalize code was not 200.
2025-11-04T00:05:54acme.sh[Tue Nov 4 00:05:54 CET 2025] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/1458980416/443694241571'
2025-11-04T00:05:54acme.sh[Tue Nov 4 00:05:54 CET 2025] Let's finalize the order.
2025-11-04T00:05:54acme.sh[Tue Nov 4 00:05:54 CET 2025] Verification finished, beginning signing.
2025-11-04T00:05:54acme.sh[Tue Nov 4 00:05:54 CET 2025] kodos.mydomain.com is already verified, skipping http-01.
2025-11-04T00:05:54acme.sh[Tue Nov 4 00:05:54 CET 2025] Getting webroot for domain='kodos.mydomain.com'
2025-11-04T00:05:52acme.sh[Tue Nov 4 00:05:52 CET 2025] Single domain='kodos.mydomain.com'
2025-11-04T00:05:52acme.sh[Tue Nov 4 00:05:52 CET 2025] Using CA: https://acme-v02.api.letsencrypt.org/directory
2025-11-04T00:05:52acme.sh[Tue Nov 4 00:05:52 CET 2025] Renewing using Le_API=https://acme-v02.api.letsencrypt.org/directory
2025-11-04T00:05:52acme.sh[Tue Nov 4 00:05:52 CET 2025] Renewing: 'kodos.mydomain.com'
I already went through every single certificate disabling/enabling OCSP yet once again it still thinks it's enabled when it tries to renew them.

Is it possible that the config file still contains bad values, in which case where are these stored so I can check them out.

As they are all used by HAProxy as I can bet I can't simply recreate each one without breaking HAProxy.

Ticket sounds good, even just to dig into the specifics.


Cheers,
Franco

Done https://github.com/opnsense/core/issues/9290

Checked again this morning and it eventually worked

Code Select Expand

Last updated 2025-10-13T22:15:01.504926
Total number of ranges 4550698

So for me, the lack of an "update now" feature hampers any simple diagnosis - perhaps something for the feature list?

I tried using curl from the OPNsense shell but I couldn't figure out how to get it to follow the redirect as I got that as the result - it did also needed quotes around the URL to take care of the ? character before the token:

Code Select Expand

Found. Redirecting to https://dl.ipinfo.io/artifacts/v1/ipinfo_lite.csv.gz?gener<redacted>

But doing the same on my Fedora server, but using wget, the file comes down correctly.

Nope, they are still the same as the last run against the old MaxMind URL

I've tried making a change to a rule on my WAN connection and that didn't cause an update, and checking some log files doesn't show anything but I'm not sure where to be looking.

Last updated 2025-10-10T10:06:14   
Total number of ranges 1298663

I updated to 25.7.5 at the weekend and today wanted to try out IPInfo. I followed the directions from the release notes, I signed up and replaced the MaxMind URL with the new one from my account but so far I see no change or any error. How can I check the status and maybe force an update? I did check the new URL manually through my browser and the file does download.

I think for me it's been a combination of things, and the WireGuard service just not letting traffic through was one perhaps caused by too many reconnect attempts. The final fix for me was a setting for the APN on my new provider, they were still sending out as default a profile with proxy enabled, once I cleared those WireGuard and some other strange issues suddenly cleared up, as well as getting better 4G/5G performance.

I've had this issue with nearly all my certificates for quite some time and found that if I re-enable OCSP, save, disable OCSP, save, the next time round it was ok.

I believe I've resolved it for myself and so far it's only happened once which I think was just a bad connection while I was travelling home on the tram.

The Android WireGuard app was missing the permission to Run in Background:Unrestricted Battery it was on the default Optimised. Once I enabled this the connection became reliable again - I can only guess Android would over time pause the app in some way. Every other app after transferring across phones would prompt me the first time I ran them, as it seems this permission doesn't transfer at least not for me, so why WireGuard I don't know.

Unfortunately this was only part of it, I think it was making the issue worse as randomly I still have the same problem with the connection blocking all traffic to the Internet and my DNS. Like before only restarting WireGuard or disconnecting then waiting a few hours gets it working again. For now I have added a cron job to restart WireGuard each midnight, and I have noted the command so I can use SSH manually restart it if I need it urgently.

I believe I've resolved it for myself and so far it's only happened once which I think was just a bad connection while I was travelling home on the tram.

The Android WireGuard app was missing the permission to Run in Background:Unrestricted Battery it was on the default Optimised. Once I enabled this the connection became reliable again - I can only guess Android would over time pause the app in some way. Every other app after transferring across phones would prompt me the first time I ran them, as it seems this permission doesn't transfer at least not for me, so why WireGuard I don't know.

@Taomin: Probably, either your IP sometimes changes

Nope, my firewall has a proper fixed IP, business account, as does my company office WiFi - I'm using the guest account which has no restrictions, just cannot access on the corporate LAN.

you have not enabled the cron job to detect a stale connection and restart Wireguard automatically (on both sides of the connection!)

No, I see the connection from my phone on the firewall changing state connected/stale/disconnected, and it doesn't matter how often I manually disconnect/reconnect on the phone. As for the cronjob, I have no clue about that as it's never been anything I needed to configure or even knew I needed.

your new provider has DS-Lite with CG-NAT and you cannot be reached via IPv4 any more.

It's happening on WiFi with a fixed IP

Only manually restarting Wireguard on the firewall do things start working again, and then only for some random amount of time at which point the traffic going external comes to a halt and from the looks of things so does the firewall Winguard logging. On the phone Wireguard is oblivious to the issue because the gateway IP and everything else internal still responds.

It's very bizzarre.