Re: IKEv2 Site-to-Site VPN between Cisco ASA and Juniper

veonwu0702 · ‎12-10-2013

Hi ,

I am trying to setup the IKEv2 site-to-site vpn tunnel between Cisco ASA (9.1 ) and Juniper SSG.

But I was not able to make it up. Both sides are using the following configuration.

Phase1 : encrytion: ase256 , DH: group2 , integrity hash : sha-256, PRF: sha

Phase2: encrytion: ase256, pfs: group2 , integrity hash : sha-256

The "debug crypto ikev2 protocol 127" and "debug crypto ikev2 platform 127" output is as below.

Decrypted packet:Data: 248 bytes

IKEv2-PROTO-1: The transform attribute is invalid

IKEv2-PROTO-1: Failed to parse the packet

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=788D49FE370EDEAE R_SPI=5AE3346E6298D495 (R) MsgID = 00000000 CurState: IDLE Event: EV_DELETE

IKEv2-PROTO-5: Action: Action_Null

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=788D49FE370EDEAE R_SPI=5AE3346E6298D495 (R) MsgID = 00000000 CurState: EXIT Event: EV_ABORT

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=788D49FE370EDEAE R_SPI=5AE3346E6298D495 (R) MsgID = 00000000 CurState: EXIT Event: EV_CHK_PENDING_ABORT

IKEv2-PLAT-5: Negotiating SA request deleted

IKEv2-PLAT-1: Failed to decrement count for incoming negotiating

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=788D49FE370EDEAE R_SPI=5AE3346E6298D495 (R) MsgID = 00000000 CurState: EXIT Event: EV_UPDATE_CAC_STATS

IKEv2-PLAT-5: INVALID PSH HANDLE

IKEv2-PROTO-3: Abort exchange

IKEv2-PLAT-1: Invalid Parameters to create MIB fail entry.

IKEv2-PROTO-2: Deleting SA

IKEv2-PLAT-5: INVALID PSH HANDLE

anyone can advise ?

Thanks

m.kafka · ‎12-10-2013

I assume the Juniper is the initiator in this case.

The second line "The transform attribute is invalid" might be the solution for your issue, can you get a level 255 output? This should give you the actual attributes of the SA negotiation in raw-output.

Maybe there are some differences in RFC interpretation between Juniper and Cisco ASA about which attributes to use or how to name them in the config. It could be different modes of the cryptographic function (I assume AES in your case) or it could be that Juniper is trying to negotiate proprietary attributes.

Best thing might be to catch a level 255 debug and contact Cisco Support if you can't identify any issues yourself.

Rgds,

MiKa

Addendum: You could try to select a "fool proof" setting on both sides (one of the RFC recommended crypto suites), using as little options as possible, e.g. no PFS or anything like that. Also try a stronger DH, group2 is not adequate for strong encryption.

veonwu0702 · ‎12-10-2013

thanks m.kafka.

we don't have Juniper's access and they don't allow any change on their side.

below is level 255 debug, I cant see any issue shown.

IKEv2 Recv RAW packet dump

4a 16 ab c7 a9 9a e9 4d 00 00 00 00 00 00 00 00 | J......M........

21 20 22 08 00 00 00 00 00 00 00 f8 22 00 00 30 | ! "........."..0

00 00 00 2c 01 01 00 04 03 00 00 0c 01 00 00 0c | ...,............

1d 00 01 00 03 00 00 08 02 00 00 05 03 00 00 08 | ................

03 00 00 0c 00 00 00 08 04 00 00 02 28 00 00 88 | ............(...

00 02 00 00 06 39 f5 93 13 6c f5 a0 30 82 11 c7 | .....9...l..0...

89 cf 62 cd 4f ba ae c4 8b 17 b2 85 fa 63 88 32 | ..b.O........c.2

f1 3f a6 b2 bd 57 d6 19 72 f0 6c c7 ff c7 33 09 | .?...W..r.l...3.

2e 58 eb b5 1d a0 de 5d 7e 99 36 98 3a f6 f7 16 | .X.....]~.6.:...

b6 2c f8 71 c2 86 a5 50 23 b7 f8 55 9b bd 8f 48 | .,.q...P#..U...H

36 46 23 ee f1 8e 6e 50 36 de 3b 1b 50 20 bf 3a | 6F#...nP6.;.P .:

3b 1c 07 2c 30 64 4b fc 37 57 d6 f2 7a 73 2c 82 | ;..,0dK.7W..zs,.

90 fe a3 1c da 11 b5 c6 98 17 7d c3 8e 7a 2d ca | ..........}..z-.

6e e7 e1 4d 00 00 00 24 36 59 f2 a7 7f 75 04 d9 | n..M...$6Y..u..

1a a1 6b a5 0e c9 db ff 44 22 87 a1 9c 8b b9 fc | ..k.....D"......

65 f7 02 4c b9 7a 77 c7 | e..L.zw.

IKEv2-PLAT-4: RECV PKT [IKE_SA_INIT] [58.x.x.x]:500->[164.x.x.x]:500 InitSPI=0x4a16abc7a99ae94d RespSPI=0x0000000000000000 MID=00000000

IKEv2-PROTO-3: Rx [L 164.78.252.43:500/R 58.145.201.73:500/VRF i0:f0] m_id: 0x0

IKEv2-PROTO-3: HDR[i:4A16ABC7A99AE94D - r: 0000000000000000]

IKEv2-PROTO-4: IKEV2 HDR ispi: 4A16ABC7A99AE94D - rspi: 0000000000000000

IKEv2-PROTO-4: Next payload: SA, version: 2.0

IKEv2-PROTO-4: Exchange type: IKE_SA_INIT, flags: INITIATOR

IKEv2-PROTO-4: Message id: 0x0, length: 248

Decrypted packet:Data: 248 bytes

IKEv2-PROTO-1: The transform attribute is invalid

IKEv2-PROTO-1: Failed to parse the packet

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=4A16ABC7A99AE94D R_SPI=0C2CA4EEDB65EB0B (R) MsgID = 00000000 CurState: IDLE Event: EV_DELETE

IKEv2-PROTO-5: Action: Action_Null

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=4A16ABC7A99AE94D R_SPI=0C2CA4EEDB65EB0B (R) MsgID = 00000000 CurState: EXIT Event: EV_ABORT

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=4A16ABC7A99AE94D R_SPI=0C2CA4EEDB65EB0B (R) MsgID = 00000000 CurState: EXIT Event: EV_CHK_PENDING_ABORT

IKEv2-PLAT-5: Negotiating SA request deleted

IKEv2-PLAT-1: Failed to decrement count for incoming negotiating

IKEv2-PROTO-5: SM Trace-> SA: I_SPI=4A16ABC7A99AE94D R_SPI=0C2CA4EEDB65EB0B (R) MsgID = 00000000 CurState: EXIT Event: EV_UPDATE_CAC_STATS

IKEv2-PLAT-5: INVALID PSH HANDLE

IKEv2-PROTO-3: Abort exchange

IKEv2-PLAT-1: Invalid Parameters to create MIB fail entry.

IKEv2-PROTO-2: Deleting SA

IKEv2-PLAT-5: INVALID PSH HANDLE

m.kafka · ‎12-10-2013

Oh wow, that was quick

I'm afraid I can't dissect/decode an IPsec IKEv2 SA INIT in HEX, maybe you can capture the SA_INIT and load it with wireshark, they have quite detailed dissectors... Or you could BASE64 encode the captured SA_INIT and post it here, I will have a look at it when I have time, maybe tomorrow.

Filters for the paket capture: srcIP: Juniper, dstIP ASA, UDP:500

Rgds,

MiKa

Addendum: you "sanitized" src/dst in one place of the debug but left them unchanged in other places....

Addendum: I can see easily the "header length 248" in the hex-block "f8" and somewhere after that point lies the culprit but it's too difficult (although possible) to decode the rest in HEX...

m.kafka · ‎12-10-2013

OK I got bored and I don't watch TV:

According to RFC5996 (IKEv2) page 84:

(see also here:

http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-4)

The attribute type for proposal 1, transform 1 (AES-CBC) is malformed, you can find it on the 4th line of the raw packet dump with a value of hex "1d".

The only allowed attribute type is key length and MUST be 14 (0xE in Hex) but is set to 0x1d

The attribute value, key length, is coded correctly to 256 bits, but this won't help you I'm afraid...

The other transforms are coded correctly BTW

My recommendation: send the debug output and my suggestion to Juniper, if they don't trust a cisco debug also send them a packet dump e.g. from wireshark.

Good night,

MiKa

PS: why do you use DH group2 (quite weak) if all the other transforms are strong?

Addendum: try to configure a fixed key-length algo like 3DES to test whether it's really just the variable key length coding which is broken on the Juniper, from the security strangth it shouldn't make a difference as DH group2 is weaker than AES256.

Message was edited by: Michael Kafka

veonwu0702 · ‎12-11-2013

Hi Mika,

Really appreciate your help.

To make the ikev2 tunnel up , the encrytion need to be changed to AES or other method ?

For the reason we are using DH group 2 , it's because the configuration in Junipor end has been fixed without any change allowed.

Reards,

Veon

m.kafka · ‎12-11-2013

Hi

If you can't change the configuration of the Juniper you have no chance to connect.

The Juniper is the initiator and offers whatever is configured there.

To make the ikev2 tunnel up , the encrytion need to be changed to AES or other method ?

It already is AES.

I said other algo, e.g. 3DES

But if you can't change the config of the Juniper it will not work.

Rgds,

MiKa