OPNsense config file maintenance recommendation

[binaryanomaly]

I have an OPNsense installation that is now a bit older ~2 years. I did some hardware changes and reconfigurations along this.

Now I have the feeling that my config file probably accumulated quite some stuff that may not be ideal anymore.
On the other hand I'd want to avoid time consuming setup from scratch. OPNsense is a critical piece of my infrastructure and longer internet downtimes are socially not acceptable

On the other hand some times OPNsense config pages load slow. In general they're fast but sometimes they just keep loading which let me believe some clean up would be beneficial.

Manually cleaning out the config file seems to be a bit dangerous as well.

Any recommendations regarding low-risk OPNsense house-keeping? How does everybody do this?
Thx

[lilsense]

Find a good weekend around 3AM on Saturday is preferable...

capture all things config.

Clear/reset the OPNsense.

Begin Fun!

[binaryanomaly]

Haha, unfortunately that's also socially hard to sell... 

Guess this may end in:
the pitcher goes so often to the well that it is broken at last
*OPNsense

[cookiemonster]

Why not try to validate the assumption? Dowload the config file from the UI and open it on a text editor.
Chances are the file size is miniscule in the small hundred Kb of size. There shouldn't be any "accumulated old stuff" and you can verify by eyeballing it.

[binaryanomaly]

Yes that's certainly an option. Quite time consuming but an option...

[lilsense]

Are there any FW appliances out there that have what you are requesting?

[binaryanomaly]

I think some handle it a bit better. I have to analyze the config file first.

But to make it short: Replacing a NIC on a server triggered a new interface assignment (only 1 changed) which kind of made a mess of my opnsense. It mostly recovered by now and I reconfigured some things but I still don't trust it fully without verifying it.

Things such as static dhc assignments, fw rules, etc. where just lost afterwards.

[cookiemonster]

Are there any FW appliances out there that have what you are requesting?

Of course. The suggestion is not to go line by line. There wil potentially be thousands. Instead to collapse all xml nodes then expand a few, just to verify/confirm as I expect, that the only entries there are the ones in use i.e. no cruft.
My theory is that the config file size is not the problem for pages to load slowly.
Normally those are for large firewall rules only in my experience, or simply the system is under load for a reason or another and for instance starts swapping.

I think some handle it a bit better. I have to analyze the config file first.

But to make it short: Replacing a NIC on a server triggered a new interface assignment (only 1 changed) which kind of made a mess of my opnsense. It mostly recovered by now and I reconfigured some things but I still don't trust it fully without verifying it.

Things such as static dhc assignments, fw rules, etc. where just lost afterwards.

Ah. For that, from the console you should be able to re-assign interfaces after boot and it will put the right names in the right places in the config file.

[binaryanomaly]

Ah. For that, from the console you should be able to re-assign interfaces after boot and it will put the right names in the right places in the config file.

That‘s what I did.

But it nevertheless caused some configurations to be lost and or/wrong.
Out of 4 interfaces only 1 really changed effectively but it was enough to confuse opnsense completely. Worse it usually does some autoassignment as a fallback which is almost ever completely wrong. This might be the root cause for what I‘m currently dealing with.

[harshw]

I had eight or nine VLANs and four interfaces - had the same problem

I used Visual Studio Code and its excellent XML editor, took a default Opnsense config file and went through the two and compared. Takes a while but the next time you get a mis-assigned interface, it is quite easy to put back

[binaryanomaly]

This is the way... 

Looks like there's no way around doing this.
Might leverage the selective backup restore capability in order to minimize risks.