Messages

newsense, Franco:

Any suggestions as to how to troubleshoot "IPv6 not working as expected"?

Thanks

newsense:

I tried both.  Changing the mirror to one much closer to me reproduced the same exact errors. I then SSH'd to the box and issued the opnsense-update -bkr 26.1.11 command.  Same basic error, as shown below:

root@OPNsense:/home/<redacted> # opnsense-update -bkr 26.1.11
Fetching base-26.1.11-amd64.txz: ...............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/48626/base-26.1.11-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found

Franco, I changed the system DNS queries from being forced down the VPN tunnels to using the WAN interface (Quad9 DNS over TLS).  Lookups tested from clients and Interfaces -> Diagnostics -> DNS Lookup appear to function fine.  Attempted updates again:

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.11_10 (amd64) at Sat Sep 19 12:31:30 EDT 2026
Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/232496 bytes
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 933 packages processed.
All repositories are up to date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.

After a LONG pause, with "Updates" tab showing rotating circle, I am presented with the option to install base 26.1.11 and kernel 26.1.11; current version of both packages is listed as 26.1.7, which "seems" incorrect, as I am running 26.1.11_10 already.  The changelog being truncated is also concerning.  So then I ran System -> Status -> Run an audit -> Health


***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.11_10 (amd64) at Sat Sep 19 12:50:25 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-isc-dhcp 1.0_6
os-nut 1.9_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.11_10 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***

OK, so the audit also indicates I'm running base and kernal 26.1.7 vice 26.1.11.  I go back to the "Updates" tab and click on the Update box to install base 26.1.11 and kernel 26.1.11. Note says "There are 2 updates available, total download size is 168.5MiB. This update requires a reboot." Result:

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.1.11_10 (amd64) at Sat Sep 19 13:04:33 EDT 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Flushing temporary package files... done
Starting web GUI...done.
Fetching base-26.1.11-amd64.txz: ...............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/5484/base-26.1.11-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found
***DONE***

I'm stuck. No option to upgrade to 26.7, and my 26.1 software appears to have a problem. As best I can tell, DNS is functioning as expected.  Franco, you mentioned IPv6 also.  Is there anything specific I can check or diagnostic to run to try to narrow the problem down?

Thank you for the explanation, franco; I can't imagine I would have figured that out on my own.

My OPNsense platform is a VPN client, with 2 tunnels.  I force most of my traffic out the tunnels, including not only client DNS queries but system DNS queries; the target is an ad/malware-blocking DNS server offered by the VPN provider.  When I have time to reconfigure, I'll change the system DNS queries back to a public server, exiting via the WAN interface rather than the VPN, and see if that clears the issues up.

Thanks again.

Unsophisticated user here.  Just realized I have a couple of issues I ned to get my head around.
Note the highlighted issues below.  Any advice from the more knowledgeable would be deeply appreciated.

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.1.11_10 (amd64) at Tue Jul 21 10:01:14 EDT 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Flushing temporary package files... done
Starting web GUI...done.
Fetching base-26.1.11-amd64.txz: ...............................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/93517/base-26.1.11-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found
***DONE***

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.11_10 (amd64) at Tue Jul 21 10:06:04 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.7 is incorrect, expected: 26.1.11
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-isc-dhcp 1.0_6
os-nut 1.9_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.11_10 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***

passeri:

It is, and I plan on implementing SSH shortly.  I'm just trying to get all recovery options clear in my mind, along with the consequences/side effects of each.  One might have to recover via the method I asked about if, e.g., there were issues with both web access and SSH access, unlikely though that might be. ;-)

So, to verify, not only did this procedure (1) reset the root password, (2) allow you to change the authentication method back to Local Database, but also (3) reenable the previously disabled root user account?  I have been wondering about #3.

I ran across Franco's 2018 explanation as to question 1 (https://forum.opnsense.org/index.php?topic=9690.0).  Console option 3 will not only allow you to reset the password, but also asks "Do you want to set it back to Local Database [y/n]".  Perfect.

Thanks for the response, viragomann.

I was testing forcing system DNS queries down a pair of Wireguard tunnels, and was hoping to be able to specify the VPN gateway group vice the two VPN gateways.  However, I tested the failover with the 2 gateways individually listed, and DNS failed over fine from one to the other.

I'm still mulling whether to use WAN or VPN gateways for DNS resolution; I may go back to just letting the routing table decide (so generally WAN).

Thanks for the help!

Newbie here, running 25.7.3_7.  I note that under System → Settings → General, one can specify any existing gateway for a DNS server.  However, one cannot specify a gateway group.  Is this omission by design?  Thanks.

Couple of newbie questions: (1) Assuming one has created additional admin users and disabled root, will the console password recovery process (option 3: reset root user password) still work?  In other words, will the console password recovery process not only allow one to reset the root user password but also reenable a disabled root user account?  (2) Where does one look to verify whether a particular installation used ZFS or UFS filesystem?  I could have sworn it used to be displayed on the Lobby Dashboard . . .

Thanks

I have now run into this issue as well.  I am a total OPNsense noob ... though I have a year of pfsense under my belt.  I followed the documentation very carefully to configure Unbound and Dnsmasq to work together.  I followed the example configuration steps in "DHCP4 with DNS Registration".  "DHCP register firewall rules" has been checked since the beginning. After I was done, I noted that the Dnsmasq service failed to start.  Logs pointed me to the issue.  I disabled the ISC DHCP4 service and manually restarted the Dnsmasq Service.  So far, so good.  Then I noticed no rules had been created with respect to DNS on any of my interfaces.  Based on this thread, I verified that the Dnsmasq General Tab listed all the interfaces (physical and VLAN) I had created (except WAN) in the "Interface" field, and under Advanced Mode the "Interface [no dhcp]" field says "Nothing selected". I did a System - Diagnostics - Packet Filter - Restart and when this changed nothing, I did a Power - Reboot.  Can anyone offer any suggestions for things to check?  Thanks.

POSTSCRIPT:  Never mind.  Noob GUI interface ignorance.  I didn't realize all the autogenerated rules are collapsed into their own folder.  The 3 "allow access to DHCP server" rules are on each interface.