[strongSwan] tunnels not coming up after rekey

Yogesh Purohit yogeshpurohit2 at gmail.com
Fri Jun 5 09:49:59 CEST 2020


Hi,

I have a setup where I am using the ikev1 version. i am using strongswan
version : strongswan-5.5.2

I am seeing some unusual logs from charon. Attaching the snippet below:

 charon[]:  received packet: from 10.109.229.222[500] to 10.109.229.221[500]
 charon[]:  parsing header of message
 charon[]:  parsing HEADER payload, 428 bytes left
 charon[]:    parsing rule 0 IKE_SPI
 charon[]:    parsing rule 1 IKE_SPI
 charon[]:    parsing rule 2 U_INT_8
 charon[]:    parsing rule 3 U_INT_4
 charon[]:    parsing rule 4 U_INT_4
 charon[]:    parsing rule 5 U_INT_8
 charon[]:    parsing rule 6 RESERVED_BIT
 charon[]:    parsing rule 7 RESERVED_BIT
 charon[]:    parsing rule 8 FLAG
 charon[]:    parsing rule 9 FLAG
 charon[]:    parsing rule 10 FLAG
 charon[]:    parsing rule 11 FLAG
 charon[]:    parsing rule 12 FLAG
 charon[]:    parsing rule 13 FLAG
 charon[]:    parsing rule 14 U_INT_32
 charon[]:    parsing rule 15 HEADER_LENGTH
 charon[]:  parsing HEADER payload finished
 charon[]:  parsed a QUICK_MODE message header
 charon[]:  waiting for data on sockets
 charon[]:  checkout IKEv1 SA by message with SPIs 59de61f4757f1928_i
43ec5a0590398519_r
 *charon[]:  Received an alert which is not handled.*
 charon[]:

* charon[]:  IKE_SA checkout not successful*

At times receive these logs:

charon[]: <10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367>
received unknown vendor ID:
69:93:69:22:87:41:c6:d4:ca:09:4c:93:e2:42:c9:de:19:e7:b7:c6:00:00:00:05:00:00:05:00
 charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367> selecting
proposal:
 charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367>
proposal matches
 charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367> received
proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
 charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367>
configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
 charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367> selected
proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
 *charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367> Received
an alert which is not handled.*
 *charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367>
reinitiating already active tasks*
 charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367>
ISAKMP_VENDOR task
 charon[]:
<10.109.229.221_142.90.21.0/24-10.109.229.222_192.168.4.0/22|367>
MAIN_MODE task

Here in above case what is triggering charon to reinitiate the already
active task and does it mean it stops handling already active task for
tunnel creation.
These logs occur repetitively while parsing the received packet.
I am not sure what these logs mean, why they are coming and because of this
rekey process is not getting completed hence resulting in tunnels to be
down.

To complete the process I have to manually restart the service by
stop/start. During initial tunnel establishment I do not see these logs and
tunnel comes up and works fine till rekey. This is peculiar behavior.

I tried to look through the strongswan code to see what is triggering this
lert which isn't handled. But I could not find it.

Please let me know what is causing these logs and what does it mean which
is why tunnel is not getting up ?




-- 
Best Regards,

Yogesh Purohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200605/79277553/attachment.html>


More information about the Users mailing list