hardMultiple Choice
300-410 Practice Question: An engineer configures an IPsec site-to-site VPN…
An engineer configures an IPsec site-to-site VPN between two routers using iBGP for routing. The BGP session comes up, but routes learned from the remote site are not installed in the routing table. The engineer verifies that the IPsec tunnel is up and that the BGP prefixes are present in the BGP table. What is the most likely explanation?
⚠ Common exam trap
Cisco often tests the concept that BGP route installation depends on next-hop reachability, and candidates mistakenly assume that a working BGP session and IPsec tunnel guarantee route installation, ignoring the need for the next-hop to be reachable via the routing table.
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 next-hop address for the BGP routes is the physical interface IP of the remote router, which is not reachable through the tunnel, so the route is not installed.
In iBGP, the next-hop for routes learned from an eBGP peer is not changed by default. When the remote router advertises prefixes, it sets the next-hop to its physical interface IP address. If the IPsec tunnel is configured to encrypt traffic between the two routers' tunnel endpoints (e.g., virtual tunnel interfaces or crypto maps applied to physical interfaces), the physical interface IP of the remote router may not be reachable through the tunnel. BGP will not install a route in the routing table if the next-hop is not reachable via a valid route in the routing table, even if the BGP session is up and the prefixes are in the BGP table.
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 BGP synchronization rule is enabled, and the IGP does not carry the BGP routes, preventing installation.
Why it's wrong here
The BGP synchronization rule does not prevent a router from installing iBGP-learned routes into its RIB; it only suppresses advertisements to eBGP peers until the prefix is also present in the IGP. In modern IOS, synchronization is disabled by default, and even when enabled, it checks the presence of the exact prefix in the IGP, not the reachability of the next hop. The actual failure here is that the BGP next hop (the remote router's physical interface IP) is not reachable via the tunnel, so the route fails the next-hop reachability check and is not installed—synchronization never factors into that decision.
- ✓
The next-hop address for the BGP routes is the physical interface IP of the remote router, which is not reachable through the tunnel, so the route is not installed.
Why this is correct
iBGP does not change the next hop by default. If the BGP session is over the tunnel, but the next hop is the physical IP, the router cannot reach it unless the IGP or a static route points to the tunnel. The fix is to use next-hop-self on the neighbor.
- ✗
The IPsec transform set uses SHA-2 authentication, which is incompatible with BGP MD5 authentication.
Why it's wrong here
BGP MD5 authentication and IPsec transform-set authentication operate at completely different protocol layers. BGP MD5 (TCP option 19) protects only the TCP session between BGP peers, while IPsec's ESP authentication (e.g., HMAC-SHA-2) authenticates the encrypted IP payload; they do not interact or compete. A transform set's authentication algorithm has no bearing on BGP's ability to install routes—RIB installation depends on next-hop reachability, not on which authentication method is used for packet integrity. Therefore, this option is incorrect because even if both were configured, the mismatch in authentication mechanisms cannot prevent a valid BGP route from being installed.
- ✗
The BGP session is using loopback interfaces, and the IPsec tunnel is not configured to encrypt traffic to the loopback.
Why it's wrong here
If the BGP session uses loopback interfaces, the IPsec tunnel must protect traffic between those loopback addresses, and the BGP next-hop would be the loopback IP, not a physical interface IP. In this scenario, the described symptom is that the next-hop points to the physical interface IP, which is not reachable through the tunnel—so the route is rejected for unreachability, not because loopback traffic is unencrypted. Even if the IPsec tunnel were missing for loopback traffic, the router would still try to install the route if the next hop were reachable; encryption is irrelevant to the BGP decision process. Thus, the root cause is next-hop reachability, not a gap in IPsec encryption coverage for loopback traffic.
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 1,401 original 300-410 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 →
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.