[strongSwan] Flapping tunnel and hundreds or queued QUICK_MODE tasks

[Eric Germann]

Hello all,

I’ve got a Strongswan 5.3.5 installation compiled from source installed on Centos 6.7 box connecting to a Cisco ASA which exhibits the following behavior.

On start it runs fine for an indeterminate period of time, then the tunnels begin to flap up and down.  Time could be several days to several weeks.

When running an ‘ipsec statusall’ it shows (truncated to remove tunnel configs):


Status of IKE charon daemon (strongSwan 5.3.5, Linux 2.6.32-573.8.1.el6.x86_64, x86_64):
  uptime: 4 days, since Dec 02 21:19:31 2015
  malloc: sbrk 913408, mmap 0, used 545392, free 368016
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 340
  loaded plugins: charon aesni aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt f
ips-prf gmp xcbc cmac hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown xauth-generic
Listening IP addresses:
  100.93.64.90

Security Associations (1 up, 0 connecting):
xxx-yyy-zzz-10-228-0-0-16[2621]: ESTABLISHED 29 seconds ago, 100.93.64.90[52.89.229.66]...166.108.248.1[166.108.248.1]
xxx-yyy-zzz-10-228-0-0-16[2621]: IKEv1 SPIs: 88c593b6b7148d7d_i* c11b33192527a0f2_r, pre-shared key reauthentication in 7 hours
xxx-yyy-zzz-10-228-0-0-16[2621]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
xxx-yyy-zzz-10-228-0-0-16[2621]: Tasks queued: QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MOD
E QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE Q
UICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUIC
K_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_M
ODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE
 QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QU
ICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK
_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MO
DE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE
QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUI
CK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_
MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MOD
E QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE Q
UICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUIC
K_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_M
ODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE …
xxx-yyy-zzz-10-228-0-0-16[2621]: Tasks active: QUICK_MODE
xxx-yyy-zzz-10-228-0-0-16[2621]: Tasks passive: QUICK_MODE QUICK_MODE QUICK_MODE


We updated to 5.3.5 hoping we’d fix this because when it’s showing this, we see in the logs

Dec  7 18:24:39 ip-100-93-64-90 charon: 07[ENC] invalid HASH_V1 payload length, decryption failed?
Dec  7 18:24:39 ip-100-93-64-90 charon: 07[ENC] could not decrypt payloads
Dec  7 18:24:39 ip-100-93-64-90 charon: 07[IKE] message parsing failed
Dec  7 18:24:39 ip-100-93-64-90 charon: 07[ENC] generating INFORMATIONAL_V1 request 2524142361 [ HASH N(PLD_MAL) ]


It looked like the below resolved fix would resolve it, but I seem to be missing a piece.

https://wiki.strongswan.org/issues/1120 <https://wiki.strongswan.org/issues/1120>

Restarting ipsec doesn’t seem to fix it, only a reboot of the machine at this point, leading me to a resource exhaustion thought.

Any thoughts on what we can do to stabilize the tunnel?


Thanks

EKG






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20151207/f1ae4581/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4030 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20151207/f1ae4581/attachment-0001.bin>