Hi Herbie, > Today's topic is that when the daemon restarts, the security policies > all get deleted. This leaves the kernel completely wide open...
Actually, the policies are NOT deleted from the kernel. So the SAs and policies are actually used without interruption after the daemon has crashed. Until the SAs expire. However, we don't set lifetimes on policies so plain packets should not leave the host even when the SAs are eventually gone. But because those entries are still in the kernel when the SAs are reestablished, after the charon daemon got restarted by the starter daemon, you'll get these EEXIST errors: > 11:51:00 09[KNL] adding policy 10.2.10.121/32 === 10.2.10.122/32 out > 11:51:00 09[KNL] unable to add policy: File exists. (5017) When starter is terminated properly (e.g. via `ipsec stop`) the kernel state is flushed, but during a restart because of a crash that's not the case. Neither are routes or firewall rules removed that were added by the daemon or via updown script. The basic assumption is, of course, that the daemon should never crash. > I checked the KLIPS and Netlink versions and it looks like the > add_policy method is always supposed to update existing SPs in the > kernel. If it knows about the existing policies, they are updated. But in this case the restarted IKE daemon has no knowledge of them (it assumes full control over the kernel's IPsec stack and a clean slate). > With that in mind, would the fix for this problem be to handle EEXIST > in add_policy_internal by replacing Yes, that should work for this particular case. Not sure if there are situations where updating existing policies is unwanted (for the daemon this still looks like it added the policies, so it will eventually remove them). Anyway, I pushed changes for the kernel-pfkey and kernel-netlink plugins to the policy-update-eexist branch [1]. By the way, if auto=route is used the result might be a bit odd. Since the previously installed SAs and policies are still there no new SAs are established until the existing SAs expire. Soft expires will be triggered, for which the daemon does not find any state, so no rekeying is done. And only when the SAs have finally expired will the kernel send an acquire to the daemon (this assumes that the reqids are the same as they were before the restart, which should be the case since 5.3.0). Also, if the other peer has lower lifetimes it will try to rekey the CHILD_SA using an IKE_SA that does not exist on the restarted peer, so after a few retransmits it will eventually trigger its configured `dpdaction`. Regards, Tobias [1] https://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/policy-update-eexist _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
