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?
Best regards,
Ansis Atteka
policies_148
Description: Binary data
state_148
Description: Binary data
statusall_148
Description: Binary data
policies_149
Description: Binary data
statusall_149
Description: Binary data
state_149
Description: Binary data
spoofer_on_148
Description: Binary data
spoofer_on_149
Description: Binary data
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
