Firewall Rules migrated but now with current Firmware all Setting Missing

[Nephiria]

Hi everyone,

I recently migrated all my rules to Rules New. But today I discovered that all the migrated rules are now gone, apparently due to a firmware upgrade.

New alias entries I created are also gone.

I find this rather suspicious, to be honest. I didn't notice it at first; it wasn't until the Crowdsec website told me that the OPNsense integration wasn't working that I checked again and discovered it.

Ive look on my Firewall : the Snapshot from that Migration i have created on 2026-02-20 19:06

[notspam]

Let us ask the crystal ball:

- From which opnsense version started to which new version was the upgrade path ?

- There was no interaction by admin ?
All rules deleted only by a firmware upgrade ?

This sounds exciting. More input would be helpful.

[Nephiria]

Hello everyone,

As I already mentioned, the migration was performed in February 2026.

I only noticed yesterday after seeing that something was wrong with the Crowdsec alias; it seems to have been reset as well. Everything was set up on the OPNsense around the same time.

And yes, all the migrated rules appear to have been reset. My rules are back in their original location.

I deleted them from the "old location" after the migration, once I had verified that everything was working correctly.

The only changes I made were installing Crowdsec on the OPNsense and firmware updates. I personally suspect that a firmware update might have loaded the old snapshot taken before the migration, which is why everything was reset.

I'm currently on the following firmware version:

OPNsense 26.1.4-amd64
FreeBSD 14.3-RELEASE-p9
OpenSSL 3.0.19

It seems this happened during the upgrade from version 25.xx to 26.xx, but I can't say for sure. I'll probably have no choice but to perform this migration again. I just wanted to report it since these rules weren't deleted by me. I assume it was an automated process, like a firmware upgrade.

Unfortunately, I don't have any further information.

[Patrick M. Hausen]

But then you should be able to check the list of snapshots - active and inactive - together with their creation dates, and see if that theory holds. And possible activate the most recent one and boot into that. You have complete control over your snapshots from the UI.

[Nephiria]

Okay, I booted from the other snapshot and the rules were migrated. That would solve my problem, but the question remains whether this was done by the firmware.

[Patrick M. Hausen]

Hardly. An update installs to the currently active snapshot. Which is not necessarily the one that will be activated after next reboot.

The regular way to go for e.g. a major update for which I always create snapshots:

- I have a current and active after reboot snapshot, e.g. 25.7
- I rename that to 26.1 - because the update will install to the current one
- I create an additional one and name it 25.7 - it will keep the current state and can be reverted to if necessary
- I install the update into the current snapshot which will also be active after reboot and is already aptly named 26.1

Of course you can do the same for minor updates.

So possibly you

- created a new snapshot
- set it to active but did NOT reboot to actually make it the current runtime
- installed the update
- the system rebooted but with the snapshot you just created, thus reverting the update

HTH,
Patrick