300-410 · topic practice
Practise Cisco CCNP ENARSI 300-410 VPN Technologies practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
What the exam tests
VPN Technologies questions test whether you can apply the concept in context, not just recognise a definition.
How the topic appears in realistic exam-style scenarios.
Which detail in the question changes the correct answer.
How to eliminate plausible but wrong options.
How to connect the question back to the wider exam objective.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Trap 1: The transform-set does not support HTTP traffic due to port…
Transform-set defines encryption and authentication algorithms, not traffic selection.
Trap 2: The IPsec SA is only established for ICMP; other traffic requires a…
The SA is triggered by the ACL; if the ACL is narrow, only matched traffic creates SAs.
Trap 3: The router has a NAT rule that bypasses IPsec for HTTP traffic.
NAT can interfere, but the question does not mention NAT.
The ACL for interesting traffic only permits ICMP, so only ICMP is encrypted.
IPsec uses the ACL to determine which traffic to protect; if only ICMP is permitted, other traffic is not encrypted.
The transform-set does not support HTTP traffic due to port filtering.
Why wrong: Transform-set defines encryption and authentication algorithms, not traffic selection.
The IPsec SA is only established for ICMP; other traffic requires a separate SA.
Why wrong: The SA is triggered by the ACL; if the ACL is narrow, only matched traffic creates SAs.
The router has a NAT rule that bypasses IPsec for HTTP traffic.
Why wrong: NAT can interfere, but the question does not mention NAT.
Trap 1: The ACL is filtering NHRP packets, preventing spoke-to-spoke…
NHRP resolution succeeds, so NHRP packets are not blocked.
Trap 2: The spoke has a misconfigured NHRP authentication key.
Authentication mismatch would prevent NHRP registration, but resolution succeeds.
Trap 3: The ACL is applied outbound, filtering outgoing traffic.
Outbound ACL would affect traffic leaving the spoke, not incoming spoke-to-spoke traffic.
The ACL is filtering the outer IP header of the mGRE tunnel, blocking spoke-to-spoke traffic.
The ACL on the tunnel interface filters the encapsulated packets; if it only permits the hub's IP, traffic from other spokes is denied.
The ACL is filtering NHRP packets, preventing spoke-to-spoke resolution.
Why wrong: NHRP resolution succeeds, so NHRP packets are not blocked.
The spoke has a misconfigured NHRP authentication key.
Why wrong: Authentication mismatch would prevent NHRP registration, but resolution succeeds.
The ACL is applied outbound, filtering outgoing traffic.
Why wrong: Outbound ACL would affect traffic leaving the spoke, not incoming spoke-to-spoke traffic.
Trap 1: The tunnel mode is mGRE, but the spokes are configured with…
Spokes typically use mGRE as well; if they used p2p GRE, they would only connect to the hub, but the scenario does not indicate this.
Trap 2: The NHRP network-id is different on R2 and R3, preventing…
The network-id must match, but the scenario shows it is 1 on the hub; if spokes had different IDs, they would not register.
Trap 3: The tunnel source interface is not reachable between spokes.
Spoke-to-spoke reachability is established via NHRP; if NHRP is not working, the tunnel source may be reachable but the tunnel itself fails.
The spokes are missing the 'ip nhrp nhs' command to point to the hub, preventing registration and resolution of spoke-to-spoke addresses.
Without NHS configuration, spokes do not register with the hub, so NHRP cannot provide the mapping for spoke-to-spoke tunnels.
The tunnel mode is mGRE, but the spokes are configured with point-to-point GRE tunnels.
Why wrong: Spokes typically use mGRE as well; if they used p2p GRE, they would only connect to the hub, but the scenario does not indicate this.
The NHRP network-id is different on R2 and R3, preventing communication.
Why wrong: The network-id must match, but the scenario shows it is 1 on the hub; if spokes had different IDs, they would not register.
The tunnel source interface is not reachable between spokes.
Why wrong: Spoke-to-spoke reachability is established via NHRP; if NHRP is not working, the tunnel source may be reachable but the tunnel itself fails.
Trap 1: The spoke's 'ip nhrp shortcut' command is missing on the tunnel…
Incorrect because the engineer verified that 'ip nhrp shortcut' is enabled.
Trap 2: The spoke's routing table has a static route to the remote spoke's…
Incorrect because a static route would not prevent shortcut creation; the redirect is still needed.
Trap 3: The hub's tunnel interface has 'no ip nhrp redirect' configured.
Incorrect because the engineer verified that 'ip nhrp redirect' is enabled.
The hub router does not have a route to the remote spoke's LAN subnet.
Correct because the hub must have a route to the destination subnet to send an NHRP redirect.
The spoke's 'ip nhrp shortcut' command is missing on the tunnel interface.
Why wrong: Incorrect because the engineer verified that 'ip nhrp shortcut' is enabled.
The spoke's routing table has a static route to the remote spoke's LAN via the hub.
Why wrong: Incorrect because a static route would not prevent shortcut creation; the redirect is still needed.
The hub's tunnel interface has 'no ip nhrp redirect' configured.
Why wrong: Incorrect because the engineer verified that 'ip nhrp redirect' is enabled.
Trap 1: The route map uses a prefix-list that does not match the spoke's…
Even if matched, the next-hop would still be the hub's tunnel IP.
Trap 2: The spoke routers have NHRP authentication mismatch, preventing…
NHRP authentication affects registration, not route next-hop.
Trap 3: The tunnel mode is mGRE on the spokes, which does not support…
Phase 2 supports spoke-to-spoke with mGRE.
The route map is applied on the spoke router inbound from the hub, but it should be applied on the hub router outbound to the spokes.
The hub must set the next-hop to the remote spoke's tunnel IP; the spoke cannot change the next-hop for routes received from the hub.
The route map uses a prefix-list that does not match the spoke's subnet.
Why wrong: Even if matched, the next-hop would still be the hub's tunnel IP.
The spoke routers have NHRP authentication mismatch, preventing direct communication.
Why wrong: NHRP authentication affects registration, not route next-hop.
The tunnel mode is mGRE on the spokes, which does not support spoke-to-spoke.
Why wrong: Phase 2 supports spoke-to-spoke with mGRE.
Trap 1: The spoke is missing the ip nhrp shortcut command under Tunnel0.
While the spoke also needs this command, the hub's missing redirect is the primary cause here.
Trap 2: The tunnel mode should be gre multipoint on the spokes.
Spokes can use point-to-point GRE tunnels; multipoint is only required on the hub.
Trap 3: IPv6 NHRP is not supported on DMVPN phase 3.
IPv6 NHRP is supported on DMVPN phase 3 with appropriate configuration.
The hub is missing the ip nhrp redirect command under Tunnel0.
This command enables NHRP redirect messages, which are essential for phase 3 spoke-to-spoke shortcut establishment.
The spoke is missing the ip nhrp shortcut command under Tunnel0.
Why wrong: While the spoke also needs this command, the hub's missing redirect is the primary cause here.
The tunnel mode should be gre multipoint on the spokes.
Why wrong: Spokes can use point-to-point GRE tunnels; multipoint is only required on the hub.
IPv6 NHRP is not supported on DMVPN phase 3.
Why wrong: IPv6 NHRP is supported on DMVPN phase 3 with appropriate configuration.
A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue:
R1# debug crypto ipsec *Mar 1 00:02:34.567: IPSEC(sa_request): , (key eng. msg.) src=10.0.0.1, dst=10.0.0.2, src_proxy=192.168.1.0/255.255.255.0/0/0, dst_proxy=192.168.2.0/255.255.255.0/0/0, *Mar 1 00:02:34.567: IPSEC(validate_proposal): transform proposal (esp-3des esp-sha-hmac) not supported for proxy 192.168.1.0/255.255.255.0/0/0 *Mar 1 00:02:34.567: IPSEC(validate_proposal): proposal doesn't match! *Mar 1 00:02:34.568: IPSEC(create_sa): SA created with (0x1234, 0x5678) but no inbound or outbound SPI
What does this output indicate?
Trap 1: The IPsec SA is established successfully with ESP 3DES and SHA.
The output says 'proposal doesn't match' and 'no inbound or outbound SPI', indicating failure.
Trap 2: The ACL for the crypto map is misconfigured, causing the traffic to…
The debug shows src_proxy and dst_proxy, indicating the ACL matched, but the transform set is the issue.
Trap 3: The IKE phase 1 SA is not established before IPsec negotiation.
The debug does not mention IKE phase 1; it focuses on IPsec transform validation.
The IPsec SA is established successfully with ESP 3DES and SHA.
Why wrong: The output says 'proposal doesn't match' and 'no inbound or outbound SPI', indicating failure.
The transform set on the remote peer does not match the local transform set, causing IPsec SA negotiation to fail.
The debug explicitly states the proposal is not supported, meaning a mismatch in transform set.
The ACL for the crypto map is misconfigured, causing the traffic to not match.
Why wrong: The debug shows src_proxy and dst_proxy, indicating the ACL matched, but the transform set is the issue.
The IKE phase 1 SA is not established before IPsec negotiation.
Why wrong: The debug does not mention IKE phase 1; it focuses on IPsec transform validation.
A network engineer runs the following command on Router R1:
R1# show crypto ipsec sa
interface: Tunnel0
Crypto map tag: VPN-MAP, local addr 10.1.1.1protected vrf: (none) local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0) current_peer 10.1.1.2 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 #send errors 0, #recv errors 0
Based on this output, what is the problem?
Trap 1: The IPsec SA is not established; phase 1 is still pending.
The SA is present with a current peer; phase 1 and 2 are complete.
Trap 2: The remote peer is unreachable; the SA is in a dead state.
The SA is still present; if the peer were unreachable, the SA would be deleted or show errors.
Trap 3: The tunnel interface is down; the SA cannot be used.
The output does not show interface state; SA presence suggests tunnel is up.
The IPsec SA is not established; phase 1 is still pending.
Why wrong: The SA is present with a current peer; phase 1 and 2 are complete.
The tunnel is up but no traffic is being encrypted; the crypto ACL may not match the traffic.
Zero packet counts indicate no traffic has been encapsulated; check the crypto ACL and routing.
The remote peer is unreachable; the SA is in a dead state.
Why wrong: The SA is still present; if the peer were unreachable, the SA would be deleted or show errors.
The tunnel interface is down; the SA cannot be used.
Why wrong: The output does not show interface state; SA presence suggests tunnel is up.
Trap 1: The spoke routers have incorrect NHRP authentication, causing the…
Authentication mismatch would prevent NHRP registration, but the mapping exists.
Trap 2: The tunnel interface on R1 is not in the correct VRF.
VRF misconfiguration would cause other issues, but not specifically spoke-to-spoke failure with existing NHRP mapping.
Trap 3: The IPsec transform set is mismatched between spokes.
IPsec mismatch would prevent tunnel establishment, but the DMVPN session is up.
The hub is missing the ip nhrp redirect command, and the spokes are missing ip nhrp shortcut, preventing spoke-to-spoke direct communication.
Without these commands, the hub does not trigger NHRP resolution for spoke-to-spoke traffic, and spokes do not install the necessary routes.
The spoke routers have incorrect NHRP authentication, causing the mapping to be invalid.
Why wrong: Authentication mismatch would prevent NHRP registration, but the mapping exists.
The tunnel interface on R1 is not in the correct VRF.
Why wrong: VRF misconfiguration would cause other issues, but not specifically spoke-to-spoke failure with existing NHRP mapping.
The IPsec transform set is mismatched between spokes.
Why wrong: IPsec mismatch would prevent tunnel establishment, but the DMVPN session is up.
Trap 1: 5 seconds
5 seconds is not the default; it is configurable but not default.
Trap 2: 15 seconds
15 seconds is not the default for GRE tunnels.
Trap 3: 20 seconds
20 seconds is not the default; it may be used for other tunnel types.
5 seconds
Why wrong: 5 seconds is not the default; it is configurable but not default.
10 seconds
The default keepalive interval is 10 seconds.
15 seconds
Why wrong: 15 seconds is not the default for GRE tunnels.
20 seconds
Why wrong: 20 seconds is not the default; it may be used for other tunnel types.
Trap 1: The tunnel interface is not configured with 'ipv6 eigrp' under the…
The question states the interface is included in the EIGRP process, so this is not the issue.
Trap 2: The IPsec transform set does not allow multicast traffic, which…
IPsec can encrypt multicast traffic; EIGRP hellos are sent to the multicast address FF02::A, which is encapsulated in the tunnel.
Trap 3: The GRE tunnel does not support EIGRP for IPv6; only OSPFv3 is…
GRE tunnels support any Layer 3 protocol, including EIGRP for IPv6.
EIGRP for IPv6 requires the 'no shutdown' command under the address-family; without it, the process is administratively down.
Unlike EIGRP for IPv4, EIGRP for IPv6 has a shutdown state by default. The 'no shutdown' command is required to activate the address-family.
The tunnel interface is not configured with 'ipv6 eigrp' under the interface.
Why wrong: The question states the interface is included in the EIGRP process, so this is not the issue.
The IPsec transform set does not allow multicast traffic, which EIGRP uses for hellos.
Why wrong: IPsec can encrypt multicast traffic; EIGRP hellos are sent to the multicast address FF02::A, which is encapsulated in the tunnel.
The GRE tunnel does not support EIGRP for IPv6; only OSPFv3 is supported.
Why wrong: GRE tunnels support any Layer 3 protocol, including EIGRP for IPv6.
A network engineer runs the following command to troubleshoot an MPLS L3VPN issue:
R1# show bgp vpnv4 vrf CUSTOMER-A 10.1.1.0/24
Output: BGP routing table entry for 10.1.1.0/24, version 10 Paths: (1 available, best #1, table CUSTOMER-A) Advertised to update-groups: 1 Refresh Epoch 1 Local
0.0.0.0 from 0.0.0.0 (10.0.0.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:100:100 mpls labels in/out nolabel/nolabel
What does this output indicate?
Trap 1: The route is learned from a BGP peer
The next hop is 0.0.0.0, indicating local origin, not from a peer.
Trap 2: The route has an MPLS label of 100
The extended community RT:100:100 is not an MPLS label; labels are nolabel.
Trap 3: The route is not best
The output explicitly states 'best'.
The route is locally originated and has no MPLS label
The route is sourced locally (0.0.0.0 from 0.0.0.0) and the mpls labels are nolabel/nolabel.
The route is learned from a BGP peer
Why wrong: The next hop is 0.0.0.0, indicating local origin, not from a peer.
The route has an MPLS label of 100
Why wrong: The extended community RT:100:100 is not an MPLS label; labels are nolabel.
The route is not best
Why wrong: The output explicitly states 'best'.
Trap 1: BGP next-hop-self is not configured on R2.
Next-hop-self would change the next-hop to R2's tunnel IP, but the issue is reachability of the next-hop, not its value.
Trap 2: The IPsec tunnel is not encrypting BGP traffic.
BGP peering is established, so IPsec is working for BGP traffic.
Trap 3: The BGP network statement for 10.10.10.0/24 is missing on R2.
R2 is advertising the route, as R1 sees it in BGP table.
The static route to 10.10.10.0/24 via tunnel causes recursive routing failure because the tunnel destination is not reachable.
The static route references the tunnel interface, but the tunnel's destination IP must be reachable via another route. If not, the route is invalid, and BGP cannot use the next-hop.
BGP next-hop-self is not configured on R2.
Why wrong: Next-hop-self would change the next-hop to R2's tunnel IP, but the issue is reachability of the next-hop, not its value.
The IPsec tunnel is not encrypting BGP traffic.
Why wrong: BGP peering is established, so IPsec is working for BGP traffic.
The BGP network statement for 10.10.10.0/24 is missing on R2.
Why wrong: R2 is advertising the route, as R1 sees it in BGP table.
A network engineer runs the following command on Router PE2:
PE2# show ip bgp vpnv4 vrf CUSTOMER_A 10.10.10.0 24
BGP routing table entry for 10.10.10.0/24, version 15 Paths: (1 available, best #1, table CUSTOMER_A) Advertised to update-groups: 1 Refresh Epoch 1 Local, imported path from 10.10.10.0/24
10.1.1.1 (metric 20) from 10.1.1.1 (10.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:100 mpls labels in/out 18/19
Based on this output, what is the problem?
Trap 1: The route is not being advertised to any BGP peer.
The output shows 'Advertised to update-groups: 1', meaning it is being advertised.
Trap 2: The route is missing the required Route Target community.
The output shows 'Extended Community: RT:100:100', so the RT is present.
Trap 3: The route has an incorrect label binding.
Labels 18/19 are present and valid; no error is shown.
The route is not being advertised to any BGP peer.
Why wrong: The output shows 'Advertised to update-groups: 1', meaning it is being advertised.
The route is missing the required Route Target community.
Why wrong: The output shows 'Extended Community: RT:100:100', so the RT is present.
The route is functioning correctly with no issues.
All fields indicate a valid, best route with labels and RT.
The route has an incorrect label binding.
Why wrong: Labels 18/19 are present and valid; no error is shown.
Trap 1: show ipv6 route
Shows IPv6 routing table, not tunnel interface status.
Trap 2: show ipv6 tunnel 0
This is not a valid Cisco IOS command.
Trap 3: show running-config interface tunnel 0
Shows configuration, not operational status.
show interfaces tunnel 0
Displays tunnel interface status, encapsulation, and counters.
show ipv6 interface tunnel 0
Shows IPv6-specific details including link-local address and ND status.
show ipv6 route
Why wrong: Shows IPv6 routing table, not tunnel interface status.
show ipv6 tunnel 0
Why wrong: This is not a valid Cisco IOS command.
show running-config interface tunnel 0
Why wrong: Shows configuration, not operational status.
Trap 1: 'show crypto isakmp sa' is the correct command to view IKEv2 SAs.
Incorrect. 'show crypto isakmp sa' is for IKEv1; for IKEv2 use 'show crypto ikev2 sa'.
Trap 2: The 'pkts encaps' counter in 'show crypto ipsec sa' increments on…
Incorrect. 'pkts encaps' increments on the outbound SA; inbound SA uses 'pkts decaps'.
Trap 3: 'show crypto map' displays the current packet count for each IPsec…
Incorrect. 'show crypto map' shows the crypto map configuration, not packet counters.
'show crypto session' displays the IKEv2 SA status and the IPsec SA status.
Correct. This command shows both IKE and IPsec session information.
'show crypto ipsec sa' shows the number of packets that have been encrypted and decrypted.
Correct. The output includes 'pkts encaps' and 'pkts decaps' counters.
'show crypto isakmp sa' is the correct command to view IKEv2 SAs.
Why wrong: Incorrect. 'show crypto isakmp sa' is for IKEv1; for IKEv2 use 'show crypto ikev2 sa'.
The 'pkts encaps' counter in 'show crypto ipsec sa' increments on the inbound SA.
Why wrong: Incorrect. 'pkts encaps' increments on the outbound SA; inbound SA uses 'pkts decaps'.
'show crypto map' displays the current packet count for each IPsec SA.
Why wrong: Incorrect. 'show crypto map' shows the crypto map configuration, not packet counters.
A network engineer runs the following command to troubleshoot DMVPN NHRP:
R1# debug nhrp
NHRP: Registration request sent to 10.0.0.1 via GigabitEthernet0/0 NHRP: Registration reply received from 10.0.0.1 Holding time: 3600 sec Flags: 0x0000 NHRP: Cache added 10.1.1.1/32 via 10.0.0.1, non-caching
What does this output indicate?
Trap 1: NHRP registration failed because no reply was received.
A reply was received.
Trap 2: NHRP registration is pending due to authentication failure.
No authentication failure is indicated.
Trap 3: NHRP registration is rejected by the hub.
The reply contains a holding time, indicating acceptance.
NHRP registration to the hub is successful.
Registration request sent and reply received, with a cache entry added.
NHRP registration failed because no reply was received.
Why wrong: A reply was received.
NHRP registration is pending due to authentication failure.
Why wrong: No authentication failure is indicated.
NHRP registration is rejected by the hub.
Why wrong: The reply contains a holding time, indicating acceptance.
Trap 1: To control which VRFs import routes from other PEs.
That is the function of the Route Target (RT), not the RD.
Trap 2: To specify the VPN label that is used for forwarding.
The VPN label is allocated by the LDP or BGP, not by the RD.
Trap 3: To identify the VRF on the local PE router.
The VRF is identified by its name locally; the RD is used in BGP updates.
To make IPv4 prefixes unique across different VRFs in the MPLS network.
The RD creates a globally unique VPNv4 prefix by combining with the IPv4 address, preventing route ambiguity.
To control which VRFs import routes from other PEs.
Why wrong: That is the function of the Route Target (RT), not the RD.
To specify the VPN label that is used for forwarding.
Why wrong: The VPN label is allocated by the LDP or BGP, not by the RD.
To identify the VRF on the local PE router.
Why wrong: The VRF is identified by its name locally; the RD is used in BGP updates.
Trap 1: Add an 'ip nat outside' command on the inside interface.
Incorrect because the inside interface should be 'ip nat inside'; adding outside would break the NAT logic.
Trap 2: Configure a route-map to exempt the VPN traffic from NAT.
Incorrect because the issue is that NAT is not translating the outbound traffic; exempting would make it worse.
Trap 3: Change the static NAT to 'ip nat inside source static 10.0.0.10…
Incorrect because 'extendable' allows multiple static NATs for the same inside host, but it does not fix the routing/interface issue.
Add an 'ip nat outside' command on the inside interface.
Why wrong: Incorrect because the inside interface should be 'ip nat inside'; adding outside would break the NAT logic.
Configure a route-map to exempt the VPN traffic from NAT.
Why wrong: Incorrect because the issue is that NAT is not translating the outbound traffic; exempting would make it worse.
Ensure that the router has a route to the remote site's public IP via the outside interface, and that the static NAT entry is correctly applied.
Correct because if the return traffic from the server is routed out a different interface (e.g., a VPN tunnel interface), the NAT might not be applied; the router needs to route the traffic via the outside interface where NAT is configured.
Change the static NAT to 'ip nat inside source static 10.0.0.10 203.0.113.10 extendable'.
Why wrong: Incorrect because 'extendable' allows multiple static NATs for the same inside host, but it does not fix the routing/interface issue.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused VPN Technologies sessions
Every question in these sessions is drawn from the VPN Technologies domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Practise 300-410 questions linked to Layer 3 Technologies.
Work through 300-410 questions on VPN Technologies.
Work through 300-410 questions on Infrastructure Security.
Infrastructure Services practice questions for 300-410.
Targeted 300-410 practice covering 300-410 fundamentals.
Work through 300-410 questions on 300-410 scenario.
Practise 300-410 questions linked to 300-410 troubleshooting.
A free account saves results across sessions and highlights which topics need work.
Sign up free