[strongSwan-dev] StrongSwan negotiated two pairs of IPsec SAs that lead to occasional connectivity issue

[Ansis Atteka]

On Fri, Jul 31, 2015 at 7:35 PM, Ansis Atteka <aatteka at nicira.com> wrote:
> We are seeing occasional connectivity issues caused by IPsec (either
> by Linux Kernel IPsec stack or StrongSwan). At the time of seeing this
> connectivity issue I captured output of:
> 1) ip -s xfrm state
> 2) ip -s xfrm policy
> 3) ipsec statusall
>
> Raw output of those commands is in the attachment (host .148 and
> .149). After looking into the 'ip xfrm" output I decided to create a
> shell script that would manually restore Linux Kernel IPsec
> configuration to the same state that strongSwan pushed to it. This way
> I was able to reproduce this bug 100% of the time (see scripts
> spoofer_on_148 and spoofer_on_149 that restore XFRM state in the Linux
> kernel to what strongSwan pushed).
>
> Basically the sympthoms of this bug are:
> 1) It goes away on IKE_SA rekey
> 2) And for one IPsec SA bytes_o remains set to 0 while for the other
> SA bytes_i remains set to 0 (like if both SAs are being partially
> used):
> 192.168.2.149{1}:  AES_CBC_128/HMAC_SHA1_96, *0 bytes_i*, 12871
> bytes_o (111 pkts, 34s ago), rekeying in 33 minutes
> 192.168.2.149{4}:  AES_CBC_128/HMAC_SHA1_96, 45023 bytes_i (724 pkts,
> 0s ago), *0 bytes_o*, rekeying in 35 minutes
>
> Is this a known issue?


After looking closer into the ip-xfrm policy and state dumps that are
in the attachment, I have come to conclusion that this is a strongSwan
bug.

It looks like strongSwan incorrectly set reqid in IPsec policy. Either
strongSwan should have:
1) on 192.168.2.148 installed IPsec policty with reqid=4 instead of reqid=1; OR
2) on 192.168.2.149 installed IPsec policy with reqid=5 instead of reqid=4.

Since, my understanding is that reqid does not show up at IKEv2 wire
protocol level, then is this connectivity bug a result of race
condition where both sides tried to rekey at the same time?