little story about a failed upgrade/ Une petite histoire d'un upgrade raté

[vigilian]

Hi guys,

Hope that everyone is okey.

So I was thinking of making this little post to make an echo about this posthttps://forum.opnsense.org/index.php?topic=19159.0.

So I know this ancient post is a bit of a rant but after yesterday I need to say that the upgrade of opnsense i kinda disappointing and I can understand the rant of  this guy.

So saturday I have worked a lot on my new opnsense setup
the setup is a kvm setup on a little homemade rack server under fedora server 33.
I want to specify first that I have several instances of opnsense and it didn't happen with every instances, jthis one was just the worse, others had some other problems but not as dramatic than this one.

the goal of this instance is to put opnsense as firewall of several VMs who are linked to different virtual interfaces in opnsense for different purposes. Some goes through a vpn, others through tor etc.
Opnsense instance is also contained in a VM so every interfaces is virtualized too. the networks linking VMs are also virtualized one and everything is on the same server.

The WAN interface of this instance is a bridge0 interface which normally resides in first position.

So I was working and making a lot of changes in this instance including trying to setup a wireguard setup to vpn server which has a dedicated ip for me and port forwarding . So I made a bunch of rules, port forward rules, etc. All the interfaces were assigned correctly.

I applied the settings of course so everything was running. I didn't backed up the configuration.
there was 2 kernel updates waiting on this fedora server and there was the upgrade to 21.1.3 and I was under 21.1.1 I think?  So not major upgrade normally.

So I've made all the necessary updates and rebooted everything.

What happened do you think?
Well opnsense decided on its own to change the interfaces assignments . There was no more OPT1 -> 4, just a LAN and a WAN where the bridge0 has been assigned to LAN this time.The WAN interface was now the second virtualized interface.
So I couldn't reach opnsense anymore. According to the boot screen, there was no DHCP plan either since LAN was back at 192.168.1.1 .... strange... none of my virt interfaces was using this network and even my WAN before was not using this one.
So no rules, no port forwarding...
I was stucked with my badass password in root so couldn't login like I would be able to do in pfsense for example by using https://docs.netgate.com/pfsense/en/latest/troubleshooting/locked-out.html
By chance I've come up with using the first 3 steps and then logged back in root login screen and reset the password before to reboot in multiuser mode.

So I had also had to use the trick to only assign the WAN interface to retrieve back control of the WEBGUI to see what the damages were.
the openvpn and other packages were still installed.
So not a disk problem. and anyway it's isntalled on 2 new sandisk SSD in RAID1 in a qcow2 file so it can't be that or the file would be simply corrupt.
only everything related to interfaces has disappeared.... firewall, assignments, names, everything...

So I need to re-do everything.

So I can understand how upsetting it is for someone who is not as focused as I am on my tasks to have everything lost.

So I only see 2 possibilities here,
1/ the updates code are really screwed up.
2/ there is some edge conditions where updates through webgui does go to shit... I still can't determine what. But if it is that, then it means that update process is relying on webgui which is horribly wrong since it should be an independent process. So I hope it is not that.

just food for thoughts to the coders of OPNSENSE.
Thanks for reading.


--------------------------------------------FRENCH VERSION ----------------------------------------------------

Bonjour la team,

J'espère que tout le monde va bien.

Donc je pensais à faire un petit écho au post de ce gars là: https://forum.opnsense.org/index.php?topic=19159.0

Je sais que ce post est plutôt un rant de ce gars en question mais je pense qu'il illustre bien ce qui m'est arrivé ce week-end et je ne peux que donner en partie raison à ce gars.

Donc samedi je bossais beaucoup sur cette instance spécifique d'opnsense que j'ai installé sur un server rack conçu moi-même sous fedora 33 server.
Je tiens à préciser avant tout que j'ai plusieurs instances d'opnsense et que j'ai eu ce gros problème qu'avec celle-là. Les autres ont eu aussi des problèmes sur cette mise à jour mais pas aussi gros.

Le but de cette instance est de mette opnsense dans une VM et agissant comme pare-feu pour toute une série d'autres VM sur le même serveur. Ces VM étant connectées par des réseaux générés par kvm-qemu et donc reliées à des interfaces virtuelles de la vm opnsense.
Certaines de ces VM vont à travers des vpns, d'autres tor, etc.

L'interface WAN est donc sur une interface bridge0 qui se trouve en première position dans la liste et donc normalement pour la VM aussi.

Donc je bossais sur beaucoup de changements dans cette instance et notamment faire un lien wireguard entre un serveur et cette instance, qui a une ip dédiée et du port forwarding. Du coup, pas mal de port forward rules, de firewall rules etc .
Tout fonctionnait correctement et les paramètres étaient appliqués et fonctionnels.

J'avais plusierus mises à jours en attente, des kernel update sur le serveur fedora lui-même. Et la mise à jour vers 21.1.3 alors que j'étais sur 21.1.1 d'opnsense il me semble. Donc normalement pas de grosses mise à jour.

J'ai fait tout ça et j'ai rebooté.

Qu'arriva-t-il?

Opnsense n'a plus rien reconnu et a décidé de soi-même que le bridge0 finalement c'était pas assez bien pour le WAN donc il allait le mettre en LAN et plus de WAN plus d'OPT rien.
J'avais évidemment pas sauvegardé ma config sur un fichier.
Il avait purement et simplement réinitialisé toute la config concernant les interfaces et donc les liens entre les interfaces, les règles pare-feu etc.

Alors Je me retrouvais juste avec la console, locked out pusique j'avais un gros mot de passe pour le root. Pas moyen de faire copier coller sur la console. Donc je devais trouver un moyen de réinitialiser le root password.
J'ai donc suivi la doc netgate de pfsense : https://docs.netgate.com/pfsense/en/latest/troubleshooting/locked-out.html
Mais évidemment la dernière étape est pas dispo sur opnsense donc par chance je me suis juste reloggé avec root et je me suis retrouvé sur l'écran de démarrage normal à partir duquel j'ai reset le password.

J'ai reboot en mode multi-user et j'ai utilisé le truc que je dois toujours utiliser en réassignant juste le WAN pour avoir de novueau accès au webgui et de là j'ai pu constater les dégats.

C'était vraissemblablement pas un problème de disques puisque d'une part les paquets que j'avais installé en plus étaient toujours là. D'autres parts ce système est sur deux novueaux SSD sandisk en raid1 et si y avait corruption le fichier qcow2 serait devenu illisible.

Donc je dois faire tout de nouveau.

Donc vous imaginez bien que je peux comprendre la furstration de quelqu'un qui a tout perdu aussi et qui est peut-être moins déterminé sur ses tâches que moi.

Donc il y a deux possibilités ici,
1/ soit le code des updates c'est vraiment de la merde.
2/ soit dans certains cas limites, les updates à travers le webgui font de la merde et je ne sais pas déterminé quoi exactement. Mais si c'est ça, alors ça pose quand même un problème conceptuel qui est que normalement un update process est indépendant du reste. Si c'est pas le cas, c'est vraiment vraiment pas bon.

Doncvoilà de quo ifaire travailler les méninges des codeurs d'Opnsense quand ils auront du temps.
Merci pour votre lecture.

[Maurice]

Might or might not be caused by the update. Could be just a generic interface assignment issue triggered by the reboot. Happened to me once with a specific type of virtual interface.

For "special" interfaces, I'd always recommend to lock them ("Prevent interface removal" in the interface's settings).

Cheers

Maurice

[vigilian]

there are all virtualized interfaces and since it's fedora with qemu so it means REDHAT product and so it means virtio drivers. And what do we tell about virtio drivers? That there are the most optimized drivers and more stable ever.... So I don't know guys....

But thanks for the advice anyway, but the fact that we should check this box, .... really???..... It reminds me of those MMORPG where you actually do find a problem or an exploit and then the GM is responding by "Ow but this is a FEATURES.... " or a "GAME  MECHANISM" ... sounds lame really ...
I think that, if it is really a feature, =====> then really need to have a specific doc page about it. With an actual explicit title like "What to do when your interfaces assignment goes to shit after an update"

[franco]

There's a solution here and the fact that Redhat is great. So are we here then?


Cheers,
Franco

[Darkopnsense]

Bonjour @Vigilant,
Ta mésaventure je l'ai vécu une fois (il y a deux ans, sur l'APU4C donc en hardware), les affectations étaient réinitialisées au valeur par défaut. Le fichier config réseau n'était plus supporté.
Je confirme que depuis j'empêche la suppression des interfaces.
Cordialement,

[vigilian]

There's a solution here and the fact that Redhat is great. So are we here then?


Cheers,
Franco

I guess you forgot a why in your phrase.
Redhat is rubbish on several accounts, totally true. But apparently, since I'm not the only case of that happening well there might be some improvements to do.
Anyway thanks to you all for the tip about non removal interface.
I must specify that the MAC address in fedora for the VM opnsense didn't change from before to after the upgrade of the kernel. So unless opnsense is relying on something else than MAC address to identify a NIC (which I don't really see on which varable it could rely on) I do'nt think it can really be the fault of the kernel upgrade.... But yeah sure why not blame redhat on this one.

[franco]

This must be some sort of language barrier we're unable to cross:

it's fedora with qemu so it means REDHAT product and so it means virtio drivers. And what do we tell about virtio drivers? That there are the most optimized drivers and more stable ever....

What, I cannot call into question this over the top characterisation? Do you just want this to be the conclusion to your problem description? Why post this in a forum where other people might respond?


Cheers,
Franco