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 4ZSLbn2CBBz332d for ; Wed, 2 Apr 2025 10:25:25 +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 4ZSLbj5RSgz2yHd for ; Wed, 2 Apr 2025 10:25:21 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZSLbj23kzzNV; Wed, 2 Apr 2025 10:25:21 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1743589521; 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=j7j9+h1JL0wAlh8qjeHgdCStOtAZrPOtz6HU51RWYi0=; b=Ooo7zCU9AMdb2PM2GZu094KWw0DHChy819jNHaubjKtag3Ovk/kC6lGyhgW9rh0LEWxiLS lig2/OkUX0trZOAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1743589521; 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=j7j9+h1JL0wAlh8qjeHgdCStOtAZrPOtz6HU51RWYi0=; b=VzREwXf3rDhqrqpS9tv5oN1P8sWBZyZAG4i3+Up++PeXngyh26jDfeEn/IKBSEkPa8wGEu qQnugvrVsEEFbdVF+ppyOiUCp0NZfl1Uz1dGUMaUDJ8GgzvH4cc7TpG0QjhJvv/j9qppfj PDyXMEz2BRzoO8sjq6mucjUS4SXzmmA6cVUQVPJEaGVwhxv7kvbfcEthoKzss+P4PaAPuu paZcUV2U414b9IhC11yxWbuyVlszWi8SCLp8uSYrOq7XsZFO5ipAMxs0SeX9wH1GFc9vkh hLVp5XNQaBdQdN+GB8u/gg8kTiPOhmo7mNZD0L7Tc5F3fJJG/bvGAPfpqqC95w== Content-Type: text/plain; charset=utf-8 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 From: Michael Tremer In-Reply-To: <8195eb1a-4c74-4472-9941-09b9310108a0@ipfire.org> Date: Wed, 2 Apr 2025 11:25:20 +0100 Cc: Tom Rymes , "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D69F7C2-46D6-4AFB-B6DD-98E2915CCD50@rymes.net> <8195eb1a-4c74-4472-9941-09b9310108a0@ipfire.org> To: Adolf Belka 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 wrote: >=20 > Hi Tom, >=20 > On 01/04/2025 23:52, Tom Rymes wrote: >> Adolf, >> I wouldn=E2=80=99t worry about any additional testing. So long as = it=E2=80=99s obvious to the user that any established tunnels will be = torn down and re-established, that=E2=80=99s 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, =E2=80=9CAbagail=E2=80=9D was just autocorrect=E2=80=99s fun = way of changing =E2=80=9CBugzilla=E2=80=9D, for whatever reason, so = please disregard. >=20 > LOL. I have suffered some of those on my phone but that one is a = beauty. >=20 > Regards, >=20 > Adolf. >=20 >> Tom >>> On Apr 1, 2025, at 4:44=E2=80=AFPM, Adolf Belka = wrote: >>>=20 >>> =EF=BB=BFHi Tom, >>>=20 >>>=20 >>>> On 01/04/2025 21:00, Tom Rymes wrote: >>>> I=E2=80=99m sure that this has been considered already, and = Abigail=E2=80=99s 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? >>>=20 >>> I am not sure what "Abigail's" is a reference to. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>> I=E2=80=99m thinking of a PSK connection that would be reset if you = restore certificates, perhaps? >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I will try and do some testing but I may not have time before I am = going off travelling. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>> Tom >>>>>> On Apr 1, 2025, at 2:08=E2=80=AFPM, Adolf Belka = wrote: >>>>>=20 >>>>> =EF=BB=BF- 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. >>>>>=20 >>>>> Fixes: bug13737 >>>>> Tested-by: Adolf Belka >>>>> Signed-off-by: Adolf Belka >>>>> --- >>>>> config/backup/backup.pl | 3 +++ >>>>> 1 file changed, 3 insertions(+) >>>>>=20 >>>>> 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 >>>>>=20 >>>>> + # Reload ipsec certificates and secrets after doing a restore >>>>> + &General::system('/usr/local/bin/ipsecctrl', 'R'); >>>>> + >>>>> return 0 >>>>> } >>>>>=20 >>>>> -- >>>>> 2.49.0 >>>>>=20 >>>>>=20 >>>=20 >=20 >=20