From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZSLZW4Fvxz32wj for ; Wed, 2 Apr 2025 10:24:19 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature RSA-PSS (4096 bits)) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZSLZS0Nrhz2yHd for ; Wed, 2 Apr 2025 10:24:16 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZSLZR48qzz13; Wed, 2 Apr 2025 10:24:15 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1743589455; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xFQfOmUnRkD74tjYMGnFpeSw3q6M/MqE3yLqMHzjNks=; b=t6tVE6f0X0vr3eyybX9PcOwcHUC1DhHlqgWRwmUc+ZRjOBUJVPk36qHS1fBb8ko6XrET1n fz4Yw9R37ftBdcCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1743589455; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xFQfOmUnRkD74tjYMGnFpeSw3q6M/MqE3yLqMHzjNks=; b=Wv5jtVmi2lUj6D7QSt3ykiHpbD/hUH1SSwwh7p2NwO1ndKIK6qL9+GDeRdz7AyzVtU15Pq zKRO1N6hjxf/i18NrxWUmJoIda9v+GTgCMEDAxZcQyZGeTKHYdf68tm8/gu1/vB9NY8JaE 6O3PGIcQuKO2E8j9gbKeozMJhNujsykNTfFamG6aoKUrJgBRCwTKzgnmCWr4rTi3tOFTwN FuDm15hWcEO2bCnSA3wYZWFOoBJNlYVvT7PZFJtgN0c2GuO9iE9dP1IVW7eDMbYKgouH4E yJRwfS99mZ/LCB9AMCThe+Ey36cz64JXnXWHW8Pl4+Ddc2jyfr+3Ah7XHXlRqg== Message-ID: <8195eb1a-4c74-4472-9941-09b9310108a0@ipfire.org> Date: Wed, 2 Apr 2025 12:24:11 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: [PATCH 4/6] backup.pl: Fixes bug13737 - restarts ipsec to use the restored certs etc To: Tom Rymes References: <1D69F7C2-46D6-4AFB-B6DD-98E2915CCD50@rymes.net> Content-Language: en-GB Cc: "IPFire: Development-List" From: Adolf Belka In-Reply-To: <1D69F7C2-46D6-4AFB-B6DD-98E2915CCD50@rymes.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 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 >>>> Signed-off-by: Adolf Belka >>>> --- >>>> 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 >>>> >>>> >> >