mediumMultiple Choice
350-401 Practice Question: Is configuring a site-to-site IPsec VPN between…
A network engineer is configuring a site-to-site IPsec VPN between two Cisco routers. The engineer wants to ensure that the VPN tunnel uses the strongest possible encryption and authentication algorithms. The engineer configures the following: crypto isakmp policy 10, authentication pre-share, encryption aes-256, group 14, lifetime 86400. On the remote router, the engineer configures: crypto isakmp policy 10, authentication pre-share, encryption aes-256, group 14, lifetime 86400. The tunnel fails to establish. What is the most likely cause?
⚠ Common exam trap
Cisco often tests the fact that the hash algorithm is a mandatory parameter in an ISAKMP policy, and candidates mistakenly assume that omitting it will default to a consistent value across routers, leading to a mismatch.
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
✓
The hash algorithm is not specified and defaults may differ between routers.
The most likely cause is that the hash algorithm is not specified in the ISAKMP policy. By default, Cisco IOS uses SHA-1 (or MD5 on older versions) for the hash algorithm, but if one router defaults to SHA-1 and the other defaults to MD5, the IKE Phase 1 proposals will not match, causing the tunnel to fail. The configuration must explicitly include the `hash` command to ensure both peers agree on the same hash algorithm.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The lifetimes are set too high; they should be 3600 seconds.
Why it's wrong here
The IKE lifetime of 3600 seconds is the standard Cisco default and is identical on both routers, so the peers will not reject a proposal because of lifetimes. Even if the values were different, IPsec negotiation handles lifetime differences gracefully by taking the smaller proposal, causing an early rekey rather than a complete failure. Therefore, this configuration is not the source of the mismatch.
- ✓
The hash algorithm is not specified and defaults may differ between routers.
Why this is correct
In IKEv1, when a transform set does not explicitly name the HMAC hash algorithm, the router substitutes a built-in default that varies across Cisco IOS versions and platforms—often SHA-1 in older releases but SHA-256 in newer builds. If the two routers default to different hashes, the hash algorithm field in the proposal differs, so the responder cannot find an acceptable transform and IKE SA negotiation fails, even though all explicitly configured parameters match. This is a classic invisible-difference problem because the config appears consistent, but the effective proposal is not.
- ✗
The Diffie-Hellman group 14 is not supported on these routers.
Why it's wrong here
Diffie-Hellman group 14 (2048-bit MODP) is defined in RFC 3526 and is supported on virtually all modern Cisco routing and switching platforms; a lack of support would be extremely unusual for the equipment referenced in the question. If group 14 were unavailable, the router would generate an explicit error when applying the crypto isakmp policy, not a subtle failure. Since the debug output would show the proposal reaching the hash check, an unsupported DH group is not a plausible cause.
- ✗
Pre-shared keys cannot be used with AES-256 encryption.
Why it's wrong here
Pre-shared keys and AES-256 operate at different layers in IPsec: the PSK authenticates the IKE phase 1 exchange and seeds key derivation, while AES-256 is an encryption transform for ESP-protected data traffic. There is no protocol restriction preventing a PSK from being used with AES-256; in fact, PSK is one of the most common authentication methods for AES-encrypted VPNs. A failure here would be due to a PSK mismatch or a missing hash/integrity algorithm, not to a fundamental incompatibility.
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
Courseiva writes every 350-401 question from scratch — 1,923 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 practice question is part of Courseiva's free Cisco 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 350-401 exam.