VPN Technologies practice questions

Drag and drop the steps to negotiate an IKEv2 IPsec site-to-site tunnel into the correct order, from first to last.

Question 2harddrag order

Drag and drop the steps to troubleshoot an IPsec site-to-site VPN adjacency failure into the correct order, from first to last.

Question 3mediumdrag order

Study the full IPv6 explanation →

Drag and drop the steps to verify and validate the operational state of an IPsec site-to-site VPN into the correct order, from first to last.

Question 4mediumdrag order

Drag and drop the steps to configure a GRE tunnel for IPv6 over IPv4 into the correct order, from first to last.

Question 5hardmultiple choice

Study the full EIGRP explanation →

A DMVPN network uses IPv6 with EIGRP as the routing protocol. Spoke routers R2 and R3 are behind NAT and use mGRE tunnels. The hub R1 has an IPv6 ACL applied inbound on the tunnel interface that permits only EIGRP and denies all other IPv6 traffic. Spoke-to-spoke traffic fails even though direct tunnels are established. R2 shows 'ping 2001:db8:3::1 source loopback0' fails, but 'ping 2001:db8:1::1' (hub) succeeds. What is the root cause?

Trap 1: NAT traversal is broken for spoke-to-spoke traffic due to IPsec…

The ping to the hub works, indicating NAT traversal is functional.

Trap 2: EIGRP is not advertising spoke loopbacks to other spokes, causing…

If EIGRP were not advertising, the ping would fail with 'no route', but the issue is filtering.

Trap 3: The mGRE tunnel on R2 does not have a destination for R3,…

DMVPN dynamically creates spoke-to-spoke tunnels; the mGRE configuration is correct.

A
R1's inbound ACL on the tunnel interface permits only EIGRP, dropping all other traffic including spoke-to-spoke data packets.
Spoke-to-spoke traffic is forwarded through the hub if the routing table points to the hub. The ACL on the hub's tunnel interface filters this traffic.
B
NAT traversal is broken for spoke-to-spoke traffic due to IPsec encryption issues.
Why wrong: The ping to the hub works, indicating NAT traversal is functional.
C
EIGRP is not advertising spoke loopbacks to other spokes, causing no route.
Why wrong: If EIGRP were not advertising, the ping would fail with 'no route', but the issue is filtering.
D
The mGRE tunnel on R2 does not have a destination for R3, preventing direct communication.
Why wrong: DMVPN dynamically creates spoke-to-spoke tunnels; the mGRE configuration is correct.

Study the full IPv6 explanation →

Question 6hardmultiple choice

An engineer configures IPv6 uRPF loose mode on an interface that connects to a DMVPN spoke. The spoke router uses NHRP to register with the hub and establishes a tunnel. Traffic from the spoke to destinations behind the hub is dropped. Which is the most likely explanation?

Trap 1: The hub has uRPF strict mode configured, which breaks the DMVPN…

Incorrect. The question specifies uRPF loose mode on the spoke interface, not strict mode on the hub.

Trap 2: The spoke's NHRP registration packets are filtered by the uRPF…

Incorrect. NHRP uses unicast or multicast; uRPF checks source address, not destination.

Trap 3: The tunnel interface has an IPv6 ACL that denies traffic from the…

Incorrect. There is no mention of an ACL; the issue is uRPF behavior.

A
The spoke's tunnel IPv6 address is not in the global routing table because it is only known via NHRP, causing uRPF loose mode to drop packets sourced from that address.
Correct. uRPF loose mode requires that the source address be present in the routing table (any interface). If the address is only in NHRP cache, not in the routing table, packets are dropped.
B
The hub has uRPF strict mode configured, which breaks the DMVPN tunnel because of asymmetric routing.
Why wrong: Incorrect. The question specifies uRPF loose mode on the spoke interface, not strict mode on the hub.
C
The spoke's NHRP registration packets are filtered by the uRPF check because they use multicast destination.
Why wrong: Incorrect. NHRP uses unicast or multicast; uRPF checks source address, not destination.
D
The tunnel interface has an IPv6 ACL that denies traffic from the spoke's tunnel address, overriding uRPF.
Why wrong: Incorrect. There is no mention of an ACL; the issue is uRPF behavior.

Question 7hardmultiple choice

A network engineer is troubleshooting NAT for a VPN tunnel. The router has a static NAT rule 'ip nat inside source static 10.0.0.10 203.0.113.10' for a server. The VPN traffic from the remote site to 203.0.113.10 is being NATed to 10.0.0.10, but the return traffic from the server to the remote site is not being translated back. The engineer sees that the server sends packets with source 10.0.0.10 to the remote site's public IP. What should the engineer do to fix this?

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.

A
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.
B
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.
C
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.
D
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.

Study the full ACL explanation →

Question 8hardmultiple choice

A network engineer configures CoPP on a router that is a DMVPN hub. The policy includes a class-map to match NHRP traffic and police it. After deployment, spoke-to-spoke tunnels fail to establish, although spoke-to-hub tunnels work. Which is the most likely explanation?

Trap 1: The CoPP policy drops IPsec packets, which are used for…

Spoke-to-spoke tunnels use mGRE, not IPsec directly; NHRP is the control protocol.

Trap 2: The CoPP policy is applied to the tunnel interface, not the control…

CoPP is applied to the control plane, not interfaces.

Trap 3: The CoPP policy uses the default class class-default, which blocks…

The class-default permits traffic by default.

A
The CoPP policy drops IPsec packets, which are used for spoke-to-spoke encryption.
Why wrong: Spoke-to-spoke tunnels use mGRE, not IPsec directly; NHRP is the control protocol.
B
The CoPP policy polices NHRP traffic, causing NHRP redirect packets from the hub to be dropped, so spokes cannot learn each other's addresses.
NHRP redirects are essential for spoke-to-spoke communication; policing them breaks the dynamic tunnel setup.
C
The CoPP policy is applied to the tunnel interface, not the control plane.
Why wrong: CoPP is applied to the control plane, not interfaces.
D
The CoPP policy uses the default class class-default, which blocks NHRP.
Why wrong: The class-default permits traffic by default.

Study the full ACL explanation →

Question 9hardmultiple choice

A router has CoPP configured with a class-map that matches all traffic and polices it to 10000 pps. The router also has IPsec configured for a site-to-site VPN. After applying CoPP, the IPsec tunnel goes up, but traffic through the tunnel is intermittently dropped. Which is the most likely explanation?

Trap 1: CoPP drops ESP packets, which are data plane traffic.

ESP packets are data plane and should not hit the control plane unless they are destined to the router.

Trap 2: IPsec uses TCP, and CoPP only polices UDP.

IKE uses UDP, and ESP is IP protocol 50.

Trap 3: The CoPP policy is applied to the tunnel interface, not the control…

CoPP is applied to the control plane.

A
CoPP drops ESP packets, which are data plane traffic.
Why wrong: ESP packets are data plane and should not hit the control plane unless they are destined to the router.
B
CoPP drops IKE packets during rekey, causing the IPsec tunnel to fail temporarily.
IKE packets are control plane; if dropped, the tunnel may not rekey properly, causing traffic loss.
C
IPsec uses TCP, and CoPP only polices UDP.
Why wrong: IKE uses UDP, and ESP is IP protocol 50.
D
The CoPP policy is applied to the tunnel interface, not the control plane.
Why wrong: CoPP is applied to the control plane.

Study the full IPv6 explanation →

Question 10hardmultiple choice

A network engineer is troubleshooting IPv6 DMVPN phase 2 spoke-to-spoke tunnel failures. Spoke routers are able to communicate with the hub, but direct spoke-to-spoke traffic is not working. Router R1 (spoke) has the following relevant configuration:

interface Tunnel0

ipv6 address 2001:DB8:1::1/64 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint ipv6 nhrp network-id 1 ipv6 nhrp nhs 2001:DB8:1::2 ipv6 nhrp map multicast dynamic !

Router R2 (hub) shows: show ipv6 nhrp brief output indicates that both spokes are registered. What is the root cause?

Trap 1: The tunnel mode is multipoint, but the spokes need to be configured…

DMVPN phase 2 uses multipoint GRE tunnels on spokes as well.

Trap 2: The spokes have different NHRP network IDs, preventing registration.

The show output indicates both spokes are registered, so network IDs match.

Trap 3: The IPv6 addresses on the tunnel interfaces are in different…

All tunnel interfaces should be in the same subnet for DMVPN to work.

A
The tunnel mode is multipoint, but the spokes need to be configured with 'tunnel mode gre ip' for direct communication.
Why wrong: DMVPN phase 2 uses multipoint GRE tunnels on spokes as well.
B
The hub is missing the 'ipv6 nhrp redirect' command, and the spokes are missing 'ipv6 nhrp shortcut'.
Without redirect and shortcut, spokes do not learn each other's NHRP mappings and send traffic through the hub.
C
The spokes have different NHRP network IDs, preventing registration.
Why wrong: The show output indicates both spokes are registered, so network IDs match.
D
The IPv6 addresses on the tunnel interfaces are in different subnets.
Why wrong: All tunnel interfaces should be in the same subnet for DMVPN to work.

Question 11hardmultiple choice

A large enterprise network is experiencing intermittent connectivity failures for VoIP traffic traversing a DMVPN hub-and-spoke topology. Hub router R1 has the following relevant configuration: ip nat inside source list 100 interface Tunnel0 overload. Spoke router R2 shows: show ip nat translations: Pro Inside global Inside local Outside local Outside global --- 10.1.1.1 192.168.1.1 203.0.113.1 203.0.113.1. VoIP calls drop after 30 seconds. What is the root cause?

Trap 1: Add ip nat inside source list 100 interface Tunnel0 overload to the…

This would duplicate NAT configuration and cause conflicts, not resolve the timeout issue.

Trap 2: Change the DMVPN tunnel mode to GRE over IPsec with no NAT.

This may avoid NAT but is a major redesign and does not address the root cause of timeout mismatch.

Trap 3: Use ip nat outside source list 100 interface Tunnel0 overload.

Outside source NAT is for translating external addresses, not relevant to inside VoIP traffic.

A
Configure ip nat translation timeout 60 for UDP to align with VoIP timers.
Reducing the NAT timeout for UDP ensures that stale entries are cleared quickly, preventing mismatches with VoIP session refreshes.
B
Add ip nat inside source list 100 interface Tunnel0 overload to the spoke router.
Why wrong: This would duplicate NAT configuration and cause conflicts, not resolve the timeout issue.
C
Change the DMVPN tunnel mode to GRE over IPsec with no NAT.
Why wrong: This may avoid NAT but is a major redesign and does not address the root cause of timeout mismatch.
D
Use ip nat outside source list 100 interface Tunnel0 overload.
Why wrong: Outside source NAT is for translating external addresses, not relevant to inside VoIP traffic.

Question 12mediummultiple choice

A network engineer runs the following command on Router R1:

R1# show dmvpn

Legend: Attrb -> S: Static, D: Dynamic, I: Incomplete N: NATed, L: Local, X: No Socket

# Entries: 2
Interface: Tunnel0, IPv4 NHRP Details

Type: Hub, NHRP Peers: 2,

# Ent  Peer NBMA Addr Peer Tunnel Addr State  UpDn Tm Attrb

----- --------------- --------------- ----- -------- ----- 1 192.168.1.2 10.0.0.2 UP 00:15:30 D 2 192.168.2.2 10.0.0.3 UP 00:14:20 D

Based on this output, which statement is correct?

Trap 1: The DMVPN tunnel is not functioning because there are only two…

Two peers is normal for a hub with two spokes.

Trap 2: The hub router has static NHRP entries for the spokes.

The entries are marked D for dynamic.

Trap 3: The spokes are not able to communicate with each other.

This output does not provide information about spoke-to-spoke communication.

A
The DMVPN tunnel is not functioning because there are only two peers.
Why wrong: Two peers is normal for a hub with two spokes.
B
Both spoke routers have established dynamic NHRP registrations with the hub.
The state is UP and attribute is D (dynamic).
C
The hub router has static NHRP entries for the spokes.
Why wrong: The entries are marked D for dynamic.
D
The spokes are not able to communicate with each other.
Why wrong: This output does not provide information about spoke-to-spoke communication.

Question 13mediummultiple choice

A network engineer runs the following command to verify NAT on a VRF:

R1# show ip nat translations vrf CUSTOMER

Pro Inside global Inside local Outside local Outside global --- 10.2.2.2 10.1.1.1 192.168.1.1 192.168.1.1

What is the purpose of the 'vrf CUSTOMER' parameter?

Trap 1: It shows all translations across all VRFs.

The command shows only the specified VRF.

Trap 2: It enables NAT on the VRF interface.

The command is for verification, not configuration.

Trap 3: It creates a new VRF for NAT.

No creation is done.

A
It filters translations for a specific VRF, allowing per-customer NAT.
VRF-aware NAT is used to translate addresses for different customers.
B
It shows all translations across all VRFs.
Why wrong: The command shows only the specified VRF.
C
It enables NAT on the VRF interface.
Why wrong: The command is for verification, not configuration.
D
It creates a new VRF for NAT.
Why wrong: No creation is done.

Question 14hardmultiple choice

A DMVPN network with hub R1 and spokes R2 and R3 is configured with mGRE and NHRP. Spoke-to-spoke tunnels fail to form. R1 configuration: interface Tunnel0, ip address 10.0.0.1 255.255.255.0, tunnel source GigabitEthernet0/0, tunnel mode gre multipoint, ip nhrp network-id 1, ip nhrp map multicast dynamic. R2 shows: 'show dmvpn' shows no dynamic sessions. R3 shows: 'show ip nhrp' shows no entries for R2. What is the root cause?

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.

A
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.
B
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.
C
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.
D
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.

Question 15hardmulti select

An engineer must configure NAT so that inside hosts (192.168.1.0/24) are translated to a public IP pool (203.0.113.1-203.0.113.10) when accessing the Internet, but must NOT translate traffic destined to a VPN subnet (10.10.10.0/24) reachable via the same outside interface. Which TWO configuration steps are required? (Choose TWO.)

Trap 1: Apply 'ip nat inside source list 1 interface GigabitEthernet0/0…

Incorrect. This would translate all traffic from 192.168.1.0/24, including traffic to the VPN subnet, which is not desired.

Trap 2: Configure 'ip nat inside source static 192.168.1.1 203.0.113.1' for…

Incorrect. Static NAT would require individual entries and would still translate traffic to the VPN subnet unless additional filtering is applied.

Trap 3: Apply 'ip access-group 100 in' on the inside interface to block…

Incorrect. Blocking traffic is not the goal; the goal is to allow traffic but not translate it.

A
Create an ACL that denies 10.10.10.0 0.0.0.255 and permits any, then reference it in a route map with 'match ip address'.
Correct. The ACL denies the VPN subnet, so the route map will not match traffic to that destination, thus exempting it from NAT.
B
Apply 'ip nat inside source list 1 interface GigabitEthernet0/0 overload' where ACL 1 permits 192.168.1.0 0.0.0.255.
Why wrong: Incorrect. This would translate all traffic from 192.168.1.0/24, including traffic to the VPN subnet, which is not desired.
C
Use 'ip nat inside source route-map RMAP pool POOL' where the route map matches the ACL from step A.
Correct. The route map uses the ACL to selectively translate only traffic not denied (i.e., not destined to VPN).
D
Configure 'ip nat inside source static 192.168.1.1 203.0.113.1' for each host to ensure translation.
Why wrong: Incorrect. Static NAT would require individual entries and would still translate traffic to the VPN subnet unless additional filtering is applied.
E
Apply 'ip access-group 100 in' on the inside interface to block traffic to the VPN subnet.
Why wrong: Incorrect. Blocking traffic is not the goal; the goal is to allow traffic but not translate it.

Question 16hardmultiple choice

An engineer configures an IPsec site-to-site VPN between two routers. The tunnel comes up, but traffic is not encrypted. Which is the most likely explanation?

Trap 1: The transform set uses ESP with null encryption.

Null encryption would still encrypt (with null algo), but traffic would be encapsulated.

Trap 2: The ISAKMP policy has the wrong authentication method.

ISAKMP policy affects phase 1, not encryption of data.

Trap 3: The pre-shared key is incorrect.

Incorrect PSK would prevent phase 1 from completing.

A
The crypto ACL does not match the traffic that is being sent.
Correct. Interesting traffic must match the ACL for encryption.
B
The transform set uses ESP with null encryption.
Why wrong: Null encryption would still encrypt (with null algo), but traffic would be encapsulated.
C
The ISAKMP policy has the wrong authentication method.
Why wrong: ISAKMP policy affects phase 1, not encryption of data.
D
The pre-shared key is incorrect.
Why wrong: Incorrect PSK would prevent phase 1 from completing.

Question 17mediummultiple choice

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.

A
NHRP registration to the hub is successful.
Registration request sent and reply received, with a cache entry added.
B
NHRP registration failed because no reply was received.
Why wrong: A reply was received.
C
NHRP registration is pending due to authentication failure.
Why wrong: No authentication failure is indicated.
D
NHRP registration is rejected by the hub.
Why wrong: The reply contains a holding time, indicating acceptance.

Question 18hardmultiple choice

A network engineer runs the following command to troubleshoot IPsec IKE phase 1:

R1# debug crypto isakmp

ISAKMP: (0:0:N/A:0) Starting aggressive mode exchange ISAKMP: (0:0:N/A:0) processing SA payload ISAKMP: (0:0:N/A:0) Checking ISAKMP transform 1 against priority 1 policy ISAKMP: (0:0:N/A:0) encryption 3DES ISAKMP: (0:0:N/A:0) hash SHA ISAKMP: (0:0:N/A:0) group 2 ISAKMP: (0:0:N/A:0) auth pre-share ISAKMP: (0:0:N/A:0) life type in seconds ISAKMP: (0:0:N/A:0) life duration (basic) of 86400 ISAKMP: (0:0:N/A:0) atts are not acceptable

What does this output indicate?

Trap 1: IKE phase 1 is successful; the transform set is accepted.

The output says 'atts are not acceptable'.

Trap 2: IKE phase 1 fails due to authentication failure.

No authentication failure is shown; the issue is with the transform set.

Trap 3: IKE phase 1 fails due to lifetime mismatch.

The lifetime is shown but not indicated as the cause; the general 'atts are not acceptable' covers all attributes.

A
IKE phase 1 is successful; the transform set is accepted.
Why wrong: The output says 'atts are not acceptable'.
B
IKE phase 1 fails due to transform set mismatch.
The attributes are not acceptable, indicating a mismatch.
C
IKE phase 1 fails due to authentication failure.
Why wrong: No authentication failure is shown; the issue is with the transform set.
D
IKE phase 1 fails due to lifetime mismatch.
Why wrong: The lifetime is shown but not indicated as the cause; the general 'atts are not acceptable' covers all attributes.

Question 19hardmultiple choice

An engineer configures NAT overload (PAT) on a router to translate internal addresses to a single public IP. Users can browse the web, but some applications that use non-standard ports fail. Which is the most likely explanation?

Trap 1: The NAT pool is exhausted.

Exhaustion would affect all traffic, not just non-standard ports.

Trap 2: The inside interface is not configured correctly.

Interface misconfiguration would affect all traffic.

Trap 3: The outside interface has a different MTU.

MTU mismatch would cause fragmentation issues, not port-specific failure.

A
The application uses protocols that do not have port numbers, such as GRE, and PAT cannot handle them.
Correct. PAT requires port numbers; non-TCP/UDP protocols fail.
B
The NAT pool is exhausted.
Why wrong: Exhaustion would affect all traffic, not just non-standard ports.
C
The inside interface is not configured correctly.
Why wrong: Interface misconfiguration would affect all traffic.
D
The outside interface has a different MTU.
Why wrong: MTU mismatch would cause fragmentation issues, not port-specific failure.

Question 20hardmultiple choice

An engineer configures a DMVPN Phase 2 network. Spoke routers can communicate with the hub, but spoke-to-spoke traffic does not trigger a direct tunnel. Which is the most likely explanation?

Trap 1: The spoke routers have 'ip nhrp shortcut' configured.

Shortcut is required on spokes; its presence would help, not hinder.

Trap 2: The tunnel mode is set to gre multipoint on the spokes.

GRE multipoint is correct for Phase 2.

Trap 3: The NHRP authentication is mismatched.

Authentication mismatch would prevent all NHRP communication.

A
The hub router is missing the 'ip nhrp redirect' command.
Correct. Redirect is required for Phase 2 spoke-to-spoke.
B
The spoke routers have 'ip nhrp shortcut' configured.
Why wrong: Shortcut is required on spokes; its presence would help, not hinder.
C
The tunnel mode is set to gre multipoint on the spokes.
Why wrong: GRE multipoint is correct for Phase 2.
D
The NHRP authentication is mismatched.
Why wrong: Authentication mismatch would prevent all NHRP communication.