easyMultiple Choice
350-401 Practice Question: An engineer is troubleshooting a site-to-site VPN…
An engineer is troubleshooting a site-to-site VPN that uses IPsec with IKEv1. The tunnel is established, but traffic is intermittently dropped. The engineer checks the 'show crypto ipsec sa' output and sees that the number of packets that failed anti-replay check is increasing. What is the most likely cause of this issue?
⚠ Common exam trap
Cisco often tests the anti-replay mechanism by linking it to packet reordering from asymmetric routing or multi-path forwarding, leading candidates to mistakenly blame rekeying or encryption settings instead of the actual cause of out-of-order delivery.
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 traffic is taking multiple paths, causing packets to arrive out of order.
The anti-replay check in IPsec uses sequence numbers to protect against replay attacks. When packets arrive out of order, the anti-replay window (default size 64 or 1024 packets) may reject packets that fall outside the window, causing the counter to increment. This is typical when traffic takes multiple paths, as packets can be reordered before reaching the peer.
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 IPsec SA is using a weak encryption algorithm.
Why it's wrong here
The anti-replay mechanism in IPsec is implemented via the sequence number field and a sliding window in the ESP/AH header; it is completely independent of the cipher used for encryption. A weak algorithm such as DES or 3DES might weaken confidentiality, but it does not alter sequence-number processing or the receiver's replay window. Therefore, even a vulnerable encryption algorithm would not cause packets to be dropped as suspected replays.
- ✗
The IPsec SA is using ESP in tunnel mode with authentication only.
Why it's wrong here
ESP in tunnel mode with authentication only (using ESP-NULL or no encryption) still includes the 32-bit sequence number field, and an authentication-only ESP SA is fully capable of anti-replay checks if configured. Neither the encapsulation mode (tunnel vs. transport) nor the IPsec protocol's decision to use integrity instead of confidentiality changes how the anti-replay window operates. Thus, authentication-only ESP would not by itself produce anti-replay failures; it simply omits encryption.
- ✓
The traffic is taking multiple paths, causing packets to arrive out of order.
Why this is correct
IPsec anti-replay protection relies on monotonically increasing sequence numbers and a receiver-side sliding window, typically 64 packets wide. If traffic is load-balanced across multiple paths with different latency, packets can arrive out of order; a legitimate packet whose sequence number falls below the left edge of the window is treated as a replay and discarded. This is a well-known cause of intermittent IPsec drops, especially with unequal-cost multipath or ECMP routing.
- ✗
The IPsec SA lifetime is too short, causing frequent rekeying.
Why it's wrong here
A short SA lifetime causes frequent rekeying, but each new SA initializes its sequence number counter to zero and has its own anti-replay window, so an old SA being deleted does not cause anti-replay failure on the new SA. Any transient packet loss during rekey is due to the moment when the old SA is torn down and the new SA is negotiated, not to the anti-replay check. Therefore, rapid rekeying would not manifest as replay-induced drops.
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
This 350-401 question is part of Courseiva's 1,923-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.