Hello,
is it possible to back my configuration from ipfire 2.23 586 and restore it to a actual release,
freshly installed?
What files are backed up by the GUI?
Only /var/ipfire/* ?
Will all the openvpn certificates work?
Best regards
yes, provided that it is the same hardware. Otherwise you would need few adjustments.
You will find the answers to these questions in the fine manual.
yes.
1 Like
Hello cfusco,
thank you for your answer.
Ok, useful manual, but it didn’t describe a detailed list of backuped files.
THe ISO-Backup is from the actual ISO with all my configs? Amazing.
I did test-installation in a VM and invesgitatet the backup files, all in what i asumed.
What bothers me: The backup file is not password protected! It was easy to read the information from it.
Best regards.
not detailed, but it lists the main components of the backup tree.
No, they are not encrypted. You are correct. However the files are hosted inside IPFire which is password protected. To download it you need to access the Web User Interface with admin credentials. You could encrypt the ISO yourself for storage in an unsafe environment.
Another layer of protection would be useful, but as usual there is a trade off between functionality and complexity (leading to bugs) and the developers team is really small and really busy with IPFire 3.X development.
2 Likes
The backup files are just simple archive files so you can open the file with any archive viewer package and see the directory and file structure that has been stored.
The major version of 2.23 covers Core Updates 131 to 139 which is around 4 years old and the version of the IPS WUI page was a single provider. Current versions now use multiple providers and I am not certain that a restore from single to multiple providers works because of the major changes in file structure between the two. The Core Updates would work because a converter programme was used to convert the data from single to multiple providers.
You mention 586. If that means the architecture then you will not be able to restore to a current release as 32 bit architecture is no longer supported by IPfire since Core Update 163. The last 32 bit version was Core Update 162.
If your old hardware is capable of using 64 bit architecture then you can install the latest version and do the restore but you will need to follow the instructions in the following wiki section
https://wiki.ipfire.org/installation/hardware-change
If your existing hardware only runs 32 bit then you will need to find some new 64 bit capable hardware.
2 Likes
Thanks for you answers.
But:
Are you really, really sure i can backup
IPFire 2.23 core136 32bit
OpenVPN 2.4.7
OpenSSL 1.1.1d
and restore it on
IPFire 2.27 core182 64bit
OpenVPN 2.5.9
OpenSSL 3.1.4
and all of the OpenVPN certificates will work when clients still have
OpenVPN client 2.4.7 installed?
I will have differenet architectures (32bit->64bit) and different OpenVPN-Versions (2.4.7-> 2.5.9).
It is not an option to generate and install all certificates new on the clients.
Best regards.
As the clients are running openvpn-2.4.7 then they will not work with the old openssl-1.1.1d certificates together with openssl-3.1.4 on the server.
From Openvpn-2.5 onwards the option
providers legacy default
is available to enable the legacy certificates to be recognised by openssl-3.x
Many clients automatically have that option enabled by default.
However that option is not available in the openvpn-2.4 branch which is being used on the IPFire server being used and the clients.
Upgrading has been delayed for so long that it is now a very difficult situation. Everything has changed so much in that intervening period that doing a simple upgrade is just not feasible.
The first step I can think of would be to get the IPFire installation to be able to recognise the providers legacy option from above.
A copy of IPFire CU153 for 32 bit would need to be found and installed and then a restore carried out. That version would get IPFire to openvpn-2.5.0 which is where the legacy option first gets recognised.
Everything should hopefully continue working as previously as this is then 17 core updates difference instead of 46, although 17 is still a very significant step to do in an upgrade and things could still go wrong.
Then the openvpn versions would need to be updated in each of the clients one at a time. After updating the openvpn version on the client, the legacy option line should be added into the clients config file.
This can then be tested, client by client, to ensure that they continue working.
Then having updated IPFire and every client to an openvpn version of at least 2.5.0 then a backup should be taken and a restore of this tried onto the new 64 bit machine with CU182 on it.
The above is not an easy approach but it will only get harder as time goes by and the clients are running with openssl-1.1.1d which is very old, insecure and End Of Life.
The whole openssl-1.1.1 branch is now End of Life and in the time between 1.1.1d and the last version 1.1.1w there have been a very large number of security vulnerabilities found. Additionally some CVE’s that apply to the older openvpn versions include back to version 2.4.7
Therefore an update of the network from a security point of view should also be urgently considered.
1 Like
If you want to be more sure, I’d suggest taking time to build up an IPFire setup on VM and give it a try. Jumping ~50 updates and jumping architectures is a big “ask”.
Maybe something like this:
Do a backup to a separate external drive. Restore it on the VM running CU 182. See what happens…
On second thought, since you have an old 32 bit device and a 64-bit box - just use those and give it a try. Keep the old 32 bit box as-is as your backup!
2 Likes