Upgradethread 23.1.11_1 to 23.7

[RamSense]

updated to 23.7 also. Had a little hickup with internet not working, probably due to adguard home, but after a another manual reboot with first disabling adguard home and back to only bind the system was working. Put adguard home back on and all is running like it should.

Only in the terminal I have an error building up in # with this:

    [fib_algo] inet.0 (radix4_lockless#2180) rebuild_fd_flm: table rebuild failed
    [fib_algo] inet.0 (radix4_lockless#2180) rebuild_fd_flm: sync rebuild failed
    [fib_algo] inet.0 setup_fd_instance: radix4_lockless algo instance setup failed

and failures=1,2,3......up to 52 now and still counting up..

others having this also?

[br41n]

Unbound does not start any longer, now using Mobile backup.

/usr/local/opnsense/mvc/app/models/OPNsense/Unbound/Unbound.php.50:in_array(): Argument#2($haystack) must be of type array, int given.

Hope this gets fixed soon. My firewall itself can't get Internet access any longer due to lack of DNS ...

Had the same issue.
The fix for me was here, had to manually update line 47:
https://github.com/opnsense/core/commit/c61ef7a2876880222e09831bdf90f6a137a4f67c

But I have another issue.
I have unbound on port 5335 and adguard on 53 and Primary DNS active.
On reboot wireguard is starting before adguard and is not able to connect to a server with hostname
and is blocking other services from starting (booting the rest of the services).
Only way right now to fix that is through ssh and manual restarting adguard fixes everything. (other services are able to start)

Otherwise the update went super easy and well.
Thank you OPNSense Team

[newsense]

Unbound does not start any longer, now using Mobile backup.

/usr/local/opnsense/mvc/app/models/OPNsense/Unbound/Unbound.php.50:in_array(): Argument#2($haystack) must be of type array, int given.

Hope this gets fixed soon. My firewall itself can't get Internet access any longer due to lack of DNS ...

Had the same issue.
The fix for me was here, had to manually update line 47:
https://github.com/opnsense/core/commit/c61ef7a2876880222e09831bdf90f6a137a4f67c

But I have another issue.
I have unbound on port 5335 and adguard on 53 and Primary DNS active.
On reboot wireguard is starting before adguard and is not able to connect to a server with hostname
and is blocking other services from starting (booting the rest of the services).
Only way right now to fix that is through ssh and manual restarting adguard fixes everything. (other services are able to start)

Otherwise the update went super easy and well.
Thank you OPNSense Team

I'm not 100% sure what the what the official position is regarding altering the core configuration of OPNsense.


I consider Unbound a core service - fingers crossed v18 gets released soon - and while I moved all FWs last October to AdguardHome, Unbound still runs on port 53 should it be needed, and or all LANs/VLANs there's a Port Forward rule that takes any DNS traffic outbound and redirects it to where AGH is running/listening - in my case I opted for 127.0.0.1:5353 _only_

This particular configuration word so well that even when there's been small accidents in the past everything worked well and no upgrades resulted in services/FWs being down, and should any future AGH update fail for some reason my FWs will have all other services up and I'll be able to remote in and take corrective actions.

[yeraycito]

updated to 23.7 also. Had a little hickup with internet not working, probably due to adguard home, but after a another manual reboot with first disabling adguard home and back to only bind the system was working. Put adguard home back on and all is running like it should.

Only in the terminal I have an error building up in # with this:

    [fib_algo] inet.0 (radix4_lockless#2180) rebuild_fd_flm: table rebuild failed
    [fib_algo] inet.0 (radix4_lockless#2180) rebuild_fd_flm: sync rebuild failed
    [fib_algo] inet.0 setup_fd_instance: radix4_lockless algo instance setup failed

and failures=1,2,3......up to 52 now and still counting up..

others having this also?

In my opinion Adguard is the culprit for not starting several services after an Opnsense restart, when starting Adguard the stopped services start by themselves. In my case I have Unbound disabled and Adguard not only doesn't start but blocks the start of Suricata, Cron and ddclient along with Wireguard.

https://forum.opnsense.org/index.php?topic=35057.0

[Patrick M. Hausen]

Services that depend on DNS when starting will not start if DNS is not ready. Start e.g. Unbound and AdGuard Home and direct only users to AGH and all service on the firewall to Unbound. BIND also works reliably.

There is no need for WireGuard to have a DNS ad blocker in place.

Also AGH might fail to start if the upstream DNS cannot be reached. So point it at a local Unbound or BIND instead of something external, if your Internet connection takes a while to come up.

[yeraycito]

Services that depend on DNS when starting will not start if DNS is not ready. Start e.g. Unbound and AdGuard Home and direct only users to AGH and all service on the firewall to Unbound. BIND also works reliably.

There is no need for WireGuard to have a DNS ad blocker in place.

Also AGH might fail to start if the upstream DNS cannot be reached. So point it at a local Unbound or BIND instead of something external, if your Internet connection takes a while to come up.

I agree with the excellent explanation, especially the first part but the solution you propose is not valid for me because I don't want to use Unbound and I want to use Adguard with DNS Quic. I have been using Adguard for a long time and what is happening now was not happening before, so something must be happening with the Adguard plugin.

[Patrick M. Hausen]

The AdGuard Home plugin is not part of the OPNsense distribution. So I suggest you take that issue to the plugin maintainer(s).

BTW: I do use AGH. In combination with BIND. No issues whatsoever.

[ValliereMagic]

I'm having an issue with firewall groups on 23.7:

• I noticed in the changelog that it was mentioned that the groups system was re-written using the MVC framework. Thinking this *may* be related to that in some way
• The odd part, is that I have a group containing a single interface [wan] containing only floating rules that IS working, while my other two are not.
• This appears to be an issue on the UI side only because firewall rules from the groups are applying correctly, and in the correct order

Behaviour Exhibited

• Interfaces are no longer grouping by firewall group under the interfaces menu in the UI, except for the WAN interface group
• The group interfaces are showing up correctly under the firewall menu, and have the correct rules from my config XML in them
• Within a group interface's individual firewall rules menu, previously the group rules were shown underneath the auto-generated rules. Now they are omitted entirely [yet are working correctly in the background] with the exception of the WAN interface group; hence, I have some interfaces that only inherit from groups that appear completely empty, with no indication that they inherit from an interface group.

Troubleshooting steps already taken

• I've tried creating a new group to see if it would show up, as well but it was omitted entirely from the firewall menu
• I've tried restoring from my configuration XML backups
• Multiple reboots

Next steps

• Considering reinstalling 23.7 fresh on my box, and restoring from config

Before I go down the road of reinstalling, and trying the config restore I wanted to reach out and see if anyone else was experiencing a similar issue first.

all the best,
Vall

Edit:

Hunch I saw looking at my pre-migration config, vs. my post-migration config:
Is it possible somewhere in the ui (like JavaScript somewhere that doesn't affect the workings of the backend) is still expecting space separated ifgroup members instead of comma separated ifgroup members?

This would explain why my single-member interface group shows up correctly (because it's the same in both representations)

i.e ifgroups version="1.0.0":
<members>opt4,opt1,lan</members>
23.1.11:
<members>opt4 opt1 lan</members>

ifgroup with single entry is still working because it has no separators, and would be valid in both i.e.:
ifgroups version="1.0.0":
<members>lan</members>
23.1.11:
<members>lan</members>

Just a hunch that was keeping me awake.

thanks again,
Vall

[GrantSquirt8415]

Completed the upgrade from 23.1.11 to 23.1.11_1 with no issues. The upgrade from 23.1.11_1 to 23.7 seemed to proceed with no issues, but after the update was complete internal machines had no internet access. I could no longer access the firewall with the FQDN but could access it directly via IP address. For some reason unbound was not started. Going into the configuration the check box to enable it was not checked and some of the other required settings were missing. Enabled unbound and restarted the service and only other minor issue was a complaint about a logging database missing (I had OPNSense create what it wanted). Has been running fine since.
Setup includes two wan interfaces and two lan interface with a firewall rule for gateway fail over.

[bobbysmithers]

This update kills all my WireGuard tunnels on startup.
I have to disable and re-enable my WireGuard gateways every time I reboot to get them working again.
Any ideas on a fix or is this a new bug?
Previous version 23.1.11 worked perfectly.

Edit:
So, I can get everything working again just by disabling the WireGuard plugin for a few seconds and re-enabling it.
Did the startup order just change and WireGuard starts too quickly now before it can make a connection?
Is there a way to delay WireGuard from starting by like 10-15 seconds? I think that may fix it.

[franco]

Edit:

Hunch I saw looking at my pre-migration config, vs. my post-migration config:
Is it possible somewhere in the ui (like JavaScript somewhere that doesn't affect the workings of the backend) is still expecting space separated ifgroup members instead of comma separated ifgroup members?

This would explain why my single-member interface group shows up correctly (because it's the same in both representations)

i.e ifgroups version="1.0.0":
<members>opt4,opt1,lan</members>
23.1.11:
<members>opt4 opt1 lan</members>

ifgroup with single entry is still working because it has no separators, and would be valid in both i.e.:
ifgroups version="1.0.0":
<members>lan</members>
23.1.11:
<members>lan</members>

Thanks for debugging. Here is a patch: https://github.com/opnsense/core/commit/b52bf63e9

# opnsense-patch b52bf63e9


Cheers,
Franco

[bsiege]

This time no luck at all...

No matter if started via gui or console (ssh/serial both) this update does not work for me.
After restart it runs still on 23.1.11_1 

Have a hard time to debug this. Cannot find any relevant log.

What i see there is some 23.7 package here, but not up to date.
pkg version | grep opns
opnsense-23.1.11_1                 =
opnsense-installer-23.1            =
opnsense-lang-22.7.3               =
opnsense-update-23.7               >
pam_opnsense-19.1.3                =

Yes, i can reinstall, no problem. But i like to know what colud be "special" on my system..

Intel(R) Celeron(R) J4125 CPU @ 2.00GHz (4 cores, 4 threads)
ZFS

[franco]

There is an upgrade log and it will tell you what custom package prevents you from upgrading...

Either System: Firmware: Status -> Run an Audit -> Upgrade

Or on the console:

# opnsense-update -G


Cheers,
Franco

[kbhsn4]

Thanks for debugging. Here is a patch: https://github.com/opnsense/core/commit/b52bf63e9

# opnsense-patch b52bf63e9

Plus this one: https://github.com/opnsense/core/commit/0e1aa4bcca6

[franco]

Yup

# opnsense-patch b52bf63e9 0e1aa4bcca6


Cheers,
Franco