Loading...
Loading...
After IKEv2 SA rekey the IOS-XE device is unable to encrypt / decrypt IKEv2 messages using new IKEv2 SA. DPD messages cannot be exchanged. Any Create Child SA for IPSEC SA rekey fails. When DPD periodic is configured on the IOS-XE router it deletes the IKEv2 SA, without sending a delete. The IPSEC SA can stay up - show crypto session shows "up-no-ike". This can cause "Invalid SPI" messages on the other side. The other side, if using DPD periodic, brings the IKEv2 SA and IPSEC SA down. The tunnel recovers when the remote peer initiates again. The debugs seen on the IOS-XE device: debug crypto ikev2 debug crypto ikev2 error Failure to send DPD: 2022/03/15 16:59:53.351474 {IOSRP_R0-0}{1}: [ikev2] [1676]: (debug): IKEv2:(SESSION ID = 526,SA ID = 5):Sending DPD/liveness query 2022/03/15 16:59:53.351513 {IOSRP_R0-0}{1}: [ikev2] [1676]: (debug): IKEv2:(SESSION ID = 526,SA ID = 5):Building packet for encryption. 2022/03/15 16:59:53.354463 {IOSRP_R0-0}{1}: [ikev2] [1676]: (ERR): SA ID:5 SESSION ID:526 Remote: 198.51.100.1/4500 Local: 203.0.113.20/4500 IVRF/FVRF: 9/8 : Failed to construct an encrypted payload 2022/03/15 16:59:53.354514 {IOSRP_R0-0}{1}: [ikev2] [1676]: (debug): IKEv2-ERROR:(SESSION ID = 526,SA ID = 5):: Failed to construct an encrypted payload 2022/03/15 16:59:32.142191 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): IKEv2:(SESSION ID = 26564,SA ID = 18):Received Packet [From 198.51.100.1:4500/To 203.0.113.20:4500/VRF i0:f10] 2022/03/15 16:59:32.142213 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): Initiator SPI : C504E6A532E8AFC7 - Responder SPI : F092013C3276106D Message id: 0 2022/03/15 16:59:32.142258 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): IKEv2 INFORMATIONAL Exchange REQUEST 2022/03/15 16:59:32.142265 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): IKEv2-PAK:(SESSION ID = 26564,SA ID = 18):Next payload: ENCR, version: 2.0 2022/03/15 16:59:32.142289 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): Exchange type: INFORMATIONAL, flags: INITIATOR 2022/03/15 16:59:32.142296 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): Message id: 0, length: 80 2022/03/15 16:59:32.142391 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): Payload contents: 2022/03/15 16:59:32.143009 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): 2022/03/15 16:59:32.143991 {IOSRP_R0-0}{1}: [ikev2] [28375]: (ERR): SA ID:18 SESSION ID:26564 Remote: 198.51.100.1/4500 Local: 203.0.113.20/4500 IVRF/FVRF: 5/10 Failed to parse the packet: Failed to decrypt an encrypted payload 2022/03/15 16:59:32.194611 {IOSRP_R0-0}{1}: [ikev2] [28375]: (debug): IKEv2-ERROR:(SESSION ID = 26564,SA ID = 18):Failed to parse the packet: Failed to decrypt an encrypted payload
IKEv2 tunnel on IOS-XE. Crypto IKEv2 policy has multiple proposals using different algorithms - AES-CBC and AES-GCM. The VPN peer has IKEv2 policy with proposals in different order - e.g. AES-GCM and AES-CBC. The peer that initiates the IKEv2 SA rekey is not the same who initiated the tunnel. As a result the new IKEv2 SA is using different algorithm than one used to bring up initial IKEv2 SA.
1. Use only one preferred IKEv2 SA proposal in the IKEv2 policy. This might be tricky when configuring new VPNs with different peers. 2. If multiple proposals are needed agree with the remote peers on the order of proposals - from strongest to weakest. 3. Make sure the same side initiates the IKEv2 SA and rekey. The IKEv2 SA lifetime is local to the peers, so it can be configured that one peer has lower IKEv2 SA lifetime and always initiates the rekey. The same peer should always initiate the tunnel. 4. Create separate IKEv2 policies per different peers. IOS-XE allows creating IKEv2 policy matching on local IP and local fVRF. Therefore explicit "per peer" IKEv2 policy might not be possible.
The IKEv2 RFC doesn't explicitly say change of ciphers should be supported. This never worked and was never tested on IOS-XE, hence treating it as enhancement request.
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.