Super long frustrating story short as I can make it. Had some severe weather, lost the PSU in my OPNsnese box. Had a spare dell PC with a quad port nic I keep as a backup in case of a hardware failure. I need to know if I've hit a bug that I need to report or if this is just ignorance on the restore process.
So, to try and recover here is what I did. I created my bootable ISO, installed my backup PC in place, booted the opnsense media >
The config import option presented in the console on install seems unable to mount a separate USB drive with my backup xml. I don't know if this means the usb drive is formatted in a format it cannot read or if there is something more specific it's looking for. But no matter in the past I just booted the live environment, imported backup, updated interfaces and moved on. So that's the path I headed down >
Booted into the live environment, imported my backup file, and I am met with the expected interface assignment warning. That's where this all fell apart for me.
I have the following interface:
- 4 physical interfaces
- 2 VPN interfaces, wireguard and zerotier
- 5 VLAN interfaces
-I navigate to interfaces > assignments, then change the wan and lan interface to match the physical nics they are now plugged into on the new hardware. Click save but it warns that it can't save due to the vlan parent interfaces being wrong and resets my assignment.
-Ok, so navigate to interfaces > devices > vlans and attempt to change their parent interfaces. But then it won't let me save due to the vlan naming. Apparently my naming is old and has the interface name in the name (ix0_vlan10) for example, so I decide to just fix it to start with "vlan" as the warning dictates. But it won't let me save it because "Interface cannot be changed while assigned". So it sorta deadlocks me...
-Fine so let's go just delete the assignment, can't it's in a group...
-Fine go remove the vlan's from the group their in in the firewall config
-Back to assignments, delete vlan assignments, assign lan and wan to their correct nic, and click apply and I lose my connectivity to OPNsense entirely no idea why...
I did this process on repeat maybe 5 or 6 times with trying slight variations each time. Every time it ended in loss of connectivity to the LAN interface on my firewall.
With all that said, is this user error? Do I not understand the process? Or has my old vlan naming config deadlocked me into being unable to restore to dissimilar hardware? If so how do I fix this config so that I don't get so locked up in this situation next time?
This time I was able to rob a WAY too large PSU out of a gaming computer to get my original OPNsenese box powered back up and a replacement part ordered but if this was an issue that I couldn't have repaired I would have been reinstalling and configuring OPNsense from scratch.
I just did an import on bare metal (from a VM config). I used a FAT USB.
The drive had the entire /conf directory copied from the source. You need at least /conf/config.xml.
Before the import, I searched/replaced all physical device names (vtnet -> igc in this case).
My vlan devices were already vlan0_<VLANID> so I didn't have to convert these.
It has to be any FAT except extFAT
Quote from: EricPerl on May 22, 2025, 11:14:16 PMI just did an import on bare metal (from a VM config). I used a FAT USB.
The drive had the entire /conf directory copied from the source. You need at least /conf/config.xml.
Before the import, I searched/replaced all physical device names (vtnet -> igc in this case).
My vlan devices were already vlan0_<VLANID> so I didn't have to convert these.
ah ok, so I can't just put my backup xml on a usb drive and it import it in the console? Also I encrypt my backups so opening and adjusting doesn't seem like an option, I'd have to make an unencrypted backup to make that sort of modification. I could make an unencrypted one now, but that doesn't help when my machine was borked.
Quote from: cookiemonster on May 22, 2025, 11:21:28 PMIt has to be any FAT except extFAT
It's formatted in fat32, but from the above post sounds like it was looking for some config file maybe copied from the actual OS instead of my backup xml that get generated nightly.
The file needs to be /conf/config.xml on the USB drive (NOT at the root).
I have a last known good version of the entire /conf of the appliance (which contains all versions).
Straight scp...
You can compare with a version obtained from your backups. I expect them to match.
Quote from: EricPerl on Today at 01:35:23 AMThe file needs to be /conf/config.xml on the USB drive (NOT at the root).
I have a last known good version of the entire /conf of the appliance (which contains all versions).
Straight scp...
You can compare with a version obtained from your backups. I expect them to match.
so maybe if I had renamed the backup config.xml and created the /conf/ file structure it might have been able to find/read it?
But even then as long as I have encrypted backups I'll still have the issue of figuring out the vlan/interface deadlock post restore. Unless there is some way to open the encrypted XML file outside of opnsense. I feel like if this wasn't user error it might need a bug report.
I feel like maybe we've strayed off the issue at hand. IMO at least editing backup conf files before a restore seems broken. So either I need to fix my vlan config to match current standards so I don't get deadlocked or some other better understanding of the recovery process and interface assignments (if it's some user error on my part).
Starting with the first one, what's the best way to rename these vlans to match current naming convention?
"vlan0*" as far as I know. Can be "vlan07" or "vlan0.7" or anything but must start with a 0.
Unless things changed again, recently :-)
Quote from: FullyBorked on May 22, 2025, 02:59:32 PMApparently my naming is old and has the interface name in the name (ix0_vlan10)
this is also something i had noticed after my last upgrade.
i think it's a good idea to move to that (standard?) naming for vlans, but they might want to have had something to prevent legacy machines from breaking on it (like automatically changing the names when upgrading, if that would be possible for example)
the best solution would just indeed be updating the configs to be vlan0.x instead of ix0_vlanx
the "maybe the devs can think of old users" option would be to have something in the restore that catches old naming conventions and automatically updates it.
i think it's just a scenario that's not been thought of to test (old interface naming of vlans, and restoring that to a different host is likely not a daily use case)
guess i'll be adding the "update vlan naming" to my todo list as well before i get bitten in the same way you did.
Quote from: FullyBorked on Today at 03:54:50 AMI feel like maybe we've strayed off the issue at hand. IMO at least editing backup conf files before a restore seems broken. So either I need to fix my vlan config to match current standards so I don't get deadlocked or some other better understanding of the recovery process and interface assignments (if it's some user error on my part).
Starting with the first one, what's the best way to rename these vlans to match current naming convention?
I've done 3 or 4 configuration imports over the past 9 months. PCIe passthrough -> vtnet (twice), vtnet -> bare metal igc.
The only time I've ran into trouble was user error (mangling filenames while building an ISO, which would not have occurred with just /conf/config.xml).
All my VLANs follow the vlan0.VLANID convention (not _ per previous message). I never had to tinker with these.