[Openswan Users] rekey problem between openswan and strongswan

Fri Jan 30 09:21:57 EST 2015

Rescued from the Spam bucket.  Please remember to subscribe to the mailing list before posting to it.

From: "Ko, HsuenJu" <HsuenJu.Ko at stratus.com <mailto:HsuenJu.Ko at stratus.com>>
To: "'users at lists.openswan.org <mailto:users at lists.openswan.org>'" <users at lists.openswan.org <mailto:users at lists.openswan.org>>
Subject: rekey problem between openswan and strongswan
Date: January 30, 2015 at 9:04:14 AM GMT-5

Hi,
I experienced problem between strongswan and openswan involving rekey.  Strongswan side sent CREATE_CHILD_SA message and openswan side does not respond and here is the log from openswan side.  I found a thread from Oct, 2010 dev list with similar issue shown below.   I am using openswan 2.6.32.  Is it possible this is fixed in later release?

| *received 316 bytes from 134.111.75.175:500 on bond0 (port=500)
|   c0 69 8d 71  51 69 ae 11  84 f0 91 c5  c6 de 29 da
|   2e 20 24 00  00 00 00 00  00 00 01 3c  29 00 01 20
|   a4 8e 59 4b  86 a6 17 ce  ff 0e 5d 11  c5 88 b0 03
|   ec 2b c6 e7  a3 ba 07 12  6f 78 de f7  e9 92 d6 b0
|   22 26 99 fb  4f bb a7 25  9c bd 7c 9b  b2 ff e2 88
|   3f bf bd 88  ab 07 1d 4a  c8 58 45 42  ba 3a 56 7a
|   b3 74 19 9a  c2 73 c7 fb  b4 2e 9c 00  5c 68 41 bb
|   0b 71 ba e7  4d f6 aa 02  f4 bc b7 54  e3 bb 50 44
|   1f c0 a5 06  d2 bc aa d9  c7 91 5b 5a  0b ae 87 26
|   e7 d9 bc 64  da 66 c4 7e  a4 34 e2 a1  f7 ca a0 44
|   fb 7c 4a de  95 98 82 81  77 cf 3d 05  e3 c0 f9 30
|   eb be 0a 26  e7 91 01 d7  af fe d0 16  1e 39 40 0e
|   8d 7b a5 2d  0c c4 54 75  36 c7 98 3e  59 89 e2 e8
|   0d 50 28 30  ec e3 97 38  cd 3e 58 f3  af 21 90 86
|   18 2d 45 95  b8 31 3f b1  44 69 b9 98  0f 0f 7b dc
|   ea ae ec 50  d1 c9 bd d1  51 a9 ed aa  01 e1 93 04
|   a8 47 6f 20  4a 3a 79 c9  6f f1 cf 00  a1 59 a5 aa
|   78 ff e2 c6  09 e9 dd 54  2c 57 6b a4  61 39 92 cb
|   bb 7f 9b 21  12 95 df a6  1b 5a 62 76  54 f6 69 c8
|   e4 96 c1 1d  d1 25 02 9a  35 2f 66 79
| **parse ISAKMP Message:
|    initiator cookie:
|   c0 69 8d 71  51 69 ae 11
|    responder cookie:
|   84 f0 91 c5  c6 de 29 da
|    next payload type: ISAKMP_NEXT_v2E
|    ISAKMP version: IKEv2 version 2.0 (rfc4306)
|    exchange type: ISAKMP_v2_CHILD_SA
|    flags: none
|    message ID:  00 00 00 00
|    length: 316
|  processing version=2.0 packet with exchange type=ISAKMP_v2_CHILD_SA (36)
| I am IKE SA Initiator
| ICOOKIE:  c0 69 8d 71  51 69 ae 11
| RCOOKIE:  84 f0 91 c5  c6 de 29 da
| state hash entry 1
| v2 peer and cookies match on #1
| v2 state object #1 found, in STATE_PARENT_I3
| * processed 0 messages from cryptographic helpers
| next event EVENT_PENDING_DDNS in 47 seconds
| next event EVENT_PENDING_DDNS in 47 seconds

On Wed, 27 Oct 2010, Yatong Cui wrote:

> 1>First sorry that i forgot to change the phase 1 settings on the strongswan side from a previous test,should be "ike=3des-sha1-modp1024(not aes)", however the result is the same,the rekey is still not successful.

I am not sure if the "rekey" is the issue. It seems like this is the initial child_sa?

> (SCENARION D)======STRONGSWAN----->>-----OPENSWAN=========
>                   (shorter)             (longer)
> 
> After 'lifetime minus margintime(parameters on strongswan)',strongswan begins to send the 'CREATE_CHILD_SA' isakmp packets.
> 
> But there seems to be no respond from openswan side.

The relevant part of the log being:

Oct 27 07:36:44 OPENSWAN pluto[4474]: | **parse ISAKMP Message:
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    initiator cookie:
Oct 27 07:36:44 OPENSWAN pluto[4474]: |   ed 1f 17 d9  81 8f 37 92
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    responder cookie:
Oct 27 07:36:44 OPENSWAN pluto[4474]: |   16 d1 0c 4a  ac 5e c6 65
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    next payload type: ISAKMP_NEXT_v2E
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    ISAKMP version: IKEv2 version 2.0 (rfc4306)
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    exchange type: ISAKMP_v2_CHILD_SA
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    flags: ISAKMP_FLAG_INIT
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    message ID:  00 00 00 02
Oct 27 07:36:44 OPENSWAN pluto[4474]: |    length: 348
Oct 27 07:36:44 OPENSWAN pluto[4474]: |  processing version=2.0 packet with exchange type=ISAKMP_v2_CHILD_SA (36)
Oct 27 07:36:44 OPENSWAN pluto[4474]: | ICOOKIE:  ed 1f 17 d9  81 8f 37 92
Oct 27 07:36:44 OPENSWAN pluto[4474]: | RCOOKIE:  16 d1 0c 4a  ac 5e c6 65
Oct 27 07:36:44 OPENSWAN pluto[4474]: | state hash entry 23
Oct 27 07:36:44 OPENSWAN pluto[4474]: | v2 peer and cookies match on #1
Oct 27 07:36:44 OPENSWAN pluto[4474]: | v2 state object #1 found, in STATE_PARENT_R2
Oct 27 07:36:44 OPENSWAN pluto[4474]: packet from 2001:db8:1:2:20c:29ff:fe45:b04e:500: sending notification v2N_INVALID_MESSAGE_ID to 2001:db8:1:2:20c:29ff:fe45:b04e:500
Oct 27 07:36:44 OPENSWAN pluto[4474]: | don't send packet when notification data empty
Oct 27 07:36:44 OPENSWAN pluto[4474]: | * processed 0 messages from cryptographic helpers
Oct 27 07:36:44 OPENSWAN pluto[4474]: | next event EVENT_PENDING_DDNS in 31 seconds
Oct 27 07:36:44 OPENSWAN pluto[4474]: | next event EVENT_PENDING_DDNS in 31 seconds
Oct 27 07:36:50 OPENSWAN pluto[4474]: |

Can you check the RFC to see if the COOKIES of the parent_sa should be used for the child_sa?

Without having looked at the code, it seems we think these cookies belong to a parent_sa, and we
are not expecting a ISAKMP_v2_CHILD_SA packet with those cookies?

Paul
_______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20150130/3e5f457c/attachment-0001.html>