[strongSwan] Multiple Child_SAs are causing traffic drop

[Martin Willi]

Hi Joern,

> After re-establishing the connection it seems that both peers will
> initiate a tunnel and as a result I will have two Child_SA pairs. 

> Strongwan is using  0xf9029d40 while Checkpoint is using 0xc2088c97.

>     vpn-57-9{454}:  INSTALLED, TUNNEL, ESP SPIs: c3a797a1_i f9029d40_o
>     vpn-57-9{454}:  AES_CBC_128/HMAC_SHA1_96, 4568 bytes_i (54 pkts, 93s ago), 11716 bytes_o (99 pkts, 1s ago), rekeying in 3 minutes
>     vpn-57-9{454}:   10.57.11.9/32 === 10.22.11.9/32
>     vpn-57-9{338}:  INSTALLED, TUNNEL, ESP SPIs: c2088c97_i de446e40_o
>     vpn-57-9{338}:  AES_CBC_128/HMAC_SHA1_96, 4148 bytes_i (46 pkts, 1s ago), 0 bytes_o, rekeying in 5 minutes
>     vpn-57-9{338}:   10.57.11.9/32 === 10.22.11.9/32
> 
> Based on the rekeying information (3min vs. 5min) I would say that
> strongswan is using the older SA while Checkpoint is using the newer
> one.

As reqids are assigned incrementally, the SA with the higher reqid is
newer (rekey times are randomized using rekeyfuzz). This means that
strongSwan is using the newer SA {454}, while Checkpoint is still using
the old one {338}.

> why is strongswan dropping the packets encrypted with the newer (but
> valid) SPI?

The problem is that you can't have two equal IPsec policies in Linux,
even if the reqids differs. This means that strongSwan can install the
policy for the newest CHILD_SA only. While the old IPsec SAs are still
in place, they won't have a reqid that we have a valid policy for. Hence
a packet on the old SA won't get through.

With 5.1.0 we now reject the installation of a policy if we already have
one installed with the same selectors, but different reqids. This will
make CHILD_SA negotiation fail, and you should only ever have one
CHILD_SA for the same selectors (but different reqids).

I don't know how well this works with Checkpoint if the CHILD_SA gets
rejected, but I'd give it a try.

Regards
Martin