Hello, No idea on this question? To sum up the potential problems: - strongSwan does not expect the kernel to destroy a SA, and produces errors after that (it cannot find the expected SA in the kernel since it has been deleted) - racoon uses the "delete" event from the kernel and creates a ISAKMP DELETE message to the remote host, with the relevant SPI. In some situations, both endpoints negotiate a pair of SA at the same time, and keep deleting their old SA and renegotiate. I suspect this behavior to be related to this sysctl.
What do you think? Emeric ----- Mail original ----- De: "Emeric POUPON" <emeric.pou...@stormshield.eu> À: "FreeBSD Net" <freebsd-net@freebsd.org> Envoyé: Lundi 17 Août 2015 10:07:45 Objet: IPsec: question on the sysctl preferred_oldsa Hello, I have some questions about the sysctl "net.key.preferred_oldsa": https://svnweb.freebsd.org/base/head/sys/netipsec/key.c?view=markup#l971 When I set the net.key.preferred_oldsa to 0 (similar to Linux's behavior, according to what I have read so far): - why does the kernel delete itself the old SA ? Why not just selecting the newest one? - why does it delete the old SA only if it has been created in another "second" of time? strongSwan does not expect that behavior and I can see a lot of errors in its logs: the SA has been deleted but it does not know about that (strongSwan wants to control the SA installation/deletion itself). Two pairs of SA may be negotiated and installed at the same time due to high load, bidirectional traffic. It seems to be quite questionable to delete the old one in that case. What do you think? Emeric _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"