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 4ZS1v40BM8z335f for ; Tue, 1 Apr 2025 21:52:32 +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 4ZS1v03cTNz2xbk for ; Tue, 1 Apr 2025 21:52:28 +0000 (UTC) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4ZS1tz1nQ8zBm for ; Tue, 1 Apr 2025 21:52:27 +0000 (UTC) Authentication-Results: mail01.ipfire.org; dkim=pass header.d=rymes.net header.s=google header.b=SZHwqEXv; spf=pass (mail01.ipfire.org: domain of tom@rymes.net designates 2607:f8b0:4864:20::82c as permitted sender) smtp.mailfrom=tom@rymes.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1743544347; 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:dkim-signature; bh=8CN0YMfF9MIRWRjE9cRCIKl6cbIHI2wPWMVIvl8Wn/Q=; b=qGixF2QYZGNjJrPcAfj3jpmPaJnHL1qtHoJ9gDeIuixIcrdjMU+XJ7KvpgjjVU7k9qqBXP DjkzeS5oEZKhMo4XWuPIDazFD7NhcFCLB+oA/iymu1Xa8MCa2t/8lm7bnOU9YylR7FbzUo 38S8sdftyAyeWNMgQu46TLXwd6gmDKyHht4/2aMetVH9OyGoBo45g9YlaKFdFsIWPsUHtx B1Td+EEQWSYlA4qmkq5FWth8Y5sPDMeJWJ37gb+TeahMVgdaCHZhgrY0hTaQ7rng2ad3Ly KkgaYzRetomb/AgW/MceT8fvtLdn/Y11ROR9LDZwNns5hPwHTP0DS7zqG6n6yA== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=rymes.net header.s=google header.b=SZHwqEXv; spf=pass (mail01.ipfire.org: domain of tom@rymes.net designates 2607:f8b0:4864:20::82c as permitted sender) smtp.mailfrom=tom@rymes.net; dmarc=none ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1743544347; a=rsa-sha256; cv=none; b=bJ/PfIDlV4oh3u69L2GB4rT8BFeDU8UeDfiPKSbdLcQZ9y6tg+brxCQ5kzAnEozjq39dfx v3zJs+6LrxEGNX0TAjatXbwD5D1EnfsJtgOb/tNRo7SQuLbqRlZAo757AmPEnMxDopNZyp AOOYE33MWzE9N7kDeKvECGlfzFOgpGNhvYFQOZ4EUFZm2Oq4ddkNHvzSzKSgNsnZBau7XG rr3GJW0bs/lmbq686VnLqNn+b/CnHaQa26+nDs1+bwczerAOqBF6rYg4xhgeieo79UwaYV E4EBA9/tNIDViD3G4TXk731GV5Ht3C6YNzdP3UwmBYpqoSb6ashx3Y51bduOFA== Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-476b4c9faa2so77944291cf.3 for ; Tue, 01 Apr 2025 14:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rymes.net; s=google; t=1743544346; x=1744149146; darn=lists.ipfire.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=8CN0YMfF9MIRWRjE9cRCIKl6cbIHI2wPWMVIvl8Wn/Q=; b=SZHwqEXvrcQCJgYWLqFyq7ki4zCGT/Ur+NR9EdJHimp8G20UK6BUwMYdfh78UH8RxC XUP1B48IU8VfyfkzaGpt4XvM+oG5ReeNVszGJBNDgLjHT2NtNehEnK5vgCCiVkN4XhY0 6gqEF98lc7gM/kMSTw+eO2EageqCnTgMBfp3s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743544346; x=1744149146; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8CN0YMfF9MIRWRjE9cRCIKl6cbIHI2wPWMVIvl8Wn/Q=; b=ZqiJzqsglHWalbMY4vmmjBF+o1z8rNEKz7LKnP103JvF7zdstku3ccNuOkbVtFcXct AeIMEBdar9dhH0VIaAYGRf8lab3yrUoXH4IgdybegoXX0TgW0t6YbOePIyt7D4DIujmf 4Sl4FRjVObdumfeCxY37zZ5lrbcM4ikto5TgHTWEmIxcmyIHqUbktCuos9zPBCIODwxz xPP9Lzr1wdCv0bgyoDTD0NWLJz7g+BSafz+MSn3ksp2i2inzKRaB+foGBy7j+QJRsCgl mZqiN1jO8qUKGZNTsxtGKl9y7PlaOer/hZmu7WeT6FpyxNpNgfkcwriyf4Q3uaYjYgS1 FX3A== X-Gm-Message-State: AOJu0Yy6gWoHGYuWlLo/I1nNISJ9O6FRhgxNjNegiY+BXQ8/2PrTHiZd ccwo1RO2vhQcIyPg/LpatfNWusgObUmUuLiIR6bQU96m3wi1E95l5mlA371NHMQ= X-Gm-Gg: ASbGncuVlVfCMjowde4zYvdCUbomEU65snC5m0S3tlxGbu0c6NxClTXoz2eTwvyncpU 9vS+sZIIN4lgrGzM/M4c92Xbo3+6LJl63aVmDXNGqT9pGgd+eP0BWy2GIcg+U3q/q4YnClaNfnm ykaDpXT9v/o4eJdM2WYqSig6KU/BH2AEiz4ejnqDDEXDw4wt9jWzjez6WWYHjDMAzAjl2hDFOnl V5CLmltrTiOHPwhIZwN216u0zbf/nOJgfQwL+RiBzbi++h6vZkaHfD4w5E645binbJUm3IZwxsi MfP3xFnpdBTBm3TqC4DL5lFyF/TAo1CCIE0H0IAK8Rqj8el4rY27BoT8Ws8B8Tep8hvbw33Ulsf 35ikGOWs21e941fs= X-Google-Smtp-Source: AGHT+IGbzSJuPAaIGhd6+g+D0RocG8xm+TxeohCK1zqV0seDW3d1nJ8iK8R2cJNmvK2Xg18H/OILBA== X-Received: by 2002:a05:622a:d2:b0:476:a03b:96e1 with SMTP id d75a77b69052e-477ed78a2c8mr222516021cf.52.1743544345788; Tue, 01 Apr 2025 14:52:25 -0700 (PDT) Received: from smtpclient.apple (c-73-119-24-220.hsd1.nh.comcast.net. [73.119.24.220]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-477831a3653sm70912641cf.72.2025.04.01.14.52.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Apr 2025 14:52:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Tom Rymes Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 4/6] backup.pl: Fixes bug13737 - restarts ipsec to use the restored certs etc Date: Tue, 1 Apr 2025 17:52:14 -0400 Message-Id: <1D69F7C2-46D6-4AFB-B6DD-98E2915CCD50@rymes.net> References: Cc: "IPFire: Development-List" In-Reply-To: To: Adolf Belka X-Mailer: iPhone Mail (22D82) X-Rspamd-Server: mail01.haj.ipfire.org X-Rspamd-Queue-Id: 4ZS1tz1nQ8zBm X-Spamd-Result: default: False [-9.47 / 11.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[99.99%]; IP_REPUTATION_HAM(-0.98)[asn: 15169(-0.27), country: US(-0.01), ip: 2607:f8b0:4864:20::(-0.70)]; NEURAL_HAM(-0.98)[-0.981]; R_DKIM_ALLOW(-0.20)[rymes.net:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[rymes.net]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[rymes.net:+]; APPLE_IOS_MAILER_COMMON(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[development@lists.ipfire.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; RECEIVED_SPAMHAUS_PBL(0.00)[73.119.24.220:received]; DKIM_REPUTATION(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82c:from] X-Rspamd-Action: no action Adolf, I wouldn=E2=80=99t worry about any additional testing. So long as it=E2=80=99= s 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 ba= ckup) should make this obvious. Lastly, =E2=80=9CAbagail=E2=80=9D was just autocorrect=E2=80=99s fun way of c= hanging =E2=80=9CBugzilla=E2=80=9D, for whatever reason, so please disregard= . Tom > On Apr 1, 2025, at 4:44=E2=80=AFPM, Adolf Belka w= rote: >=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 s= o that the user knows existing connections will be dropped, or is this only u= sed 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 cert= s 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 y= ou currently could also have a problem if you do a restore from an old backu= p which had different ipsec client connections. >=20 > I am not sure that any existing connections would continue working current= ly 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 conn= ections would work. >=20 > I will try and find some time to see what happens if a restore on a non x5= 09 cleared system replaces things with an old version but the server is not r= estarted. Do the existing client connections still work if they were already= ongoing, and what happens if I try and newly connect with the previously wo= rking connection. >=20 > The only alternative would be to not use that patch to do a restart but th= en after a restore has been done then none of the restored connections will w= ork 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 throu= gh a period of restoring the backup and then having the connection from the c= lient continuously failing to work until I though to try out pressing the Sa= ve button in the Global options section. >=20 > We don't have to press any buttons for restores on any other WUI page so t= hat doesn't seem consistent to me that it would need to be done for the ipse= c page restore. >=20 >> I=E2=80=99m thinking of a PSK connection that would be reset if you resto= re certificates, perhaps? >=20 > The PSK in the ipsec.secrets file will be replaced with whatever was in th= e 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 wit= h the new ones. >=20 > I think the user needs to understand what version of backup they are resto= ring from and that there might be an interruption in service, in the same wa= y as when doing an update and you have to do a reboot. All existing connecti= ons will be lost at that point. >=20 > I will try and do some testing but I may not have time before I am going o= ff travelling. >=20 > Something does need to be done to fix this bug because currently if your h= ost cert expires the renew function is not working properly and will fail an= d the only option there is to replace the root/host cert, which will also re= move all the client connections based on certificates. The PSK connection wi= ll stay in place, although I am not sure if it still works with a new root/h= ost x509 cert set or not. >=20 > Having said all the above, I need to do a v2 version of this patch 4/6 any= way 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 th= en 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 r= estore 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 g= et 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