Hello,
after upgrading OPNsense Business to 26.4 we are seeing OPNcentral sync failures on some firewalls during NAT synchronization.
Error:
TypeError: Cannot access offset of type string on string in /usr/local/opnsense/mvc/app/controllers/Deciso/OPNcentral/Api/Sync/BaseSection.php:162
Stack trace:
Deciso\OPNcentral\Api\Sync\BaseSection->array_iterator()
Deciso\OPNcentral\Api\Sync\Nat->extend()
Deciso\OPNcentral\Api\SyncController->reconfigureAction()
Observations:
only happens after upgrade to 26.4
issue seems related to NAT / Destination NAT migration
affected systems use multiple Destination NAT redirect rules
disabling NAT sync avoids the issue
not all firewalls are affected
It looks like one NAT-related config structure is returned as string instead of array and crashes array_iterator().
Has anybody seen similar behavior after migrating to 26.4?
Regards
Christian
Hi Christian,
Haven't heard about this from someone else so far.
Would you mind sharing with me the legacy NAT rules configuratio so I can try to reproduce? At least I'm assuming it's the legacy configuration, because quirks there are more common.
# pluginctl -g nat
You can also share this via PM or mail to franco AT opnsense DOT org
Thanks,
Franco
Hello Franco,
pluginctl -n nat returns no output on my system.
At first I thought I may have missed a migration step because the firewall rules in 26.4 had to be manually converted to the new MVC system. However, from what I have been able to verify so far, NAT still appears to be largely legacy-based at the moment.
Therefore I assume my system is still using the classic NAT configuration from config.xml.
Would you prefer only the NAT section or a full config.xml for reproduction?
And on which firewall does the problem occur — source or destination?
Thanks,
Christian
Sorry I meant to write -g:
# pluginctl -g nat
Cheers,
Franco
I sent the two PMs.
Thank you, still working on it.
Cheers,
Franco
Can you try this test package? Best to install on all systems:
# opnsense-revert -z os-OPNBEcore
Cheers,
Franco
Hi Franco,
thanks for the update.
The issue is resolved with this fix and nat synchronization is working again.
I have now deployed it to the affected firewalls and it works on all of them.
Since I first installed it only on one of the target firewalls and then tested the synchronization immediately afterwards, I can confirm that updating only the target firewall was already sufficient.
Christian
Great, this will be hotfixed later this afternoon.
Cheers,
Franco