IPSec Phase 2 Negotiation fails with "IKEv2 child SA negotiation is failed received KE type %d, expected %d" - DH Group mismatch in Phase 2
122821
Created On 02/13/20 03:00 AM - Last Modified 08/04/22 22:36 PM
Symptom
- VPN Tunnel not coming up or went down
- System Logs showing "IKEv2 child SA negotiation is failed received KE type %d, expected %d"
- System Logs showing "IKEv2 child SA negotiation failed when processing SA payload. no suitable proposal found in peer's SA payload."
- CLI show command outputs on the two peer firewalls showing different DH Group algorithms (Example: DH Group 14 vs. DH Group 20)
- >less mp-log ikemgr.log showing "received KE type 14, expected 20"
- >less mp-log ikemgr.log showing "INVALID_KE_PAYLOAD"
- >less mp-log ikemgr.log showing "received Notify payload protocol 0 type NO_PROPOSAL_CHOSEN"
- >less mp-log ikemgr.log showing "transform ID doesn't match: my DH20[20], peer DH14[14]" (requires ikemgr on debug logging level)
- This DH Group mismatch in Phase 2 (IPSec Crypto Profile) won't be visible in a packet capture (unless pcap is manually decrypted), so it is best to just use CLI commands / checking both sides' configurations manually to identify and resolve this mismatched configuration
Web UI
Navigate to Network > IPSec Crypto Profile > edit IPSec Crypto Profile > edit DH Group
CLI
On both VPN peers, run the below command(s) via CLI
> show vpn tunnel
FW1> show vpn tunnel
TnID Name Gateway Local Proxy IP Ptl:Port Remote Proxy IP Ptl:Port Proposals
1 VPNTunnel10 IKEGatewayTest1 0.0.0.0/0 0:0 0.0.0.0/0 0:0 ESP tunl [DH20][AES192][SHA384] 3600-sec 0-kb
FW2> show vpn tunnel
TnID Name Gateway Local Proxy IP Ptl:Port Remote Proxy IP Ptl:Port Proposals
1 VPNTunnel10 IKEGatewayTest1 0.0.0.0/0 0:0 0.0.0.0/0 0:0 ESP tunl [DH14][AES192][SHA384] 3600-sec 0-kb
System Logs
Navigate to Monitor > System Logs
Wireshark
Take a packet capture on both VPN peers and open them in Wireshark side-by-side
Note: This will not appear in Wireshark by default. You must have dump-level ikemgr logs from both VPN peers to decrypt the packets in Wireshark. This can be done using the steps here
The peer will respond showing that it only accepts DH Group 14, for example:
This will result in the VPN failing with the message below:
ikemgr.log
Run the below command via CLI on both peers
>less mp-log ikemgr.log
2022-06-30 13:30:43 [PERR]: received KE type 14, expected 20 2022-06-28 13:41:44 [DEBG]: transform ID doesn't match: my DH20[20], peer DH14[14], skip to next ... 2022-06-28 13:41:44 [DEBG]: no peer transform matched; try next my transform proposal 2022-06-28 13:41:44 [DEBG]: none of my proposal matched 2022-06-28 13:41:44 [PERR]: no proposal chosen 2022-06-28 14:23:41 [DEBG]: received notify type INVALID_KE_PAYLOAD 2022-06-28 14:23:41 [DEBG]: ikev2_process_child_notify, notify type INVALID_KE_PAYLOAD 2022-06-28 13:41:44 [DEBG]: received notify type NO_PROPOSAL_CHOSEN 2022-06-28 13:41:44 [DEBG]: ikev2_process_child_notify, notify type NO_PROPOSAL_CHOSEN 2022-06-28 13:41:44 [PWRN]: 14 is not a child notify type 2022-06-28 13:41:44 [PERR]: received Notify payload protocol 0 type NO_PROPOSAL_CHOSEN
Note: Some of the log messages above may not show up unless ikemgr has been set to 'debug' mode
Environment
- PAN-OS
- Palo Alto Networks firewall configured with IPSec VPN Tunnel
Cause
This issue occurs when the two VPN peers have a mismatch in DH Group number
Resolution
- Configure both sides of the VPN to have a matching DH Group algorithm
(If your VPN peer is a different vendor firewall, perform their equivalent/same Phase 2 DH Group configuration change on their firewall if they are the source of the mismatch)
- Perform a Commit
- Run the below commands a couple times each on both the VPN peer firewall CLIs to get them to freshly initiate and form:
>clear vpn ike-sa gateway <name> >clear vpn ipsec-sa tunnel <name>