Messages

I found the problem - ::/0 was somehow added at the end of the "Rebind protection networks" option of Unbound/Advanced which can apparently happen randomly when changing other configuration settings of Unbound. After removing it Unbound started returning AAAA lookups correctly again.

I use Unbound as my DNS forwarder but I've been noticing the past few weeks a lot of failed IPv6 DNS lookups - I don't use IPv6 externally on my WAN, but as far as I can tell it's enabled on many of my internal devices, but I tend to stick with IPv4. Unbound is set to forward requests to Quad9 at 9.9.9.10 using TLS

When I try to test things against my Unbound I get this:

Code Select Expand

root@MOE:~# kdig @192.168.1.1 AAAA one.one.one.one
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 15362
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; one.one.one.one.            IN      AAAA

;; Received 44 B
;; Time 2026-05-14 10:17:04 CEST
;; From 192.168.1.1@53(UDP) in 14.6 ms


If I try directly against Quad9 I get:

Code Select Expand

root@MOE:~# kdig @9.9.9.10 +tls AAAA one.one.one.one
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 56075
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; one.one.one.one.            IN      AAAA

;; ANSWER SECTION:
one.one.one.one.        43200  IN      AAAA    2606:4700:4700::1111
one.one.one.one.        43200  IN      AAAA    2606:4700:4700::1001

;; Received 100 B
;; Time 2026-05-14 10:17:09 CEST
;; From 9.9.9.10@853(TLS) in 27.1 ms


I don't see any errors on the Unbound log for such queries, this I did on OPNsense itself:

Code Select Expand

drill AAAA one.one.one.one @127.0.0.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 63287
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; one.one.one.one.     IN      AAAA

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 114 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu May 14 09:56:57 2026
;; MSG SIZE  rcvd: 33

Code Select Expand

2026-05-14T09:56:57Informationalunbound[63620:1] reply: 127.0.0.1 one.one.one.one. AAAA IN NOERROR 0.113617 0 33
2026-05-14T09:56:57Informationalunbound[63620:1] info: response for one.one.one.one. AAAA IN
2026-05-14T09:56:57Informationalunbound[63620:1] info: response for one.one.one.one. AAAA IN
2026-05-14T09:56:57Informationalunbound[63620:1] info: resolving one.one.one.one. AAAA IN
2026-05-14T09:56:57Informationalunbound[63620:1] query: 127.0.0.1 one.one.one.one. AAAA IN
2026-05-14T09:48:17Informationalunbound[25115:0] reply: 127.0.0.1 one.one.one.one. AAAA IN NOERROR 0.035965 0 33
2026-05-14T09:48:17Informationalunbound[25115:0] info: response for one.one.one.one. AAAA IN
2026-05-14T09:48:17Informationalunbound[25115:0] info: response for one.one.one.one. AAAA IN
2026-05-14T09:48:17Informationalunbound[25115:0] info: resolving one.one.one.one. AAAA IN
2026-05-14T09:48:17Informationalunbound[25115:0] query: 127.0.0.1 one.one.one.one. AAAA IN


And my DNS TLS forwarding config is:

Code Select Expand

Domain:
 Server IP: 9.9.9.10
 Server Port: 853
 Forward first: Disabled
 Verify CN: dns10.quad9.net
 Description: No Malware blocking, no DNSSEC validation

Any idea what else I can check, especially commands to test on OPNsense itself as I cannot work out a way to check TLS lookups on the command line although I was able to see that traffic on port 853 was going out.

I just updated to 26.1.8_5 and it hasn't helped

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.