In one of my test runs I noticed interop-ikev2-strongswan-11-nat-initiator failed with road's strongSwan reporting:
+parsed IKE_SA_INIT response 0 [ N(NO_PROP) ] +received NO_PROPOSAL_CHOSEN notify error +establishing connection 'road-eastnet-ikev2' failed digging a little and it seems that east's pluto is consistently responding with, in sequence: - v2N_INVALID_KE_PAYLOAD (ok) - v2N_NO_PROPOSAL_CHOSEN (huh) For instance: | accepted IKE proposal ikev2_proposal: 3:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512;DH=MODP2048 | converting proposal to internal trans attrs | encryption ike_alg_lookup_by_id id: AES_GCM_C=20, found aes_gcm_16 | PRF ike_alg_lookup_by_id id: HMAC_SHA2_512=7, found sha2_512 packet from 192.1.2.254:500: initiator guessed wrong keying material group (CURVE25519); responding with INVALID_KE_PAYLOAD requesting MODP2048 | sending INVALID_KE back with MODP2048(14) packet from 192.1.2.254:500: sending unencrypted notification v2N_INVALID_KE_PAYLOAD to 192.1.2.254:500 | **emit ISAKMP Message: | initiator cookie: | 13 87 4a 1b 56 bd 74 ad | responder cookie: | 00 00 00 00 00 00 00 00 | next payload type: ISAKMP_NEXT_v2N (0x29) | ISAKMP version: IKEv2 version 2.0 (rfc4306/rfc5996) (0x20) | exchange type: ISAKMP_v2_SA_INIT (0x22) | flags: ISAKMP_FLAG_v2_MSG_RESPONSE (0x20) | message ID: 00 00 00 00 | Adding a v2N Payload | ***emit IKEv2 Notify Payload: | next payload type: ISAKMP_NEXT_v2NONE (0x0) | flags: none (0x0) | Protocol ID: PROTO_v2_RESERVED (0x0) | SPI size: 0 (0x0) | Notify Message Type: v2N_INVALID_KE_PAYLOAD (0x11) | emitting 2 raw bytes of Notify data into IKEv2 Notify Payload | Notify data 00 0e | emitting length of IKEv2 Notify Payload: 10 | padding IKEv1 message with 2 bytes | emitting 2 zero bytes of message padding into ISAKMP Message | emitting length of ISAKMP Message: 40 | sending 40 bytes for v2 notify through eth1:500 to 192.1.2.254:500 (using #0) | 13 87 4a 1b 56 bd 74 ad 00 00 00 00 00 00 00 00 | 29 20 22 20 00 00 00 00 00 00 00 28 00 00 00 0a | 00 00 00 11 00 0e 00 00 | #0 complete v2 state transition from STATE_UNDEFINED with v2N_NO_PROPOSAL_CHOSEN | sending a notification reply packet from 192.1.2.254:500: sending unencrypted notification v2N_NO_PROPOSAL_CHOSEN to 192.1.2.254:500 | **emit ISAKMP Message: | initiator cookie: | 13 87 4a 1b 56 bd 74 ad | responder cookie: | 00 00 00 00 00 00 00 00 | next payload type: ISAKMP_NEXT_v2N (0x29) | ISAKMP version: IKEv2 version 2.0 (rfc4306/rfc5996) (0x20) | exchange type: ISAKMP_v2_SA_INIT (0x22) | flags: ISAKMP_FLAG_v2_MSG_RESPONSE (0x20) | message ID: 00 00 00 00 | Adding a v2N Payload | ***emit IKEv2 Notify Payload: | next payload type: ISAKMP_NEXT_v2NONE (0x0) | flags: none (0x0) | Protocol ID: PROTO_v2_RESERVED (0x0) | SPI size: 0 (0x0) | Notify Message Type: v2N_NO_PROPOSAL_CHOSEN (0xe) | emitting length of IKEv2 Notify Payload: 8 | no IKEv1 message padding required | emitting length of ISAKMP Message: 36 | sending 36 bytes for v2 notify through eth1:500 to 192.1.2.254:500 (using #0) | 13 87 4a 1b 56 bd 74 ad 00 00 00 00 00 00 00 00 | 29 20 22 20 00 00 00 00 00 00 00 24 00 00 00 08 | 00 00 00 0e | state transition function for STATE_UNDEFINED failed: v2N_NO_PROPOSAL_CHOSEN it seems to be related to c4c2c62a Andrew PS: the log http://testing.libreswan.org/results/v3.20-709-g8de1339-master/interop-ikev2-strongswan-11-nat-initiator/OUTPUT/east.pluto.log.bz2 shows the behaviour; look for INVALID_KE _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
