[Openswan Users] Problems with openswan-1.0.6 aggressive mode!?

Tsukasa Kanazawa kanazawa.t at rapid.ocn.ne.jp
Fri Jul 16 15:39:36 CEST 2004


I tried connection by agg-mode between (openswan-1.0.6) and (super-freeswan -1.99.8).
The following error messages are outputted by responder.

 "road3"[6] 200.168.102.5 #11: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
 "road3"[6] 200.168.102.5 #11: Aggressive mode peer ID is ID_USER_FQDN: 'xxx at yy.zz.com'
 "road3"[6] 200.168.102.5 #11: complete_state_transition : st->st_connection->sa_ike_life_seconds =3600
 "road3"[6] 200.168.102.5 #11: complete_state_transition : st->st_oakley.life_seconds =3600
 "road3"[6] 200.168.102.5 #11: complete_state_transition : marg =270
 "road3"[6] 200.168.102.5 #11: ISAKMP SA established
 "road3"[6] 200.168.102.5 #11: next payload type of ISAKMP Hash Payload has an unknown value: 127
 "road3"[6] 200.168.102.5 #11: malformed payload in packet
 "road3"[6] 200.168.102.5 #11: sending encrypted notification PAYLOAD_MALFORMED to 200.168.102.5:500

The debugging mode log output of initiater is below.

Jul 14 17:20:01 ue3 pluto[23299]: | HASH(1) computed:
Jul 14 17:20:01 ue3 pluto[23299]: |   63 77 b2 39  90 df 76 e8  01 14 89 eb  b8 eb cf d7
Jul 14 17:20:01 ue3 pluto[23299]: |   1b 79 2e eb
Jul 14 17:20:01 ue3 pluto[23299]: | last Phase 1 IV:
Jul 14 17:20:01 ue3 pluto[23299]: | computed Phase 2 IV:
Jul 14 17:20:01 ue3 pluto[23299]: |   df 4a 99 1a  98 9b 34 a5  23 3e a5 e4  eb af d6 17
Jul 14 17:20:01 ue3 pluto[23299]: |   55 3d 30 df
Jul 14 17:20:01 ue3 pluto[23299]: | encrypting:
Jul 14 17:20:01 ue3 pluto[23299]: |   01 00 00 18  63 77 b2 39  90 df 76 e8  01 14 89 eb
Jul 14 17:20:01 ue3 pluto[23299]: |   b8 eb cf d7  1b 79 2e eb  0a 00 00 50  00 00 00 01
Jul 14 17:20:01 ue3 pluto[23299]: |   00 00 00 01  00 00 00 44  00 03 04 02  c6 45 f8 d5
Jul 14 17:20:01 ue3 pluto[23299]: |   03 00 00 1c  00 03 00 00  80 03 00 02  80 04 f0 03
Jul 14 17:20:01 ue3 pluto[23299]: |   80 01 00 01  80 02 70 80  80 05 00 01  00 00 00 1c
Jul 14 17:20:01 ue3 pluto[23299]: |   01 03 00 00  80 03 00 02  80 04 f0 03  80 01 00 01
Jul 14 17:20:01 ue3 pluto[23299]: |   80 02 70 80  80 05 00 02  04 00 00 14  aa 3a b7 97
Jul 14 17:20:01 ue3 pluto[23299]: |   66 80 30 66  c3 b0 03 fb  6c 7b 98 94  05 00 00 84
Jul 14 17:20:01 ue3 pluto[23299]: |   b3 28 4f ff  a3 fd 5f 81  b9 9b 3c d7  6c 6d e2 a1
Jul 14 17:20:01 ue3 pluto[23299]: |   e7 8f 94 99  a0 b1 a3 70  da 16 74 de  dc 91 95 49
Jul 14 17:20:01 ue3 pluto[23299]: |   b5 6d 7d 43  a4 cb eb 16  38 f2 bd 53  13 2d 18 c7
Jul 14 17:20:01 ue3 pluto[23299]: |   f9 5e 54 04  89 fa d5 a2  08 b3 64 10  00 89 bc 7a
Jul 14 17:20:01 ue3 pluto[23299]: |   c6 9d 07 52  35 19 e8 85  b9 b9 a5 fe  65 d1 b0 05
Jul 14 17:20:01 ue3 pluto[23299]: |   f6 aa 7d c1  e7 24 ae a5  80 40 de 70  af 3b 17 db
Jul 14 17:20:01 ue3 pluto[23299]: |   8b 9f a0 e8  58 d5 9d a9  a8 ba cc 45  2e 78 4a 50
Jul 14 17:20:01 ue3 pluto[23299]: |   5e 82 db a2  ed b6 cd f6  03 9e 77 bd  94 fa 73 44
Jul 14 17:20:01 ue3 pluto[23299]: |   05 00 00 10  04 00 00 00  c0 a8 65 0d  ff ff ff ff
Jul 14 17:20:01 ue3 pluto[23299]: |   00 00 00 10  04 00 00 00  c8 a8 67 02  ff ff ff ff
Jul 14 17:20:01 ue3 pluto[23299]: | encrypting using OAKLEY_3DES_CBC
Jul 14 17:20:01 ue3 pluto[23299]: | next IV:  65 ed 2f 2c  3d 6a dc 32
Jul 14 17:20:01 ue3 pluto[23299]: | emitting length of ISAKMP Message: 316
Jul 14 17:20:01 ue3 pluto[23299]: | sending 316 bytes for quick_outI1 through eth0 to 200.168.103.2:4500:
Jul 14 17:20:01 ue3 pluto[23299]: |   c6 97 55 72  52 a7 31 5b  a1 a8 e1 6a  43 1b e9 a2
Jul 14 17:20:01 ue3 pluto[23299]: |   08 10 20 01  e3 3f d7 ec  00 00 01 3c  0e 93 68 02
Jul 14 17:20:01 ue3 pluto[23299]: |   c8 23 fc 55  c8 54 dc 5d  0d d2 b2 70  a7 2a b5 a3
Jul 14 17:20:01 ue3 pluto[23299]: |   a0 f2 38 81  82 92 3f 4d  bb 57 e4 58  e1 fb 26 d4
Jul 14 17:20:01 ue3 pluto[23299]: |   a8 d9 a3 cc  6f 96 9c 6a  d6 71 17 29  c4 92 86 d7
Jul 14 17:20:01 ue3 pluto[23299]: |   5e 04 d0 8e  12 24 84 8b  21 44 cb b9  98 30 6d a9
Jul 14 17:20:01 ue3 pluto[23299]: |   7c a0 2b a1  9f 5d cf f6  39 56 43 48  ff de d8 04
Jul 14 17:20:01 ue3 pluto[23299]: |   90 8a 40 e3  23 35 9c 85  7e 16 b2 cd  42 30 7c 65
Jul 14 17:20:01 ue3 pluto[23299]: |   75 85 91 08  9b a8 1b 71  b1 e9 b1 9c  9c b5 8c 49
Jul 14 17:20:01 ue3 pluto[23299]: |   f0 d7 7e b5  11 62 d3 17  b7 33 81 06  d6 45 92 e9
Jul 14 17:20:01 ue3 pluto[23299]: |   1e 5c a0 de  7b 10 17 f8  72 95 e4 77  8e 08 94 7a
Jul 14 17:20:01 ue3 pluto[23299]: |   99 74 bd 71  d8 d4 1e a5  82 fc ad 01  98 98 2c d7
Jul 14 17:20:01 ue3 pluto[23299]: |   3e 29 be 76  6d e7 35 1b  76 a2 72 0a  aa 49 40 d9
Jul 14 17:20:01 ue3 pluto[23299]: |   ff c5 e4 c1  69 68 48 d9  f5 11 d3 9e  11 8f 2e c5
Jul 14 17:20:01 ue3 pluto[23299]: |   e5 76 0d 67  df 1d a7 b2  98 3a 6b 2d  06 84 a6 67
Jul 14 17:20:01 ue3 pluto[23299]: |   25 80 e4 ac  3c c4 79 40  7c 59 a2 0d  e3 d9 24 5c
Jul 14 17:20:01 ue3 pluto[23299]: |   d7 2a 9a d2  3c 35 0d 47  81 30 de 76  19 13 df 45
Jul 14 17:20:01 ue3 pluto[23299]: |   48 c3 88 08  da 88 3a 74  35 45 15 c4  a1 a3 6a d1
Jul 14 17:20:01 ue3 pluto[23299]: |   85 eb b4 e8  f5 9d ca f9  40 89 31 5d  b3 be 82 0b
Jul 14 17:20:01 ue3 pluto[23299]: |   35 0f 64 17  65 ed 2f 2c  3d 6a dc 32
Jul 14 17:20:01 ue3 pluto[23299]: | inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #11
Jul 14 17:20:01 ue3 pluto[23299]: | next event EVENT_NAT_T_KEEPALIVE in 7 seconds

The value is not contained in last Phase 1 IV:!?

I analyzed the source code and discovered the small bug.
Although it is changed in main-mode so that (last-phase1-IV) may be stored in (st->st_phase1_iv), 
it is not performed in aggressive-mode.

I applied following patch to ipsec_doi.c.

--- ipsec_doi.c.orig	2004-04-04 01:48:10.000000000 +0900
+++ ipsec_doi.c	2004-07-16 11:07:12.000000000 +0900
@@ -2057,13 +2057,13 @@
     union hash_ctx ctx;
 
     DBG_cond_dump(DBG_CRYPT, "last Phase 1 IV:"
-	, st->st_ph1_iv, st->st_ph1_iv_len);
+	, st->st_iv, st->st_iv_len);
 
     st->st_new_iv_len = h->hash_digest_size;
     passert(st->st_new_iv_len <= sizeof(st->st_new_iv));
 
     h->hash_init(&ctx);
-    h->hash_update(&ctx, st->st_ph1_iv, st->st_ph1_iv_len);
+    h->hash_update(&ctx, st->st_iv, st->st_iv_len);
     passert(*msgid != 0);
     h->hash_update(&ctx, (const u_char *)msgid, sizeof(*msgid));
     h->hash_final(st->st_new_iv, &ctx);





More information about the Users mailing list