Hi Richard, > I am using version 4.1.10 of strongswan
> 04[KNL] creating rekey job for ESP CHILD_SA 0xc450608a (reqid 11) > 04[KNL] creating delete job for ESP CHILD_SA 0xc6f71609 (reqid 11) > 04[KNL] creating delete job for ESP CHILD_SA 0xc450608a (reqid 11) > 16[KNL] unable to delete SAD entry with SPI 0x8a6050c4 > 16[KNL] unable to delete SAD entry with SPI 0x916f7c6 Your ancient strongSwan version reports the SPIs in the delete error in host instead of network order, so the SPIs are actually c450608a and c6f71609. The problem is that the kernel triggers a rekey for the SA, and short after enforces a delete for them. But in this short time-frame, the daemon is unable to complete the rekey. Additionally, the remote peer seems to initiate the rekeying at same time. You should review your rekeying configuration: Make sure to have a large enough rekeymargin, this allows the daemon to reestablish a new SA before the kernel deletes the old SA. Increasing rekeyfuzz helps to avoid these rekey collisions. man ipsec.conf for details. And I (again) recommend to use a newer strongSwan version; the handling of rekey collisions has improved a lot. Regards Martin _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
