Hi Benoit, Hi Andreas, as Benoit already confirmed, this problem is related to using the kernel-pfkey plugin in combination with pluto. I tried to reproduce the behavior using Benoit's config and I was able to do so with the PF_KEY interface, but not with the Netlink interface. Some debugging showed that the problem is a limit set in ipsec.h and consequentially used in af_key in the kernel, which defines 0x3fff (16383) as the upper limit (IPSEC_MANUAL_REQID_MAX) for the reqids that can be specified by user-land tools. If the supplied reqid exceeds this value the kernel starts generating them itself. Subsequently, the installed policies don't match the installed SAs anymore (because there, the reqids are not changed). Hence, acquires are triggered for packets that match any installed policies. Now the fun part is that pluto actually bases its generated reqids on the above limit, so the first one generated is 14384 (followed by 14388, because an offset of 4 was required in the old kernel interface and I missed to changed that). Starting at IPSEC_MANUAL_REQID_MAX probably made sense in the early days, when people wanted to configure some SAs manually. And because charon starts generating reqids with 1 it also prevented any conflicts between the two daemons. But this difference between the two daemons also meant that I never came across this limitation of the kernel's PF_KEY interface while testing it with charon. In my opinion the check in the kernel is rather bogus, as it has no means to decide whether the SADB_X_SPDADD is sent by a keying daemon or a tool like setkey.
To fix this, I propose to modify pluto so that it generates reqids from the range [0x1fff, 0x3fff] (incrementing them by 1 instead of 4). This would avoid the problem with the PF_KEY interface and would still largely avoid conflicts with charon (at least as long as charon has fewer than 8191 connections). But then again, using the kernel-netlink plugin avoids this problem altogether, so there is probably no change needed at all. Regards, Tobias _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users