I call things wrong all of the time, and I am very sure it is not me, but auto-correct.
It happens, but this one was indeed a riddle that was very hard to solve. > On 2 Apr 2025, at 11:24, Adolf Belka <[email protected]> wrote: > > Hi Tom, > > On 01/04/2025 23:52, Tom Rymes wrote: >> 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. > > LOL. I have suffered some of those on my phone but that one is a beauty. > > Regards, > > Adolf. > >> 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 >>>>> >>>>> >>> > >
