On Fri, Jul 31, 2015 at 7:35 PM, Ansis Atteka <[email protected]> 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? _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
