Hi Tom,
On 01/04/2025 22:44, 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.
I have tested this and the old ipsec certificate connection kept on working,
even though the restore had only a PSK connection and no certificate connection.
So not doing a restart would leave the existing connections going but the
connections that were restored would not work. So the question would be why do
a restore if you don't intend to replace the existing connections.
You don't need to do a restart on OpenVPN to be able to use the restored client
connections.
So if I don't do the ipsec restart, then users will need to remember that for
IPSec, they have to manually restart the daemon to be able to access the
restored connections, but not for OpenVPN.
Seems a bit inconsistent with that approach.
Would be good to get @Michaels input on this.
Regards,
Adolf.
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
