Updating backup instance

[GreenMatter]

So, I have 2 instances of Opnsense in 2 VMs (PVE), configured in HA CARP mode. I have only one public IP, therefore I use Edgerouter X as "dumb router" with switch interface (DMZ) as WAN gateway for both Opnsense instances. Failover / maintenance mode works fine.
But it seems like backup instance (and same applies to master node when acts as backup) has an issue with WAN routing (LAN is ok). When I try to upgrade it, I get:

Code Select Expand

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.9 (amd64) at Tue Jun  9 13:49:57 CEST 2026
Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz.sig appears to be truncated: 0/1332 bytes
done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: ....... done
Processing entries: .......... done
OPNsense repository update completed. 927 packages processed.
All repositories are up to date.
Checking for upgrades (107 candidates): .......... done
Processing candidates (107 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
It takes quite long time to get it displayed plus even longer to be presented with:

You cannot view this attachment.

When system was on 26.1.8 there were timeouts too when checking repository for update info but I was able to download upgrade files. Now, download attempt ends up with timeout.
I've tried to set a routing for firewall itself (This firewall) to use physical interface for WAN connections - it didn't help.

How to troubleshoot it further or fix it? Or maybe I have wrong versions of kernel running in opnsense?

[viragomann]

I have only one public IP, therefore I use Edgerouter X as "dumb router" with switch interface (DMZ) as WAN gateway for both Opnsense instances.

So both nodes have configured an IP with the correct mask in the switch DMZ subnet?

Also ensure, that you have an outbound or source NAT rule for the source subnet 127.0.0.0/8, which uses the WAN IP as translation target on both.

[franco]

> fetch: /usr/local/opnsense/changelog/changelog.txz.sig appears to be truncated: 0/1332 bytes

Usually a sign of DNS timeouts.

[GreenMatter]

So both nodes have configured an IP with the correct mask in the switch DMZ subnet?

Also ensure, that you have an outbound or source NAT rule for the source subnet 127.0.0.0/8, which uses the WAN IP as translation target on both.

Yes, both nodes WAN match the mask set in DMZ switch interface.
Could you provide more detailed info about setting up inbound/outbound rules for FW itself? I tried with "This firewall" and didn't work...

[GreenMatter]

> fetch: /usr/local/opnsense/changelog/changelog.txz.sig appears to be truncated: 0/1332 bytes

Usually a sign of DNS timeouts.

This tip got me somewhere. I use local DNS (adguard with unbound as upstream) which is run separately from opnsense. On backup node Unbound doesn't work, initially I thought it was because of not available interfaces (ipv6 tunnel) unbound is binded to. But after deselecting them still doesn't work issuing error:

Code Select Expand

Unable to open pipe. This is likely because Unbound isn't running.
In cli:

Code Select Expand

root@OPNsense-bkp:~ # dig opnsense.org
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 172.16.1.4#53: timed out
;; communications error to 2001:xxxxxxxxx::4#53: timed out 
; <<>> DiG 9.20.22 <<>> opnsense.org
;; global options: +cmd
;; no servers could be reached
Despite of:

Code Select Expand

root@OPNsense-bkp:~ # ping 172.16.1.4
PING 172.16.1.4 (172.16.1.4): 56 data bytes
64 bytes from 172.16.1.4: icmp_seq=0 ttl=64 time=0.227 ms
64 bytes from 172.16.1.4: icmp_seq=1 ttl=64 time=0.105 ms
--- 172.16.1.4 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.105/0.166/0.227/0.061 ms
root@OPNsense-bkp:~ # nc -vzu 172.16.1.4 53
Connection to 172.16.1.4 53 port [udp/domain] succeeded!
After enabling

Do not use the local DNS service as a nameserver for this system

cli started working fine:

Code Select Expand

root@OPNsense-bkp:~ # dig opnsense.org 
; <<>> DiG 9.20.22 <<>> opnsense.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40326
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;opnsense.org.   IN A 
;; ANSWER SECTION: opnsense.org.  3 IN A 89.149.225.137 
;; Query time: 0 msec
;; SERVER: 172.16.1.4#53(172.16.1.4) (UDP)
;; WHEN: Thu Jun 11 09:57:59 CEST 2026
;; MSG SIZE  rcvd: 57
But update check still fails:

Code Select Expand

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.9 (amd64) at Thu Jun 11 10:00:41 CEST 2026
Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/217364 bytes
done
Updating OPNsense repository catalogue...
Waiting for another process to update repository OPNsense
All repositories are up to date.
Checking for upgrades (107 candidates): .......... done
Processing candidates (107 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***
So, I'm a bit lost....

EDIT:
It seems like that on top of not working unbound, the main culprit was not workable ipv6 interface (tunnel broker). After removing ipv6 entry of local DNS server (System - Settings - General) and enabling preference to use ipv4, finally system was able to fetch changelog. 
Ultimate verification will be during next upgrade :-)