mediumMultiple Choice
300-410 Practice Question: Is troubleshooting an IPsec site-to-site VPN…
A network engineer is troubleshooting an IPsec site-to-site VPN where the tunnel is not coming up. The engineer runs 'show crypto isakmp sa' and sees no active IKE SAs. The peer IP address is correctly configured. What should the engineer check first?
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
✓
Check the IP connectivity between the two public IP addresses using ping.
The absence of IKE SAs indicates that IKE phase 1 negotiation has not started or failed. The first step is to verify that the routers can reach each other at the IP layer, as a connectivity issue will prevent any IKE exchange.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Verify that the crypto map is correctly applied to the outside interface.
Why it's wrong here
With no IKE SAs, phase-one negotiation never began, so the crypto map's application is irrelevant until IKE succeeds. It tempts because crypto maps carry the peer and ACL definitions, but they govern phase two, which cannot start without an established IKE SA.
- ✓
Check the IP connectivity between the two public IP addresses using ping.
Why this is correct
IKE SA negotiation requires UDP 500/4500 reachability between peers, so verifying IP connectivity to the peer's public address confirms the underlying transport exists before investigating ISAKMP policy mismatches, preshared keys or NAT-T issues that would also prevent SAs forming.
- ✗
Check the IPsec transform set configuration on both routers.
Why it's wrong here
Transform sets apply to phase two, so they cannot be reached while no IKE SA exists; phase one must complete first. It tempts because transform mismatches do break tunnels, but they manifest after IKE succeeds, not before any SA appears.
- ✗
Verify the pre-shared key is identical on both routers.
Why it's wrong here
A pre-shared key mismatch surfaces only after IKE negotiation starts, typically as an SA that fails or is deleted; here no SA exists at all. It tempts because PSK errors are a common VPN fault, but they cannot explain the total absence of IKE SAs.
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 300-410 question from scratch — 1,401 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 300-410 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 300-410 exam.