Messages

[ scratch that. I should not post out of frustration especially when I am unable to gather more info to help troubleshoot. ]

IPv6-PD is not commonly used and it is not actively monitored-at least by Tier 1 support since they told me their diagnostics all show green.

If that's the case for business accounts... then the fact that IPv6-PD works at all for my home connection is something of a miracle and I'm on my own.

Great.

I have no evidence of this, but I am guessing business and residential accounts all go thru the same support structure. We just get a different modem and our techs wear shirts and drive trucks that say Comcast Business. We also had AT&T's different broadband offerings going back to DSL in the 90s and we had similar experiences there as well. None of them had a way for technically savvy customers to help them troubleshoot. DSL Reports forums were a lifeline back then.

If you are affected by this, you'll want to get a ticket opened and request a firmware rollback.

I really want to emphasize this to anyone reading. IPv6-PD is not commonly used and it is not actively monitored-at least by Tier 1 support since they told me their diagnostics all show green. It takes everyone affected to call and open a ticket before someone notices. The call volume has to be enough to show up in their reports. Otherwise, our issue stays below their radar and they consider us "isolated issues".

Thanks for telling me about this thread, Franco. I spoke to someone in their corporate escalations group on Nov 10. Even he had to find a way to get it escalated into their engineering group. By Dec 1st, they rolled back my firmware at my request and I confirmed that fixed the problem (again). They then started rolling everyone back on Dec 5th and expected to complete that process by Dec 8th. He was going to update me if things change and I was going to reach out if the rollback caused issues. Thankfully, all went well.

Sadly, this is not the first time firmware updates affected my IPv6. My previous event triggered the modem's firewall and *block all incoming IPv6 connections* even though it is set to "disabled". Port forwarding, IPSec, client VPNs all went down. Similar to this time, I found someone who was able to relay it into engineering.

Btw, the one I am eagerly awaiting news on is the CheckPoint vs StrongSwan 6.0.3 CHILD_CREATE issue we had (#9382). The latest info I received today was their R&D discussed my case in their meeting and they will investigate my issue before making a decision. I set up a lab to gather logs and sent it all in along with Tobias' comments and links to the RFCs. I hope it was convincing enough.

OPNsense can also do GPS, but I know of nobody using that.

I went through an NTP+GPS phase and I had this GPS connected to an RS232 port running bare metal OPNsense. There is a tunable to pull PPS from DCD and I got its offset down to below 10ns. Sadly, I had to switch to USB when I upgraded and my offset is now regularly in the 0.1-0.5ms range.

OPNsense provides NTP throughout the house and I have 2 other units on the local network for accurate NTP sync.

Code Select Expand

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.20.0    .GPS.            0 l   10   16  377    0.000   -0.168   0.260
 0.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 1.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 2.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 3.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
+2603:3018:143b: .PPS.            1 u    9   16  377    0.563   +0.159   0.085
+192.168.1.124   192.168.1.10     2 s    8   16  377    0.262   +0.155   0.033
-23.150.40.242   204.9.54.119     2 u   37   64  377   37.326   +3.317   4.652
-2603:c020:0:836 132.163.97.4     2 u   15   64  377   68.738   +3.902   1.751
-158.51.99.19    204.9.54.119     2 u   27   64  377   33.253   +8.254   1.336
-2606:82c0:23::e 216.239.35.0     2 u   37   64  377   34.156   +4.076   2.105
-15.204.246.57   94.0.219.24      2 u   10   64  377   36.513   +3.360   1.836
+144.202.0.197   207.66.79.103    2 u   25   64  377   34.933   +3.891   1.411


[Reset ACME Client]

My remaining certificates renewed this morning. Under "Services > ACME Client > Log Files > System Log tab", do you see a non-zero value for "AcmeClient: AcmeClient: The shell command returned exit code 'n'"? Are you able to cat out the file at the end of that line? On my error post above, it is /var/etc/acme-client/accounts/6027ee9e097f39.62139316_prod/account.conf. Until I hit Reset ACME Client, that file did not exist. You can also try increasing the ACME logging level from "normal" to "debug" before the next renewal.

[Reset ACME Client]

Further searches through this forum produced the following links:

• https://forum.opnsense.org/index.php?topic=30249.msg147778#msg147778
• https://github.com/opnsense/plugins/issues/3154

The scenario made sense as I recently migrated to new hardware and imported config.xml. The recommendation is to click on Reset ACME Client. I was presented the following (emphasis mine) and I am confident this is the solution.

This will remove ALL certificates, private keys, CSRs from ACME Client and reset all certificate and account states. However, existing certificates will remain in OPNsense trust storage. The ACME Client will automatically regenerate everything on its next scheduled run. This is most useful when importing a config backup to a new firewall. Continue?

I notice I have the same problem on 25.7.2. All 3 of my certificates failed to renew but it works when I manually click on the button to "Issue or renew certificate". Acme-client logs show the error: 'host.domain.tld' is not an issued domain, skipping.

System log for the failure says:
AcmeClient: The shell command returned exit code '2': '/usr/local/sbin/acme.sh --renew --syslog 6 --log-level 1 --serv
er 'letsencrypt' --webroot /var/etc/acme-client/challenges --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/6027eeb80684e4.42843464' --certpath '/var/etc/acme-client/certs/6027eeb80684e4.4
2843464/cert.pem' --keypath '/var/etc/acme-client/keys/6027eeb80684e4.42843464/private.key' --capath '/var/etc/acme-client/certs/6027eeb80684e4.42843464/chain.pem' --fullchainpath '/var/etc/acme-client/certs/6027eeb806
84e4.42843464/fullchain.pem' --domain 'host.domain.tld' --days '60'   --keylength 'ec-384' --ecc --accountconf '/var/etc/acme-client/accounts/6027ee9e097f39.62139316_prod/account.conf''

System log for the successful says:
AcmeClient: The shell command returned exit code '0': '/usr/local/sbin/acme.sh --issue --syslog 6 --log-level 1 --server 'letsencrypt' --webroot /var/etc/acme-client/challenges --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/6027eeb80684e4.42843464' --certpath '/var/etc/acme-client/certs/6027eeb80684e4.42843464/cert.pem' --keypath '/var/etc/acme-client/keys/6027eeb80684e4.42843464/private.key' --capath '/var/etc/acme-client/certs/6027eeb80684e4.42843464/chain.pem' --fullchainpath '/var/etc/acme-client/certs/6027eeb80684e4.42843464/fullchain.pem' --domain 'host.domain.tld' --days '60' --force  --keylength 'ec-384' --accountconf '/var/etc/acme-client/accounts/6027ee9e097f39.62139316_prod/account.conf''


I see 3 differences between the shell commands. Perhaps one of them is the difference between a successful and failed renewal.

• --renew (failed) vs --force
• --force (succeeds)
• --ecc (failed)

On OPNsense and other BSD systems (including macOS) it is much simpler to use like this:

 % date -r 1752053171
Wed Jul  9 11:26:11 CEST 2025

As far as I know this does not work on Linux systems.

On Linux, it is this:

$ date -d @1752053171
Wed Jul  9 04:26:11 AM CDT 2025

I'm not going to run two DNS services just to be able to resolve internal host names. This whole deprecation of ISC has been a mess. ISC+Unbound is exceedingly simple and functional, Kea and dnsmasq are both half-baked.

The devs are caught in the middle with the ISC deprecation. Running EOL software is not an option in certain environments and Kea does not offer the same options. This gives users two paths with supported options depending on what their priority is. ISC is still there if EOL is fine. These additional choices bring extra support complexity so I think the devs would prefer not adding dnsmasq. Personally, I would prefer not running 2 DNS servers as well but hostname registration is important to me.

Still no support for registering DHCP leases from anything other than ISC DHCP?

Dnsmasq can handle hostname registration. Unbound is the primary resolver and forwards internal zone requests to Dnsmasq. This is covered in the documentation and walks you through the setup. I recommend someone create a sticky with a link to this doc since there are a lot of questions and discussions right now.

I am also having trouble with my captive portal under 25.1. I use "Enforce Local Group" to lock down access to a specific group, but the portal denies the logins; I've double-checked my credentials. What group privileges should I enable to allow access? I tried "All pages" as a test but it did not work.

As for the captive portal pop up, I ran tcpdump against my iOS connection. It got the HTTP 302 and connected to the portal with TLS1.2. I then see:

Code Select Expand

Alert (Level: Fatal, Description: Protocol Version)
This is the server response after Client Hello. It seems lighttpd no longer accepts TLS1.2 and requires TLS1.3 to connect.

Edit: Opened Github Issue 8300 for the TLS version.

I am having trouble with my captive portal. The portal requires a username and password, and I assigned a group under "Enforce Local Group" to restrict the users allowed. But this doesn't seem to work under 25.1. I get an error message saying "DENY user (x.x.x.x)" in portalauth/latest.log. Group privileges are set to "Nothing selected" after the upgrade. As a test, I tried setting privileges to "All pages" but authentication still fails.

Is there a specific privilege that allows captive portal logins?

Is there a common alias type whose data is missing? Are manually entered Host(s) and Port(s) aliases empty as well?

Logs for URL Table alias fetches are in Firewall > Log Files > General.

Finally reaching out for some help after following this thread and applying both patches Franco released the other day, and I am still struggling with IPSEC tunnels dropping. I am terminating between a Sonicwall 2650 and OPNSense, prior to 24.7.2 no issues, now having issues w/ P2 dropping. Below is the issue I think and I have validated that proposals match:

2024-08-28T10:25:58-05:00   Informational   charon   06[IKE] no acceptable proposal found   
2024-08-28T10:25:58-05:00   Informational   charon   06[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ   
2024-08-28T10:25:58-05:00   Informational   charon   06[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ   
2024-08-28T10:25:58-05:00   Informational   charon   06[ENC] parsed CREATE_CHILD_SA request 31 [ SA No TSi TSr ]

The Sonicwall does not have PFS enabled. This is confirmed by the missing MODP_2048 in received proposals. You should pick "default" for your ESP.