[strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0

[Tobias Brunner]

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