Adolf, I wouldn’t worry about any additional testing. So long as it’s obvious to the user that any established tunnels will be torn down and re-established, that’s all I was worried about.
It sounds (as I suspected) as if the nature of the operation (restoring a backup) should make this obvious. Lastly, “Abagail” was just autocorrect’s fun way of changing “Bugzilla”, for whatever reason, so please disregard. Tom > On Apr 1, 2025, at 4:44 PM, Adolf Belka <[email protected]> wrote: > > Hi Tom, > > >> On 01/04/2025 21:00, Tom Rymes wrote: >> I’m sure that this has been considered already, and Abigail’s is probably a >> better place to ask, but: Is there a warning of any type so that the user >> knows existing connections will be dropped, or is this only used in a >> situation where existing connections would not exist? > > I am not sure what "Abigail's" is a reference to. > > If you do a restore then currently the root/host certs and the client certs > and the PSK secrets etc will all be replaced in the /var/ipfire/vpn/config > and /var/ipfire/vpn/ipsec.secrets files anyway. So I have the feeling that > you currently could also have a problem if you do a restore from an old > backup which had different ipsec client connections. > > I am not sure that any existing connections would continue working currently > if a backup was restored even if the ipsec daemon was not restarted. > > It was just that I found doing an x509 clearout and then doing the restore so > all the client certs etc came back, did not give a system where the > connections would work. > > I will try and find some time to see what happens if a restore on a non x509 > cleared system replaces things with an old version but the server is not > restarted. Do the existing client connections still work if they were already > ongoing, and what happens if I try and newly connect with the previously > working connection. > > The only alternative would be to not use that patch to do a restart but then > after a restore has been done then none of the restored connections will work > unless the user remembers to press the save button in the global section of > the enabled ipsec wui page. That I definitely know, because I went through a > period of restoring the backup and then having the connection from the client > continuously failing to work until I though to try out pressing the Save > button in the Global options section. > > We don't have to press any buttons for restores on any other WUI page so that > doesn't seem consistent to me that it would need to be done for the ipsec > page restore. > >> I’m thinking of a PSK connection that would be reset if you restore >> certificates, perhaps? > > The PSK in the ipsec.secrets file will be replaced with whatever was in the > backup being restored. That is the same for all of IPFire. It also happens > with OpenVPN, where the existing certs will be cleared out and replaced with > the new ones. > > I think the user needs to understand what version of backup they are > restoring from and that there might be an interruption in service, in the > same way as when doing an update and you have to do a reboot. All existing > connections will be lost at that point. > > I will try and do some testing but I may not have time before I am going off > travelling. > > Something does need to be done to fix this bug because currently if your host > cert expires the renew function is not working properly and will fail and the > only option there is to replace the root/host cert, which will also remove > all the client connections based on certificates. The PSK connection will > stay in place, although I am not sure if it still works with a new root/host > x509 cert set or not. > > Having said all the above, I need to do a v2 version of this patch 4/6 anyway > as I have just noticed that I didn't update the backup.pl with the final > version I got working. The patch actually submitted won't work anyway. > > Regards, > > Adolf. > >> Tom >>>> On Apr 1, 2025, at 2:08 PM, Adolf Belka <[email protected]> wrote: >>> >>> - This adds a check if the ipsec server is enabled. If it is then >>> ipsecctrl is run to >>> restart ipsec and ensure that the restored certs are all being used. >>> - Tested this out on my vm testbed and confirmed that with this I could >>> restore a backup >>> and make the client connection as previously set up. >>> - Without this I had to press the Save button on the ipsec WUI page to get >>> the certs >>> etc being used. >>> >>> Fixes: bug13737 >>> Tested-by: Adolf Belka <[email protected]> >>> Signed-off-by: Adolf Belka <[email protected]> >>> --- >>> config/backup/backup.pl | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/config/backup/backup.pl b/config/backup/backup.pl >>> index 1c8c87d0a..a6d1467fd 100644 >>> --- a/config/backup/backup.pl >>> +++ b/config/backup/backup.pl >>> @@ -307,6 +307,9 @@ restore_backup() { >>> # start collectd after restore >>> /etc/rc.d/init.d/collectd start >>> >>> + # Reload ipsec certificates and secrets after doing a restore >>> + &General::system('/usr/local/bin/ipsecctrl', 'R'); >>> + >>> return 0 >>> } >>> >>> -- >>> 2.49.0 >>> >>> >
