hardMultiple ChoiceObjective-mapped
IPsec VPN Negotiation Failure: DH Group Mismatch
Exhibit
crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 lifetime 3600 crypto ipsec transform-set AES256-SHA esp-aes 256 esp-sha-hmac crypto map CMAP 10 ipsec-isakmp set peer 198.51.100.1 set transform-set AES256-SHA match address 101
Refer to the exhibit. A network engineer is configuring a site-to-site VPN. The remote peer is using AES-256 encryption and SHA-1 for integrity. Which configuration parameter is likely misconfigured?
Quick Answer
Group 5 stands out as the misconfigured parameter because the scenario tells you the encryption (AES-256) and integrity (SHA-1) algorithms already match between peers, which rules out the transform-set as the source of the failure, leaving the Diffie-Hellman group used during IKE Phase 1 as the remaining variable that determines whether the tunnel can even negotiate successfully. IPsec VPN negotiation happens in two phases, and Phase 1 must agree on a DH group before the peers can establish the secure channel used to negotiate everything else; if one peer is configured for Group 5 while the remote peer expects a different group, such as Group 2 or Group 14, the key exchange itself fails and the tunnel never comes up, regardless of whether the encryption and hashing algorithms would otherwise be compatible. This is why VPN negotiation failures can look confusing at first: the visible symptoms don't tell you which specific parameter caused it, so you have to work through the negotiation sequence, Phase 1 authentication and DH group first, then Phase 2 encryption and integrity, to isolate where agreement broke down. Whenever a VPN troubleshooting question confirms that encryption and integrity settings already match, look at the DH group and other Phase 1 parameters as the likely mismatch, since Phase 1 has to succeed before Phase 2 settings are ever compared.
⚠ Common exam trap
ISC2 often tests the misconception that transform-set mismatches are the only cause of VPN failures, but the trap here is that DH group mismatch in IKE Phase 1 is a separate, easily overlooked parameter that prevents tunnel establishment even when encryption and integrity algorithms match.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Group 5
The remote peer is using AES-256 encryption and SHA-1 for integrity, which are both supported in an IPsec transform-set. However, the exhibit shows that the local peer is configured with Group 5 (Diffie-Hellman 1536-bit), while the remote peer likely expects a different DH group (e.g., Group 2 or Group 14). DH group mismatch during Phase 1 (IKE) negotiation causes the VPN tunnel to fail, even if encryption and integrity algorithms match.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Transform-set
Why it's wrong here
The transform-set uses AES-256 and SHA-1, which matches the peer.
- ✗
Pre-shared key
Why it's wrong here
Pre-shared key is configured but not shown; mismatch would cause failure but is not indicated.
- ✓
Group 5
Why this is correct
Group 5 (DH5) is deprecated; the peer may require a stronger DH group.
- ✗
IKE lifetime
Why it's wrong here
Lifetime mismatch can cause renegotiation issues but is not the most likely problem.
Quick reference
VPN Protocol Comparison
| Protocol | Port | Encryption | Authentication | Use Case |
|---|---|---|---|---|
| IKEv2 / IPsec | UDP 500 / 4500 | AES-256 | Certificates / PSK | Site-to-site & remote access |
| SSL / TLS VPN | TCP 443 | TLS 1.3 | Certificates / MFA | Clientless remote access |
| L2TP / IPsec | UDP 1701 | AES (IPsec) | PSK / Certificates | Legacy remote access |
| WireGuard | UDP 51820 | ChaCha20 | Public keys | Modern high-performance VPN |
| PPTP | TCP 1723 | MPPE (weak) | MS-CHAPv2 | Legacy — avoid in production |
PPTP is considered insecure. IKEv2/IPsec and SSL VPN are the current recommended options.
Go deeper
Related to this question
About these practice questions
One of 920 original SSCP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SSCP
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A network engineer is troubleshooting a site-to-site VPN that is failing to establish. The pre-shared key is correct and both sides use IKEv2. The VPN logs show 'no proposal chosen'. What is the most likely cause?
medium- A.Firewall blocking UDP port 500
- B.Incorrect peer IP address
- ✓ C.Mismatched encryption algorithms
- D.Expired certificates
Why C: The 'no proposal chosen' error in IKEv2 indicates that the two VPN peers cannot agree on a common set of security parameters during the IKE_SA_INIT exchange. Since the pre-shared key is correct and both sides use IKEv2, the most likely cause is a mismatch in the encryption algorithms (e.g., AES-256 vs. AES-128), hash algorithms (e.g., SHA-256 vs. SHA-1), or Diffie-Hellman groups (e.g., group 14 vs. group 2). This prevents the IKE security association from being established.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SSCP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSCP exam.