Cisco Cisco AnyConnect Secure Mobility Client v2.x Guia De Resolução De Problemas
type: 2, reserved: 0x0, id: SHA256
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA1
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA512
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA384
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA256
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_1024_MODP/Group 2
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_521_ECP/Group 21
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_384_ECP/Group 20
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_256_ECP/Group 19
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP_256_PRIME/Group 24
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP/Group 14
last transform: 0x0, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_1536_MODP/Group 5
KE Next payload: N, reserved: 0x0, length: 136
DH group: 2, Reserved: 0x0
fc c9 90 2b 15 35 31 34 0e 75 88 c0 f9 2a 1e 0a
a5 6b e3 8e e1 73 b9 d1 56 1e 60 9f 82 71 6c 4e
5c 1c a4 bd b5 23 a2 bc 82 f2 11 17 61 28 33 3f
02 c9 e7 cb f7 84 a6 22 4a 64 eb fa d7 84 a1 d9
ad c7 5d 77 cd 2a 65 79 95 9a d4 5c 22 8c 62 ae
0e fc c8 fd bd c8 4d 66 0d c3 69 d3 c4 cb e8 33
72 1a f1 cc 31 5f 08 75 65 6b 77 3b 23 c3 b8 74
02 fa 15 6e e4 7a b2 73 17 8f 08 02 20 7e b8 d7
N Next payload: VID, reserved: 0x0, length: 24
87 4d 63 76 cc 10 30 0e 4c 95 40 24 d3 b3 3b f3
44 be 0f e5
Therefore, despite the fact that the client sent the groups 2,21,20,19,24,14 and 5 (these FIPS−compliant
groups), the headend still only connects only group 2−enabled in policy 1 in the previous configuration. This
problem becomes evident further down in the debugs:
groups), the headend still only connects only group 2−enabled in policy 1 in the previous configuration. This
problem becomes evident further down in the debugs:
IKEv2 received all requested SPIs from CTM to respond to a tunnel request.
IKEv2−PROTO−5: (64): SM Trace−> SA: I_SPI=74572B8D1BEC5873 R_SPI=E4160C492A824B5F
(R) MsgID = 00000006 CurState: R_VERIFY_AUTH Event: EV_OK_RECD_IPSEC_RESP
IKEv2−PROTO−2: (64): Processing IKE_AUTH message
IKEv2−PROTO−1: Tunnel Rejected: Selected IKEv2 encryption algorithm (AES−CBC−192)
is not strong enough to secure proposed IPsec encryption algorithm (AES−GCM−256).
IKEv2−PROTO−1: (64): Failed to find a matching policy
IKEv2−PROTO−1: (64): Received Policies:
ESP: Proposal 1: AES−GCM−256 AES−GCM−192 AES−GCM−128 None Don't use ESN
ESP: Proposal 2: AES−CBC−256 AES−CBC−192 AES−CBC−128 3DES SHA512 SHA384 SHA256 SHA96
Don't use ESN
IKEv2−PROTO−1: (64): Failed to find a matching policy
IKEv2−PROTO−1: (64): Expected Policies:
ESP: Proposal 0: AES−GCM−256 SHA384 Don't use ESN
IKEv2−PROTO−5: (64): Failed to verify the proposed policies
IKEv2−PROTO−1: (64): Failed to find a matching policy