[17.7.1] Restoring previous config fails partially

[Mr.Goodcat]

Hi,

in my configuration there is a LAN bridge with multiple interfaces from different NICs. Now if a previous config is restored, the interface assignment is lost, thus making the box unavailable as LAN, WAN etc. are mixed up and need to be configures from scratch.
This might also be connected to one of my RealTek NICs vanishing occasionally (either a driver issue or it's broken). Nevertheless, interfaces should be kept as they have been configured, with only unavailable NICs being dropped. Having to manually restore every configuration item that is tied to the interfaces essentially makes restoring past configs useless to me. Also IP-MAC assignments of the DHCP aren't restored, which makes recovery all the more painful.
Is this a known issue or can I provide any additional data to hunt this bug(?) down?

Thank you and kind regards,
Fabian

[bartjsmit]

Hi Fabian,

Realtek devices have a chequered history with OPNsense due to issues with FreeBSD. Do you reboot the firewall after the restore? In that case, adding a boot delay may help all network devices registering properly. This is set through a plugin. Firmware -> plugins -> os-boot-delay

Bart...

[Mr.Goodcat]

Hi Bart,

thanks for the feedback! I'll try the plugin you suggest and see if it helps.

After the restore I did a reboot, on which OPN asked me to reassign interfaces. The logs show, that one of the realtek devices hasn't been found. That is why I assume a connection of these events.

Nevertheless it would be great if an interface config would be restored as far as possible, even in cases of broken/missing NICs. Otherwise, once a single interface breaks down, one would have to reconfigure everything to get OPN back to a working state. Most people probably don't have spare NICs laying around to quickly replace faulty ones.


This is my setup, with "---" indicating which interfaces reside on a single NIC:

WAN:
RE0

LAN bridge:
RE1
-----
igb0
igb1
igb2
igb3
-----
cxgbe0
cxgbe1

[Mr.Goodcat]

Here's an update of the config failing to restore properly:

The IP-MAC assignments of the DHCP are restored correctly, but two bugs cause OPNSense to be unreachable.

• Although the DHCP and thus MAC-IP assignments are deactivated, OPN still uses this data to populate the ARP table. In my case this created a mismatch as the MAC-IP pair in OPN differed from the one I was actually using (as another DHCP was active, which would later be replaced with OPN once configuration was finished).
• When a config is restored the ARP table isn't flushed. After doing an arp -d -a, i.e. dropping the APR table manually, and rebooting OPN, the ARP table was populated with the right data, as learned from the connected network.

I believe this to also be the cause of the following issue:
https://forum.opnsense.org/index.php?topic=5274.0

Perhaps a dev could look into this? Let me know if more data is required to get this fixed.


As for loosing the interface assignments:
The offending Realtek NIC was removed, so the problem didn't occur again. I'll try the proposed os-boot-delay at a later point and provide an update.

[franco]

Hi Fabian,

17.7.1 and up have an interface lock feature that should prevent this. New images will be available in 17.7.4 to try this. I don't think we find a way to prevent the removal in a stock 17.7 image at this point.

What you can do now is enable locking for your config from 17.7.3 and use this as a base for 17.7.4 images restore.

Just report back and we'll pick it up from there.


Thanks,
Franco

[Mr.Goodcat]

Hi Franco,

good to hear the issue is already fixed. Once I have time so try the new image/version I'll report how it went. Thanks for your effort!

Cheers,
Fabian