Courseiva

CCNA IPsec Site-to-Site VPN Questions

75 of 76 questions · Page 1/2 · IPsec Site-to-Site VPN · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

Examine this configuration on router R1: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 lifetime 86400 ! crypto isakmp key cisco123 address 192.168.1.2 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.2 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 crypto map CMAP ! access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 What is missing from this configuration to ensure the tunnel works correctly?

A.Nothing is missing; the configuration is correct.
B.A route to the remote LAN 10.2.2.0/24 is missing.
C.The ISAKMP policy needs a 'lifetime' value.
D.The transform set should include 'mode transport' for site-to-site.
AnswerA

All necessary components: ISAKMP policy, key, transform set, crypto map with peer and ACL, and interface application.

Why this answer

The configuration is complete for a site-to-site IPsec VPN. ISAKMP policy 10 specifies AES-256 encryption, pre-shared key authentication, Diffie-Hellman group 14, and a lifetime of 86400 seconds (the default is 86400, so explicitly setting it is fine). The crypto map CMAP binds the transform set TSET (AES-256, SHA-HMAC) to peer 192.168.1.2 and matches interesting traffic via access-list 101 (10.1.1.0/24 to 10.2.2.0/24).

The interface GigabitEthernet0/1 applies the crypto map. A route to the remote LAN is not required because IPsec encrypts traffic based on the crypto ACL; routing only needs to reach the peer's public IP (192.168.1.2), which is directly connected on the same subnet.

Exam trap

Cisco often tests the misconception that a route to the remote LAN is required for IPsec to work, but in reality, the crypto ACL handles traffic selection, and only a route to the peer's public IP is needed.

How to eliminate wrong answers

Option B is wrong because a route to the remote LAN 10.2.2.0/24 is not required for IPsec; the crypto ACL defines which traffic is encrypted, and the router only needs a route to the peer's public IP (192.168.1.2), which is directly connected. Option C is wrong because the ISAKMP policy already includes a 'lifetime' value of 86400 seconds, which is valid and matches the default; no lifetime is missing. Option D is wrong because the transform set uses 'mode tunnel' (the default for site-to-site VPNs), which is correct; 'mode transport' is used for host-to-host or GRE-over-IPsec, not for site-to-site.

Practice this question →
2
Multi-Selecthard

Which TWO configuration changes are required to enable IPsec site-to-site VPN with IKEv2 and pre-shared keys on a Cisco IOS router? (Choose TWO.)

Select 2 answers
A.Configure an IKEv2 keyring with the pre-shared key and peer IP address.
B.Apply the 'crypto isakmp key' command globally for the peer.
C.Create an IKEv2 profile that references the keyring.
D.Define a transform set under the IKEv2 policy.
E.Use the 'crypto map' command to reference the IKEv2 profile.
AnswersA, C

Correct. The keyring defines the pre-shared key and associates it with the peer.

Why this answer

A is correct because IKEv2 uses a keyring to store pre-shared keys (PSKs) and associate them with specific peer IP addresses, replacing the legacy 'crypto isakmp key' command used in IKEv1. The keyring is then referenced by an IKEv2 profile, which binds the authentication method and other parameters to the VPN session.

Exam trap

Cisco often tests the distinction between IKEv1 and IKEv2 commands, and the trap here is that candidates familiar with IKEv1 mistakenly select the 'crypto isakmp key' or 'crypto map' options, not realizing IKEv2 requires a keyring and IPsec profile instead.

Practice this question →
3
MCQhard

R1 and R2 are running EIGRP with IPsec site-to-site VPN over a WAN link. The tunnel interface is used for the VPN. R1's EIGRP configuration includes a distribute-list out that filters prefix 192.168.1.0/24. R2's show ip eigrp topology shows the prefix as active but never transitions to passive. R2's show ip route does not have 192.168.1.0/24. What is the root cause?

A.R1's distribute-list out under EIGRP is filtering the prefix 192.168.1.0/24 from being advertised to R2.
B.EIGRP split-horizon is enabled on the tunnel interface.
C.The IPsec tunnel is dropping EIGRP multicast packets.
D.R2 has a passive interface configured for the tunnel.
AnswerA

The distribute-list out on R1 prevents the prefix from being sent to R2, so R2 never receives the route and the prefix stays in active state.

Why this answer

The distribute-list out command on R1 filters the prefix 192.168.1.0/24 from being included in EIGRP updates sent to R2. Since R2 never receives the route, it remains in an active state (query state) because it is still waiting for a reply from R1, and it never transitions to passive. This directly explains why the prefix is missing from R2's routing table.

Exam trap

Cisco often tests the distinction between a route being filtered out (distribute-list) versus a neighbor relationship failing (passive interface or multicast drop), leading candidates to incorrectly attribute the active state to connectivity issues rather than a route advertisement filter.

How to eliminate wrong answers

Option B is wrong because EIGRP split-horizon is disabled by default on tunnel interfaces (since they are point-to-point), and even if enabled, it would prevent routes learned from the tunnel from being advertised back out the same interface, not block a locally connected prefix from being advertised. Option C is wrong because if the IPsec tunnel were dropping EIGRP multicast packets (224.0.0.10), R2 would not see any EIGRP neighbors or updates, but the topology table shows the prefix as active, indicating neighbor adjacency is up and queries are being exchanged. Option D is wrong because a passive interface on R2 would prevent EIGRP from sending or receiving hellos on the tunnel, breaking the neighbor relationship entirely, yet the active topology entry proves the neighbor adjacency exists.

Practice this question →
4
MCQhard

R1 and R2 are connected via an IPsec VPN tunnel. They are running OSPF over the tunnel. R1's show ip ospf neighbor shows R2 as FULL, but R1's show ip ospf database shows the LSA from R2 but with a high age (e.g., 3600). R1's show ip route does not have routes from R2. What is the root cause?

A.The OSPF dead interval on R1's tunnel interface is too short, causing frequent neighbor resets and LSA aging.
B.The IPsec tunnel is dropping OSPF packets due to MTU issues.
C.OSPF network type is point-to-multipoint, causing LSA flooding issues.
D.R2 has a distribute-list out filtering OSPF routes.
AnswerA

A short dead interval causes the neighbor to be declared dead and re-established, but LSAs are not refreshed, leading to high age and eventual removal.

Why this answer

The correct answer is A. When the OSPF dead interval on R1's tunnel interface is too short, R1 may temporarily lose neighbor adjacency with R2, causing the LSA from R2 to be prematurely aged out (age reaches 3600, the MaxAge) and removed from the OSPF database. Even though the neighbor state shows FULL at the moment of inspection, the LSA has already been flushed due to a previous timeout, so routes are not installed in the routing table.

Exam trap

Cisco often tests the distinction between neighbor state (which can appear FULL momentarily after a flap) and LSA age (which reflects the last successful refresh), leading candidates to overlook that a short dead interval can cause LSA expiration without a permanent neighbor down state.

How to eliminate wrong answers

Option B is wrong because MTU issues would typically cause OSPF packets to be fragmented or dropped, leading to neighbor state changes (e.g., stuck in EXSTART/EXCHANGE) or packet loss, not a FULL neighbor state with a high-aged LSA. Option C is wrong because point-to-multipoint network type does not inherently cause LSA flooding issues that result in a high age of 3600; it uses additional LSAs (Type 2) but still maintains proper aging. Option D is wrong because a distribute-list out on R2 would filter routes from being advertised into OSPF, which would prevent the LSA from being generated in the first place, not cause an existing LSA to age to 3600 while the neighbor remains FULL.

Practice this question →
5
MCQmedium

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# show crypto isakmp policy Global IKE policy Protection suite of priority 10 encryption algorithm: AES - Advanced Encryption Standard (256 bit keys). hash algorithm: Secure Hash Standard authentication method: Pre-Shared Key Diffie-Hellman group: #5 (1536 bit) lifetime: 86400 seconds, no volume limit Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard authentication method: Pre-Shared Key Diffie-Hellman group: #1 (768 bit) lifetime: 86400 seconds, no volume limit What does this output indicate?

A.The IKE policy is correctly configured with strong encryption and DH group.
B.The IKE policy uses DES, which is insecure and should be changed.
C.The IKE policy is missing the authentication method.
D.The IKE policy lifetime is set to 86400 seconds, which is too short.
AnswerA

Priority 10 uses AES-256 and DH group 5, which are strong. However, the default policy is weak and should be removed.

Why this answer

Option A is correct because the output shows a global IKE policy with priority 10 using AES-256 encryption, SHA hash, Pre-Shared Key authentication, and Diffie-Hellman group 5 (1536-bit). These parameters represent a strong and secure IKE policy configuration suitable for a production IPsec VPN. The default protection suite is irrelevant unless the peer does not match the higher-priority policy, so the active policy is the one configured with priority 10.

Exam trap

Cisco often tests the distinction between the configured IKE policy and the default protection suite, tricking candidates into thinking the default suite is active or that DES is being used when it is not.

How to eliminate wrong answers

Option B is wrong because the active IKE policy (priority 10) uses AES-256, not DES; DES appears only in the default protection suite, which is not applied unless no matching policy is found. Option C is wrong because the output clearly shows 'authentication method: Pre-Shared Key' for both the priority 10 policy and the default suite, so the authentication method is present. Option D is wrong because an IKE lifetime of 86400 seconds (24 hours) is the default and is considered standard; it is not too short and can be adjusted as needed.

Practice this question →
6
Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5

Why this order

IKEv2 negotiation begins with Phase 1 (IKE_SA_INIT) to establish a secure channel, followed by IKE_AUTH to authenticate and exchange identities. Phase 2 (CREATE_CHILD_SA) then negotiates the IPsec SA, and the final step installs the IPsec security associations into the data plane.

Practice this question →
7
Multi-Selectmedium

Which TWO commands would a network engineer use to verify the status of IPsec security associations on a Cisco IOS router? (Choose TWO.)

Select 2 answers
A.show crypto ipsec sa
B.show crypto isakmp sa
C.show crypto map
D.show ip route
E.show crypto engine connections active
AnswersA, B

This command shows IPsec security associations, including SPI, encapsulation mode, and packet statistics.

Why this answer

The 'show crypto ipsec sa' command displays the IPsec security associations (SAs) that have been negotiated, including their SPI numbers, encryption and authentication algorithms, and packet counters. This is the primary command to verify that IPsec SAs are active and that traffic is being encrypted and decrypted correctly. The 'show crypto isakmp sa' command shows the IKE (ISAKMP) phase 1 SAs, which are necessary for establishing the IPsec SAs, making it a complementary verification step.

Exam trap

Cisco often tests the distinction between IKE phase 1 (ISAKMP) and IPsec phase 2 (IPsec) SAs, and candidates may incorrectly think 'show crypto isakmp sa' alone is sufficient to verify IPsec SAs, or they may confuse 'show crypto engine connections active' with IPsec SA status.

Practice this question →
8
Multi-Selectmedium

Which THREE statements about IPsec transform sets are true? (Choose THREE.)

Select 3 answers
A.A transform set can specify both ESP and AH protocols.
B.A transform set must include an encryption algorithm.
C.Multiple transform sets can be configured and tried in order.
D.AH provides both authentication and encryption.
E.The 'crypto ipsec transform-set' command is used to define the transform set.
AnswersA, C, E

A transform set can include ESP (with or without encryption) and AH for authentication.

Why this answer

Option A is correct because an IPsec transform set can specify both ESP and AH protocols simultaneously. This allows a single transform set to define the combined use of AH for authentication and ESP for encryption (or encryption plus authentication), providing flexibility in securing IPsec traffic.

Exam trap

Cisco often tests the misconception that AH provides encryption, when in fact AH only offers authentication and integrity, while encryption is exclusively the domain of ESP.

Practice this question →
9
Multi-Selecthard

Which THREE symptoms indicate a potential IPsec site-to-site VPN failure due to mismatched IKE parameters? (Choose THREE.)

Select 3 answers
A.The 'show crypto isakmp sa' output shows 'MM_NO_STATE'.
B.The 'show crypto ipsec sa' output shows packet errors.
C.The router logs display '%CRYPTO-4-IKMP_NO_POLICY' error messages.
D.The 'show crypto isakmp sa' output shows 'ACTIVE' state.
E.Pings across the VPN fail, and 'show crypto isakmp sa' shows no SA.
AnswersA, C, E

MM_NO_STATE indicates that IKE phase 1 has not completed, often due to mismatched parameters.

Why this answer

Option A is correct because the 'show crypto isakmp sa' output showing 'MM_NO_STATE' indicates that the IKE Phase 1 negotiation has failed to progress past the Main Mode initial exchange. This typically occurs when IKE parameters such as encryption, hash, Diffie-Hellman group, or authentication method do not match between the two VPN peers, preventing the establishment of an ISAKMP security association.

Exam trap

Cisco often tests the distinction between IKE Phase 1 and Phase 2 failure symptoms, and the trap here is confusing packet errors in 'show crypto ipsec sa' (Phase 2) with IKE parameter mismatches (Phase 1), leading candidates to incorrectly select option B.

Practice this question →
10
MCQhard

An engineer configures a site-to-site IPsec VPN between two routers using OSPF as the routing protocol. The OSPF neighbor becomes stuck in EXSTART state. The engineer verifies that the IPsec tunnel is up and that both routers can ping each other's tunnel interfaces. What is the most likely cause of the OSPF adjacency issue?

A.The OSPF network type on the tunnel interface is set to non-broadcast, preventing DBD exchange.
B.The IPsec transform set uses ESP with authentication, adding 22 bytes of overhead, reducing the tunnel MTU to 1478 bytes, causing OSPF DBD packets larger than 1478 bytes to be dropped.
C.The OSPF hello and dead intervals are mismatched between the two routers.
D.The IPsec tunnel is using transport mode instead of tunnel mode, corrupting OSPF packets.
AnswerB

IPsec encapsulation adds overhead (e.g., 22 bytes for ESP-AES + SHA), reducing the effective MTU. OSPF DBD packets default to 1500 bytes on Ethernet, but if the tunnel MTU is lower, they are fragmented or dropped, leading to EXSTART state.

Why this answer

When OSPF neighbors are stuck in EXSTART state, it indicates a problem with Database Description (DBD) packet exchange. With an IPsec tunnel MTU of 1478 bytes (1500 minus 22 bytes for ESP authentication overhead), OSPF DBD packets that exceed this size are fragmented or dropped. Since IPsec does not support fragmentation of encrypted packets, the DBD exchange fails, preventing OSPF from progressing past EXSTART.

Exam trap

Cisco often tests the distinction between OSPF states—candidates confuse EXSTART (DBD exchange failure) with other states like INIT (hello mismatch) or 2-WAY (neighbor discovery), and overlook the impact of IPsec overhead on MTU and packet fragmentation.

How to eliminate wrong answers

Option A is wrong because the non-broadcast network type does not prevent DBD exchange; it only requires manual neighbor configuration and uses unicast for OSPF packets, but DBD exchange can still occur. Option C is wrong because mismatched hello/dead intervals cause OSPF to get stuck in INIT or 2-WAY state, not EXSTART; EXSTART is specifically about DBD negotiation. Option D is wrong because transport mode is used for host-to-host VPNs and does not inherently corrupt OSPF packets; tunnel mode is typical for site-to-site VPNs, but mode choice does not cause EXSTART issues.

Practice this question →
11
MCQmedium

A network engineer runs the following command on Router R1: R1# show crypto isakmp sa detail Codes: C - IKEv1, I - IKEv2 C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap 1 10.1.1.1 10.1.1.2 ACTIVE aes sha psk 14 23:59:59 Based on this output, which statement is correct?

A.The IKEv1 SA is established with the peer 10.1.1.2.
B.The IKEv2 SA is established with the peer 10.1.1.2.
C.The ISAKMP SA is not established; status is MM_NO_STATE.
D.The Diffie-Hellman group is group 2.
AnswerA

The 'C' code indicates IKEv1, and the status is ACTIVE.

Why this answer

The ISAKMP SA is active, using AES encryption, SHA hash, pre-shared key authentication, and Diffie-Hellman group 14. The lifetime is about 24 hours.

Practice this question →
12
MCQhard

A network engineer is troubleshooting an IPsec site-to-site VPN where the tunnel is up and traffic is flowing, but the engineer notices that the 'show crypto ipsec sa' output shows the 'pkts encaps failed' counter incrementing slowly over time. The tunnel remains up. What is the most likely cause?

A.There is a floating static route that points to the physical interface instead of the tunnel for some subnets.
B.The crypto map is applied to the tunnel interface instead of the physical interface.
C.The IPsec SA lifetime is set too high.
D.The access list in the crypto map is too restrictive and missing some subnets.
AnswerA

Correct because if a floating static route (with a higher administrative distance) becomes active for some traffic, those packets will be sent out the physical interface without encryption, causing encapsulation failures.

Why this answer

A slow but steady increase in 'pkts encaps failed' indicates that some packets that should be encrypted are not being encrypted. This is often caused by a routing issue where some traffic to the remote LAN is being routed out an interface that does not have the crypto map, bypassing encryption.

Practice this question →
13
MCQhard

R1 and R2 are connected via an IPsec VPN tunnel. They are running EIGRP over the tunnel. R1's show ip eigrp neighbors shows R2 as up, but R1's show ip eigrp topology shows a route from R2 as 'stuck-in-active' (SIA). R1's show ip eigrp traffic shows queries being sent but no replies. What is the root cause?

A.The IPsec tunnel is not encrypting EIGRP multicast traffic, causing queries to be dropped.
B.EIGRP split-horizon is enabled on the tunnel interface.
C.The EIGRP active timer is set too low.
D.R2 has a passive interface for the tunnel.
AnswerA

EIGRP queries are sent to multicast address 224.0.0.10. If the crypto map does not protect multicast traffic, queries may be dropped, leading to SIA.

Why this answer

The correct answer is A because EIGRP uses multicast address 224.0.0.10 for neighbor discovery and route updates. If the IPsec VPN tunnel is misconfigured to not encrypt multicast traffic (e.g., using an ACL that only matches unicast or specific protocols), the EIGRP queries sent as multicast packets will be dropped by the IPsec process or the remote router, preventing replies. This results in the neighbor appearing up (due to unicast keepalives or a stale state) but routes stuck-in-active because queries are never answered.

Exam trap

Cisco often tests the misconception that a neighbor being 'up' in 'show ip eigrp neighbors' guarantees full EIGRP communication, when in fact the neighbor state can remain up due to unicast keepalives or a stale hold timer while multicast-based queries are blocked by IPsec ACLs.

How to eliminate wrong answers

Option B is wrong because EIGRP split-horizon prevents routes learned on an interface from being advertised back out the same interface, which could cause routing loops but does not cause queries to go unanswered or SIA routes; split-horizon does not block query transmission or reception. Option C is wrong because setting the EIGRP active timer too low would cause the route to transition to SIA faster, but the root cause here is that queries are sent and no replies are received, not that the timer expires prematurely; a low timer would still require replies to be sent. Option D is wrong because if R2 had a passive interface for the tunnel, R2 would not send or receive EIGRP hellos, so the neighbor adjacency would not form at all; the question states the neighbor is up, ruling out passive interface.

Practice this question →
14
MCQmedium

Which default IPsec transform set is automatically created in Cisco IOS when configuring a site-to-site VPN?

A.esp-aes 256 esp-sha-hmac
B.esp-3des esp-sha-hmac
C.No default transform set is created
D.esp-aes 128 esp-md5-hmac
AnswerC

Cisco IOS requires manual configuration of at least one transform set.

Why this answer

Cisco IOS does not automatically create any default IPsec transform set when configuring a site-to-site VPN. Transform sets must be explicitly defined using the `crypto ipsec transform-set` command, which specifies the encryption and authentication algorithms. The absence of a default ensures that administrators intentionally select the appropriate security parameters for their environment.

Exam trap

Cisco often tests the misconception that a default transform set exists, tempting candidates to select a common algorithm combination like `esp-aes 256 esp-sha-hmac` or `esp-3des esp-sha-hmac` as the default, when in fact no such default is automatically created.

How to eliminate wrong answers

Option A is wrong because `esp-aes 256 esp-sha-hmac` is not a default transform set; it is a valid user-defined transform set but must be manually configured. Option B is wrong because `esp-3des esp-sha-hmac` is also not a default; 3DES is a legacy algorithm that requires explicit configuration. Option D is wrong because `esp-aes 128 esp-md5-hmac` is not a default; MD5 is deprecated for security reasons and must be explicitly chosen if used.

Practice this question →
15
MCQmedium

Consider the following configuration on router R2: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 lifetime 3600 ! crypto isakmp key secretkey address 192.168.1.1 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.1 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.2 255.255.255.0 crypto map CMAP ! access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 Which statement is true?

A.The IPsec tunnel will establish successfully because the transform sets match.
B.The IKE phase 1 will fail due to ISAKMP lifetime mismatch.
C.The tunnel will work but will rekey every hour due to the shorter lifetime.
D.The pre-shared key mismatch will cause the tunnel to fail.
AnswerB

ISAKMP policies must match exactly, including lifetime. A mismatch causes negotiation failure.

Why this answer

The correct answer is B because the ISAKMP lifetime configured on R2 is 3600 seconds (1 hour), but the question implies the remote peer (192.168.1.1) has a different lifetime (likely the default of 86400 seconds). During IKE phase 1 negotiation, the peers propose their lifetimes, and if they do not match, the session fails because Cisco IOS requires identical lifetime values for successful phase 1 establishment. This mismatch causes the IKE phase 1 to fail, preventing the IPsec tunnel from forming.

Exam trap

Cisco often tests the misconception that only transform sets (phase 2) need to match, while IKE phase 1 parameters like lifetime are overlooked, causing candidates to incorrectly select option A.

How to eliminate wrong answers

Option A is wrong because even if the transform sets match, the IKE phase 1 lifetime mismatch will cause the entire tunnel negotiation to fail before phase 2 (transform set matching) is ever reached. Option C is wrong because the tunnel will not work at all due to the phase 1 failure; rekeying is irrelevant if the initial IKE SA cannot be established. Option D is wrong because the pre-shared key is configured correctly on R2 with the address of the peer (192.168.1.1), and there is no evidence of a mismatch; the question specifically highlights the lifetime as the issue.

Practice this question →
16
MCQmedium

A network engineer runs the following command on Router R1: R1# show crypto ipsec sa | include pkts #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 Based on this output, what is the problem?

A.The IPsec SA is not established; the tunnel is down.
B.No interesting traffic is being sent through the tunnel; check the crypto ACL and routing.
C.The tunnel is working correctly; all packets are being encrypted.
D.The remote peer is not responding; the SA is in MM_NO_STATE.
AnswerB

Zero packet counts indicate no traffic matches the crypto ACL or routing is not directing traffic to the tunnel.

Why this answer

All packet counters are zero, indicating no traffic has been encrypted or decrypted. This could be due to a misconfigured crypto ACL that does not match the actual traffic, or routing issues preventing traffic from reaching the tunnel.

Practice this question →
17
MCQhard

A network engineer is troubleshooting an IPsec site-to-site VPN where the tunnel is up but traffic from the remote LAN to the local LAN is not working. The engineer pings from the remote router to the local LAN IP and it succeeds. However, pings from a host on the remote LAN to a host on the local LAN fail. What is the most likely cause?

A.The crypto map access list on the remote router does not include the remote LAN subnet.
B.The local router does not have a route to the remote LAN subnet in its routing table.
C.The IPsec transform set is missing the esp-sha-hmac authentication.
D.The pre-shared key is mismatched between the two routers.
AnswerB

Correct because the local router must have a route to the remote LAN subnet to route the return traffic back through the tunnel. Without it, the return traffic is dropped.

Why this answer

The symptom indicates that the VPN tunnel is working for traffic sourced from the router itself, but not for traffic from the remote LAN. This is typically caused by a missing route on the local router for the remote LAN subnet, or a missing route on the remote router for the local LAN subnet, preventing the return traffic from being routed correctly.

Practice this question →
18
MCQmedium

Given the partial configuration: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 ! crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.2 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 crypto map CMAP ! access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 What is the effect of the 'crypto isakmp key' command with address 0.0.0.0 0.0.0.0?

A.The key will be used only for peer 192.168.1.2 because the crypto map specifies that peer.
B.The key will be accepted from any peer, creating a security vulnerability.
C.The configuration will fail because the key must specify a specific peer address.
D.The key will be ignored because there is no ISAKMP policy with a lifetime.
AnswerB

0.0.0.0 0.0.0.0 is a wildcard that matches any IP address, so any peer can use this key.

Why this answer

The `crypto isakmp key` command with address `0.0.0.0 0.0.0.0` acts as a wildcard, meaning the pre-shared key will be accepted from any peer IP address during IKE Phase 1 authentication. This effectively disables peer-specific validation, allowing any device that knows the key to establish an ISAKMP SA, which is a significant security vulnerability.

Exam trap

Cisco often tests the misconception that the crypto map's `set peer` command restricts which peers can authenticate with the pre-shared key, but in reality, the ISAKMP key wildcard overrides that restriction at the IKE layer.

How to eliminate wrong answers

Option A is wrong because the crypto map's peer specification only controls which peer is used for IPsec SA negotiation, not which peer is allowed to authenticate with the pre-shared key; the wildcard key overrides any peer restriction at the IKE level. Option C is wrong because the configuration is valid; Cisco IOS allows a wildcard address (0.0.0.0 0.0.0.0) for the ISAKMP key, and it will not cause a configuration failure. Option D is wrong because the ISAKMP key is not dependent on a lifetime being configured in the ISAKMP policy; the key is used regardless of whether a lifetime is explicitly set.

Practice this question →
19
MCQmedium

Consider the following configuration on router R1: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 lifetime 86400 ! crypto isakmp key cisco123 address 192.168.1.2 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.2 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 crypto map CMAP ! access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 If the remote peer has an ISAKMP policy with encryption 3des, what will happen?

A.The tunnel will use 3DES because the remote peer's policy is accepted.
B.IKE phase 1 will fail due to encryption algorithm mismatch.
C.The router will automatically adjust to use 3DES.
D.The tunnel will establish but use AES 256 anyway.
AnswerB

The encryption algorithm must match; AES 256 vs 3DES is a mismatch.

Why this answer

IKE phase 1 requires both peers to have a matching ISAKMP policy, including the encryption algorithm. Since R1 is configured with AES 256 and the remote peer uses 3DES, there is no common proposal, causing phase 1 to fail. Cisco IOS does not automatically negotiate or fall back to a different encryption algorithm; the mismatch results in a failed IKE SA.

Exam trap

Cisco often tests the misconception that IKE will automatically negotiate or fall back to a weaker algorithm, but in reality, IKE phase 1 requires an exact match of all policy parameters, and a mismatch causes the entire VPN to fail.

How to eliminate wrong answers

Option A is wrong because IKE phase 1 does not simply accept the remote peer's policy; both peers must have a matching proposal, and a mismatch causes failure. Option C is wrong because Cisco IOS does not automatically adjust encryption algorithms; each peer must have a compatible policy configured. Option D is wrong because the tunnel cannot establish if IKE phase 1 fails; no IPsec SA can be created without a successful IKE SA.

Practice this question →
20
MCQhard

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?

A.The BGP synchronization rule is enabled, and the IGP does not carry the BGP routes, preventing installation.
B.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.
C.The IPsec transform set uses SHA-2 authentication, which is incompatible with BGP MD5 authentication.
D.The BGP session is using loopback interfaces, and the IPsec tunnel is not configured to encrypt traffic to the loopback.
AnswerB

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.

Why this answer

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.

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.

How to eliminate wrong answers

Option A is wrong because BGP synchronization is a Cisco IOS default that requires the IGP to carry the same prefix before BGP installs it, but this rule is disabled by default in modern IOS versions and is not the most likely cause when the next-hop is unreachable. Option C is wrong because IPsec transform set authentication (SHA-2) and BGP MD5 authentication are independent mechanisms; SHA-2 is used for IPsec packet integrity, while MD5 is used for BGP TCP session authentication, and they do not conflict. Option D is wrong because using loopback interfaces for the BGP session does not inherently prevent route installation; the IPsec tunnel can be configured to encrypt traffic to loopback addresses, and the issue is specifically about next-hop reachability, not the BGP session source/destination.

Practice this question →
21
MCQhard

An engineer configures an IPsec site-to-site VPN using IKEv1 with aggressive mode. The VPN tunnel establishes, but after some time, the tunnel goes down and re-establishes repeatedly. The engineer notices that the ISAKMP SA lifetime is set to 86400 seconds on one router and 3600 seconds on the other. What is the most likely explanation for the instability?

A.Aggressive mode does not negotiate ISAKMP SA lifetimes; the responder's lifetime is used, so the SA expires at different times, causing re-key failures.
B.The IPsec transform set uses ESP with null encryption, which is incompatible with aggressive mode.
C.The ISAKMP SA lifetime mismatch causes the IPsec SA to be re-keyed with different parameters, leading to a transform set mismatch.
D.Aggressive mode requires pre-shared keys to be identical, and a mismatch causes the tunnel to drop after the first re-key.
AnswerA

In aggressive mode, the initiator sends its proposal, but the responder's lifetime is used for the SA. If the lifetimes differ, the SA will expire on one side first, causing the tunnel to drop and re-establish.

Why this answer

In IKEv1 aggressive mode, the ISAKMP SA lifetime is not negotiated; the responder's configured lifetime is used. With lifetimes of 86400 seconds (24 hours) on one router and 3600 seconds (1 hour) on the other, the responder will enforce its own 3600-second lifetime. When the SA expires after 3600 seconds, the re-key occurs, but the initiator still expects the longer lifetime, causing a mismatch in the re-key timing and leading to repeated tunnel drops and re-establishments.

Exam trap

Cisco often tests the subtle difference that aggressive mode does not negotiate ISAKMP SA lifetimes, so candidates mistakenly assume both sides must match or that the mismatch only affects phase 2, when in fact the responder's lifetime is used unilaterally, causing re-key timing issues.

How to eliminate wrong answers

Option B is wrong because ESP with null encryption is fully compatible with aggressive mode; aggressive mode affects IKE phase 1 negotiation, not the IPsec transform set encryption type. Option C is wrong because the ISAKMP SA lifetime mismatch does not cause the IPsec SA to be re-keyed with different parameters—the IPsec SA parameters (transform sets) are negotiated separately in phase 2 and remain consistent; the issue is the IKE SA re-key timing. Option D is wrong because aggressive mode does require pre-shared keys to be identical, but a mismatch would prevent the tunnel from establishing at all, not cause it to drop after the first re-key.

Practice this question →
22
MCQeasy

A network engineer runs the following command on Router R1: R1# show crypto ipsec transform-set Transform set ESP-AES256-SHA: { esp-256-aes esp-sha256-hmac } will negotiate = { Tunnel, }, Transform set ESP-AES128-SHA: { esp-aes esp-sha256-hmac } will negotiate = { Tunnel, }, Based on this output, which statement is correct?

A.Both transform sets use tunnel mode; ESP-AES256-SHA uses stronger encryption.
B.The transform sets use transport mode.
C.The transform sets use MD5 for hashing.
D.The transform sets are not compatible with IKEv2.
AnswerA

ESP-AES256-SHA uses 256-bit AES, which is stronger than 128-bit.

Why this answer

The output shows two transform sets configured. The first uses AES-256 with SHA256 HMAC, the second uses AES-128 with SHA256 HMAC. Both use tunnel mode.

Practice this question →
23
MCQeasy

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# show crypto map Crypto Map "CMAP" 10 ipsec-isakmp Peer = 192.168.2.2 Extended IP access list 101 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 Current peer: 192.168.2.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={myset, } Interfaces using crypto map CMAP: Tunnel0 What does this output indicate?

A.The crypto map is misconfigured because it uses an extended ACL with source and destination subnets.
B.The crypto map is correctly configured for a site-to-site VPN with the peer 192.168.2.2.
C.The crypto map is missing the transform set.
D.The crypto map should be applied to the physical interface instead of the tunnel.
AnswerB

The configuration matches typical site-to-site VPN requirements.

Why this answer

Option B is correct because the output shows a properly configured IPsec site-to-site VPN crypto map. It includes a peer (192.168.2.2), an extended ACL (101) that correctly matches the local and remote subnets (192.168.1.0/24 and 192.168.2.0/24), a transform set (myset), and is applied to Tunnel0, which is typical for a site-to-site VPN. The security association lifetime and PFS settings are also present, confirming a valid configuration.

Exam trap

Cisco often tests the misconception that an extended ACL in a crypto map is a misconfiguration, when in fact it is required for site-to-site VPNs to define the traffic to be encrypted.

How to eliminate wrong answers

Option A is wrong because using an extended ACL with source and destination subnets is correct for a site-to-site VPN; it defines which traffic should be encrypted, not a misconfiguration. Option C is wrong because the output explicitly shows 'Transform sets={myset,}', indicating a transform set is configured. Option D is wrong because applying the crypto map to a tunnel interface (Tunnel0) is valid and common for site-to-site VPNs; it does not need to be on the physical interface.

Practice this question →
24
MCQmedium

Which Diffie-Hellman group is considered the minimum recommended for secure IPsec site-to-site VPNs according to current best practices?

A.Group 1
B.Group 2
C.Group 14
D.Group 5
AnswerC

Group 14 uses 2048-bit modulus, the current minimum recommendation.

Why this answer

Diffie-Hellman Group 14 (2048-bit MODP) is the minimum recommended for secure IPsec site-to-site VPNs because it provides sufficient key strength against modern computational attacks, including those from quantum-capable adversaries in the near future. Groups 1 and 2 (768-bit and 1024-bit) are considered weak and deprecated due to the Logjam attack (CVE-2015-4000) and advances in factoring, while Group 5 (1536-bit) is also no longer recommended as it does not meet current NIST SP 800-131A guidelines for minimum 2048-bit Diffie-Hellman strength.

Exam trap

Cisco often tests the misconception that Group 5 (1536-bit) is still acceptable because it was once the default in older IOS versions, but current best practices require at least Group 14 (2048-bit) for compliance with security standards like NIST SP 800-131A.

How to eliminate wrong answers

Option A is wrong because Diffie-Hellman Group 1 (768-bit MODP) is severely weak and deprecated, as it can be broken by state-level actors and is vulnerable to the Logjam attack. Option B is wrong because Diffie-Hellman Group 2 (1024-bit MODP) is also considered insecure and deprecated in modern VPN deployments, as 1024-bit DH is no longer recommended by NIST or IETF for secure key exchange. Option D is wrong because Diffie-Hellman Group 5 (1536-bit MODP) is stronger than Groups 1 and 2 but still falls short of the current minimum recommendation of 2048 bits (Group 14) for IPsec VPNs, and is not considered secure for long-term use.

Practice this question →
25
MCQmedium

What is the default hash algorithm for IKEv1 phase 1 in Cisco IOS when not explicitly configured?

A.SHA-1
B.MD5
C.SHA-256
D.No default; hash must be configured
AnswerB

MD5 is the default hash algorithm for IKEv1.

Why this answer

In Cisco IOS, when IKEv1 phase 1 parameters are not explicitly configured, the default hash algorithm is MD5. This is because the default IKE proposal in Cisco IOS includes MD5 as the hash algorithm, along with DES encryption and Diffie-Hellman group 1. MD5 was chosen historically for its lower computational overhead, though it is now considered cryptographically weak.

Exam trap

Cisco often tests the misconception that IKEv1 has no default hash or that SHA-1 is the default, when in fact MD5 is the default for IKEv1 phase 1 in Cisco IOS.

How to eliminate wrong answers

Option A is wrong because SHA-1 is not the default hash algorithm for IKEv1 phase 1 in Cisco IOS; it must be explicitly configured if desired. Option C is wrong because SHA-256 is a stronger hash that is only available in newer IKE proposals and is never the default for IKEv1 phase 1. Option D is wrong because Cisco IOS does have a default hash algorithm (MD5) for IKEv1 phase 1; the hash does not have to be explicitly configured.

Practice this question →
26
MCQhard

In Cisco IOS, what is the default encryption algorithm for IKEv1 phase 1 if not specified in the ISAKMP policy?

A.AES 256
B.3DES
C.DES
D.AES 128
AnswerC

Cisco IOS defaults to DES if no encryption is specified.

Why this answer

In Cisco IOS, when an IKEv1 ISAKMP policy is configured without specifying an encryption algorithm, the default encryption algorithm is DES (Data Encryption Standard). This is because Cisco IOS defaults to DES for IKEv1 phase 1 if no encryption is explicitly defined in the ISAKMP policy, as per the default policy parameters. DES uses a 56-bit key and is considered weak by modern standards, but it remains the default for backward compatibility.

Exam trap

Cisco often tests the default encryption algorithm for IKEv1 phase 1, and the trap here is that candidates assume a stronger algorithm like AES or 3DES is the default, but Cisco IOS defaults to the weaker DES for backward compatibility.

How to eliminate wrong answers

Option A is wrong because AES 256 is not the default encryption algorithm for IKEv1 phase 1; it must be explicitly configured using the 'encryption aes 256' command under the ISAKMP policy. Option B is wrong because 3DES is not the default; it is a stronger alternative that must be specified with 'encryption 3des' in the ISAKMP policy. Option D is wrong because AES 128 is not the default; it requires explicit configuration via 'encryption aes 128' in the ISAKMP policy.

Practice this question →
27
MCQeasy

A network engineer runs the following command on Router R1: R1# show crypto isakmp sa dst src state conn-id slot status 10.1.1.2 10.1.1.1 QM_IDLE 1 0 ACTIVE Based on this output, which statement is correct?

A.IKE phase 1 is complete; the ISAKMP SA is established.
B.IKE phase 2 is complete; the IPsec SA is active.
C.The ISAKMP SA is in MM_NO_STATE; negotiation has failed.
D.The tunnel is down; the SA is in a dead state.
AnswerA

QM_IDLE means the SA is up and ready for quick mode (phase 2).

Why this answer

QM_IDLE indicates that IKE phase 1 (ISAKMP) is complete and the SA is idle, waiting for phase 2 negotiation. This is the normal state for an established ISAKMP SA.

Practice this question →
28
MCQeasy

A network engineer runs the following command on Router R1: R1# show crypto isakmp policy Global IKE policy Protection suite of priority 10 encryption algorithm: AES - Advanced Encryption Standard (256 bit keys). hash algorithm: Secure Hash Standard 2 (SHA256) authentication method: Pre-Shared Key Diffie-Hellman group: #14 (2048 bit) lifetime: 86400 seconds, no volume limit Protection suite of priority 20 encryption algorithm: AES - Advanced Encryption Standard (128 bit keys). hash algorithm: Secure Hash Standard 2 (SHA256) authentication method: Pre-Shared Key Diffie-Hellman group: #14 (2048 bit) lifetime: 86400 seconds, no volume limit Based on this output, which statement is correct?

A.The router has two IKE policies configured; policy 10 will be preferred.
B.The router has no IKE policies configured; the output is empty.
C.The router uses certificate-based authentication.
D.The Diffie-Hellman group is group 2 (1024 bit).
AnswerA

Lower priority number is preferred; policy 10 with AES-256 will be tried first.

Why this answer

The output shows the configured IKE policies. Both use pre-shared key authentication. This is a normal configuration for IPsec VPN.

Practice this question →
29
MCQeasy

In IPsec site-to-site VPN, what is the default lifetime for ISAKMP (IKE phase 1) security associations on Cisco IOS routers?

A.3600 seconds (1 hour)
B.86400 seconds (24 hours)
C.28800 seconds (8 hours)
D.1800 seconds (30 minutes)
AnswerB

This is the Cisco default for ISAKMP lifetime.

Why this answer

The default lifetime for ISAKMP (IKE phase 1) security associations on Cisco IOS routers is 86400 seconds (24 hours). This is defined in the Cisco IOS default configuration for the `crypto isakmp policy` and is the recommended value to balance security and performance by reducing the frequency of re-authentication and Diffie-Hellman key exchanges.

Exam trap

Cisco often tests the distinction between IKE phase 1 and IPsec phase 2 default lifetimes, so the trap here is confusing the 86400-second (24-hour) default for ISAKMP with the 3600-second (1-hour) default for IPsec SAs.

How to eliminate wrong answers

Option A is wrong because 3600 seconds (1 hour) is the default lifetime for IPsec (IKE phase 2) security associations, not for ISAKMP phase 1. Option C is wrong because 28800 seconds (8 hours) is a common user-configured value but is not the Cisco IOS default for ISAKMP. Option D is wrong because 1800 seconds (30 minutes) is too short for phase 1 and is typically used for aggressive rekeying scenarios, not the default.

Practice this question →
30
MCQhard

An engineer configures mutual redistribution between OSPF and EIGRP on a router that is part of an IPsec site-to-site VPN. After the configuration, routing loops occur intermittently. The engineer has not used any route tagging. What is the most likely cause of the routing loops?

A.The seed metric for EIGRP redistribution is set to a low value, causing EIGRP routes to be preferred over OSPF routes.
B.Routes redistributed from OSPF into EIGRP are re-distributed back into OSPF because there is no route tagging to identify them as OSPF-originated.
C.The IPsec tunnel is using transport mode, which causes routing protocol packets to be dropped.
D.The OSPF process has a higher administrative distance than EIGRP, causing route flapping.
AnswerB

Without route tagging, the router sees the redistributed routes as EIGRP routes and redistributes them back into OSPF, causing the same prefix to be advertised back to the original OSPF domain, leading to loops.

Why this answer

Without route tagging, routes redistributed from OSPF into EIGRP are not marked as OSPF-originated. When EIGRP redistributes these routes back into OSPF, OSPF accepts them as external routes, creating a mutual redistribution loop. This occurs because OSPF has no mechanism to distinguish between its own routes and those learned from EIGRP without explicit tagging (e.g., using a route-map with a tag).

Exam trap

Cisco often tests the concept that mutual redistribution without route tagging or filtering is the primary cause of routing loops, and candidates mistakenly focus on metric or administrative distance differences instead of the re-injection mechanism.

How to eliminate wrong answers

Option A is wrong because the seed metric for EIGRP redistribution affects route selection within EIGRP, not the cause of routing loops in mutual redistribution; loops arise from re-injection, not metric preference. Option C is wrong because IPsec transport mode does not drop routing protocol packets; transport mode only affects the IP header encapsulation and is unrelated to routing loop formation. Option D is wrong because administrative distance differences influence route preference but do not directly cause routing loops; route flapping is a symptom, not the root cause, and the scenario describes intermittent loops, not flapping.

Practice this question →
31
MCQeasy

What is the default IKE (ISAKMP) lifetime value in Cisco IOS for IPsec Site-to-Site VPN?

A.3600 seconds (1 hour)
B.86400 seconds (24 hours)
C.28800 seconds (8 hours)
D.180 seconds (3 minutes)
AnswerB

Cisco IOS defaults IKE lifetime to 86400 seconds.

Why this answer

The default IKE (ISAKMP) lifetime in Cisco IOS for IPsec Site-to-Site VPN is 86400 seconds (24 hours). This value is defined in the ISAKMP policy and controls how long the IKE Phase 1 security association (SA) remains active before requiring re-authentication. A longer lifetime reduces the overhead of re-establishing the Phase 1 tunnel, balancing security with performance.

Exam trap

Cisco often tests the distinction between IKE Phase 1 and IPsec Phase 2 default lifetimes, and the trap here is that candidates confuse the 3600-second default of IPsec SA (Phase 2) with the 86400-second default of IKE SA (Phase 1).

How to eliminate wrong answers

Option A is wrong because 3600 seconds (1 hour) is the default IPsec (Phase 2) SA lifetime, not the IKE (Phase 1) lifetime. Option C is wrong because 28800 seconds (8 hours) is a common custom value but not the Cisco IOS default for IKE. Option D is wrong because 180 seconds (3 minutes) is far too short and would cause excessive rekeying overhead, and it is not a default for any phase in Cisco IOS.

Practice this question →
32
MCQmedium

Given the following partial configuration on router R1: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 lifetime 86400 ! crypto isakmp key cisco123 address 192.168.1.2 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.2 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 crypto map CMAP ! access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 What is the effect of this configuration?

A.IPsec tunnel is established when traffic from 10.1.1.0/24 to 10.2.2.0/24 triggers it.
B.The tunnel will only be established if the peer initiates first.
C.The transform set uses AES 256 with MD5 authentication, which is incorrect.
D.ISAKMP lifetime is set to 86400 seconds, which is too short for a site-to-site VPN.
AnswerA

ACL 101 defines interesting traffic; once matched, IKE and IPsec negotiations begin.

Why this answer

Option A is correct because the configuration uses a crypto map with 'match address 101' referencing an ACL that permits traffic from 10.1.1.0/24 to 10.2.2.0/24. This triggers IPsec SA negotiation via ISAKMP (IKEv1) only when interesting traffic is detected. The tunnel is established dynamically upon matching traffic, which is the standard behavior for a site-to-site VPN using a crypto map.

Exam trap

Cisco often tests the misconception that a crypto map tunnel requires the peer to initiate first, but the default behavior is that the local router initiates when interesting traffic is sent, unless 'responder-only' is configured.

How to eliminate wrong answers

Option B is wrong because the configuration does not include 'set passive' or 'responder-only' mode; the crypto map is applied to the interface, so R1 will actively initiate the tunnel when interesting traffic is sent, not wait for the peer. Option C is wrong because the transform set 'TSET' uses 'esp-sha-hmac', which specifies SHA (HMAC variant) for authentication, not MD5; MD5 would be 'esp-md5-hmac'. Option D is wrong because an ISAKMP lifetime of 86400 seconds (24 hours) is a standard and valid default for site-to-site VPNs; it is not too short and is commonly used.

Practice this question →
33
MCQhard

R1 and R2 have an IPsec VPN tunnel between their physical interfaces. They are running BGP over the tunnel interface. R1's show ip bgp summary shows the BGP session with R2 as established, but R1's show ip bgp shows no routes from R2. R2's show ip bgp shows routes from R1. What is the root cause?

A.R1 has a route-map applied to the BGP neighbor inbound that denies all routes.
B.BGP next-hop-self is missing on R2.
C.The IPsec tunnel is not encrypting BGP traffic.
D.R2 is not advertising any networks.
AnswerA

An inbound route-map can filter all incoming BGP updates, preventing routes from being installed in the BGP table.

Why this answer

The correct answer is A because R1's BGP session is established (TCP port 179 is up), but no routes are received from R2. This indicates that an inbound route-map on R1 is filtering all incoming BGP updates. The route-map is applied to the neighbor inbound direction, which matches the symptom: R1 sees the session as established but has zero routes from R2, while R2 sees routes from R1 (since outbound filtering on R2 is not the issue).

Exam trap

Cisco often tests the distinction between a BGP session being established (TCP state) and routes being exchanged (NLRI processing), so candidates may incorrectly assume that an established session guarantees route exchange, overlooking inbound route-map filtering.

How to eliminate wrong answers

Option B is wrong because missing next-hop-self on R2 would cause R1 to reject routes due to an unreachable next-hop (if the next-hop is not reachable via the tunnel), but the session would still show routes in the BGP table (they would be hidden, not absent). Option C is wrong because the IPsec tunnel not encrypting BGP traffic would not prevent BGP routes from being received; BGP would still exchange routes over the unencrypted link, and the session would likely flap or fail due to mismatched security policies, not silently drop routes. Option D is wrong because R2's show ip bgp shows routes from R1, proving R2 is advertising networks (otherwise R2's table would be empty for those prefixes).

Practice this question →
34
MCQhard

An engineer configures an IPsec site-to-site VPN between two routers using OSPF as the routing protocol. The OSPF neighbor forms, but routes are not being exchanged. The engineer verifies that the IPsec tunnel is up and that OSPF packets are being encrypted. The OSPF network type on the tunnel interface is set to broadcast. What is the most likely explanation for the missing routes?

A.The OSPF network type broadcast requires a DR/BDR election, but the tunnel is point-to-point, so the DR election fails and routes are not exchanged.
B.The IPsec crypto map is configured to encrypt only unicast traffic, and OSPF hello packets are multicast (224.0.0.5), so they are dropped before encryption.
C.The OSPF hello and dead intervals are mismatched, preventing the neighbor from forming.
D.The IPsec tunnel is using transport mode, which does not support multicast traffic.
AnswerB

If the crypto ACL only permits unicast traffic (e.g., 'permit ip host A host B'), multicast OSPF packets are not matched and are sent in clear text or dropped, depending on the configuration. This is a common edge case where the interesting traffic definition does not include multicast.

Why this answer

Option B is correct because OSPF hello packets are sent to the multicast address 224.0.0.5, but IPsec crypto maps by default only encrypt unicast traffic. Since the crypto map does not match multicast packets, OSPF hellos are dropped before encryption, preventing OSPF neighbor adjacency from forming even though the IPsec tunnel is up and other packets are encrypted.

Exam trap

Cisco often tests the misconception that an IPsec tunnel being up guarantees all traffic is encrypted, but the trap here is that OSPF multicast packets are not matched by the default crypto ACL, causing OSPF to fail silently.

How to eliminate wrong answers

Option A is wrong because OSPF network type broadcast on a tunnel interface does not inherently fail; DR/BDR election can occur over a point-to-point tunnel if the network type is set to broadcast, but the real issue is that multicast OSPF hellos are not encrypted. Option C is wrong because the question states that the OSPF neighbor forms, which would not happen if hello/dead intervals were mismatched. Option D is wrong because IPsec transport mode does not inherently block multicast traffic; the limitation is that crypto maps only match unicast traffic, regardless of transport or tunnel mode.

Practice this question →
35
MCQmedium

A network engineer is troubleshooting an IPsec site-to-site VPN that uses a GRE tunnel. The GRE tunnel is up/up, and EIGRP is forming an adjacency over it. However, traffic from the local LAN to the remote LAN is not working. The engineer pings the remote LAN IP from the local router and it succeeds. What is the most likely cause?

A.The local router does not have a route to the remote LAN subnet in its routing table.
B.The crypto map access list does not include the local LAN subnet.
C.The GRE tunnel keepalive is disabled.
D.The IPsec transform set is missing authentication.
AnswerA

Correct because the router can ping the remote LAN using its own IP, but if there is no route for the remote LAN subnet, traffic from LAN hosts will be dropped.

Why this answer

The GRE tunnel and routing protocol are working, but traffic from the LAN is failing. This indicates that the routing table on the local router does not have a route to the remote LAN subnet, or the route points to the wrong next-hop. The ping from the router succeeds because the router uses its own IP as source, which is directly connected to the tunnel.

Practice this question →
36
Multi-Selecthard

Which TWO configuration steps are required to enable IPsec site-to-site VPN with IKEv2 on a Cisco router? (Choose TWO.)

Select 2 answers
A.Configure an IKEv2 keyring with the pre-shared key.
B.Configure an IKEv2 proposal specifying encryption and integrity algorithms.
C.Configure a crypto isakmp policy for phase 1.
D.Configure an IKEv2 profile and bind it to the crypto map.
E.Configure the 'crypto ipsec transform-set' command.
AnswersA, B

The keyring stores the pre-shared key used for authentication in IKEv2.

Why this answer

Option A is correct because an IKEv2 keyring stores the pre-shared key (PSK) used for authenticating the remote peer during IKEv2 SA establishment. Without a keyring, the router has no local credential to present or verify against the peer. Option B is correct because an IKEv2 proposal defines the mandatory encryption (e.g., AES-256) and integrity (e.g., SHA-256) algorithms that both peers must agree on for the IKEv2 Phase 1 (IKE SA) negotiation.

Exam trap

Cisco often tests the distinction between IKEv1 and IKEv2 commands, so the trap here is that candidates mistakenly select 'crypto isakmp policy' (IKEv1) instead of the IKEv2-specific 'crypto ikev2 proposal' and 'crypto ikev2 keyring' commands.

Practice this question →
37
MCQmedium

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.1 protected 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?

A.The IPsec SA is not established; phase 1 is still pending.
B.The tunnel is up but no traffic is being encrypted; the crypto ACL may not match the traffic.
C.The remote peer is unreachable; the SA is in a dead state.
D.The tunnel interface is down; the SA cannot be used.
AnswerB

Zero packet counts indicate no traffic has been encapsulated; check the crypto ACL and routing.

Why this answer

The IPsec SA is present but the packet counters are all zero. This indicates that the tunnel is established but no interesting traffic is being sent through it. The likely cause is that the crypto ACL does not match the actual traffic or routing is not directing traffic into the tunnel.

Practice this question →
38
MCQhard

R1 and R2 are connected via an IPsec VPN tunnel. R1 has a static route to 10.10.10.0/24 pointing to the tunnel interface. R2 has a static route to 192.168.1.0/24 pointing to the tunnel interface. Both routers have BGP configured between loopback addresses over the tunnel. BGP peering is established, but R1 cannot ping 10.10.10.1 (R2's loopback) from its loopback. R1's show ip bgp shows the route as valid but not best. What is the root cause?

A.The static route to 10.10.10.0/24 via tunnel causes recursive routing failure because the tunnel destination is not reachable.
B.BGP next-hop-self is not configured on R2.
C.The IPsec tunnel is not encrypting BGP traffic.
D.The BGP network statement for 10.10.10.0/24 is missing on R2.
AnswerA

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.

Why this answer

The correct answer is A because R1's static route to 10.10.10.0/24 points to the tunnel interface, but the tunnel destination (the remote peer's public IP) is not reachable via a valid routing path. This creates a recursive routing failure: the router tries to resolve the tunnel interface's next-hop (the tunnel destination) but cannot find a route to it, causing the BGP route to be marked as valid but not best. Without a reachable tunnel destination, the IPsec VPN cannot forward traffic, so pings from R1's loopback to 10.10.10.1 fail.

Exam trap

Cisco often tests the concept of recursive routing failure in IPsec VPN scenarios, where candidates mistakenly focus on BGP configuration issues (like next-hop-self or network statements) instead of recognizing that the tunnel destination must be reachable independently of the tunnel itself.

How to eliminate wrong answers

Option B is wrong because next-hop-self on R2 would change the next-hop of BGP routes advertised to R1 to R2's own IP, but the issue here is that the BGP route is valid but not best due to recursive routing failure, not because of next-hop reachability. Option C is wrong because the IPsec tunnel not encrypting BGP traffic would not cause the BGP route to be valid but not best; it might cause a peering issue or packet drop, but the route would still be considered best if reachable. Option D is wrong because the BGP network statement for 10.10.10.0/24 on R2 is not required for R1 to learn the route via BGP; R2 can advertise the route via network or redistribution, and the problem is on R1's side with recursive routing, not on R2's advertisement.

Practice this question →
39
MCQmedium

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# show ip route 192.168.2.0 Routing entry for 192.168.2.0/24 Known via "eigrp 100", distance 90, metric 2684416, type internal Redistributing via eigrp 100 Last update from 10.0.0.2 on Tunnel0, 00:00:23 ago Routing Descriptor Blocks: * 10.0.0.2, from 10.0.0.2, via Tunnel0 Route metric is 2684416, traffic share count is 1 Total delay is 20000 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 What does this output indicate?

A.The route to the remote LAN is not present, indicating a routing issue.
B.The IPsec tunnel is up and EIGRP is exchanging routes over the tunnel.
C.The route is using a static route, not a dynamic routing protocol.
D.The tunnel interface is down, causing the route to be unreachable.
AnswerB

The route is learned via EIGRP on Tunnel0, meaning the tunnel is operational and routing is working.

Why this answer

The output shows a route to 192.168.2.0/24 learned via EIGRP (distance 90) with the next hop 10.0.0.2 reachable through Tunnel0. The last update was 23 seconds ago, confirming the tunnel is up and EIGRP is actively exchanging routing information over the IPsec tunnel. This indicates the IPsec Site-to-Site VPN is functioning and dynamic routing is working correctly.

Exam trap

Cisco often tests the misconception that a route learned via a tunnel interface implies the tunnel is down or that dynamic routing is not functioning, but the presence of a recent update and valid next hop confirms the tunnel is operational.

How to eliminate wrong answers

Option A is wrong because the route is present in the routing table, as shown by the 'Routing entry for 192.168.2.0/24' line, so there is no missing route. Option C is wrong because the route is learned via EIGRP (dynamic routing protocol), not a static route, as indicated by 'Known via "eigrp 100"'. Option D is wrong because the tunnel interface is up and operational; the route is reachable via Tunnel0 with a recent update, and the next hop is valid.

Practice this question →
40
MCQhard

R1 and R2 have an IPsec VPN tunnel between their physical interfaces. They are running OSPF over the tunnel interface. R1's show ip ospf neighbor shows R2 as FULL, but R1's show ip route ospf does not include any routes from R2. R2's show ip route ospf shows routes from R1. What is the root cause?

A.The OSPF cost on R1's tunnel interface is set to 65535, preventing route installation.
B.OSPF network type mismatch: R1 uses broadcast, R2 uses point-to-point.
C.R1 has a distribute-list in filtering OSPF routes.
D.The IPsec tunnel is only encrypting unicast traffic, not OSPF multicast.
AnswerA

OSPF does not install routes with cost 65535 or higher (max metric). R1 receives LSAs but ignores them due to high cost.

Why this answer

When the OSPF cost on R1's tunnel interface is set to 65535, OSPF considers the route unreachable because the maximum OSPF cost for route installation is 65534 (per RFC 2328). Routes with cost 65535 are not installed in the routing table, even though the neighbor state is FULL. This explains why R1 sees R2 as FULL but has no OSPF routes, while R2 (with a normal cost) installs routes from R1.

Exam trap

Cisco often tests the nuance that OSPF neighbor state FULL does not guarantee route installation; the trap here is that candidates assume a FULL adjacency means routes are automatically exchanged and installed, ignoring the OSPF cost limit of 65535.

How to eliminate wrong answers

Option B is wrong because an OSPF network type mismatch (broadcast vs. point-to-point) would prevent the neighbor relationship from reaching FULL, or cause adjacency issues, but here the neighbor is FULL, so this cannot be the root cause. Option C is wrong because a distribute-list filtering OSPF routes would affect inbound or outbound route advertisement, but R2 still receives routes from R1, indicating filtering is not symmetric or not present; moreover, a distribute-list would not cause a FULL neighbor state with zero routes on one side only. Option D is wrong because IPsec tunnels encrypt all IP traffic traversing the tunnel, including OSPF multicast packets (224.0.0.5/224.0.0.6), as the tunnel interface encapsulates the entire IP packet; if OSPF multicast were blocked, the neighbor relationship would not form at all, let alone reach FULL.

Practice this question →
41
MCQhard

An engineer configures an IPsec site-to-site VPN between two routers running EIGRP. The EIGRP neighbor forms, but routes are not being exchanged. The engineer notices that the EIGRP neighbor is stuck in active state for certain routes. What is the most likely explanation?

A.The EIGRP hello packets are being encrypted but the reply is not, causing asymmetric routing.
B.The IPsec ACL is permitting EIGRP packets (protocol 88) only in one direction, so queries are sent but replies are dropped by the remote router's crypto map.
C.The EIGRP K-values are mismatched between the two routers.
D.The IPsec tunnel is using aggressive mode, which does not support multicast traffic.
AnswerB

If the crypto ACL on one router permits only certain traffic (e.g., TCP/179 for BGP) but not EIGRP, EIGRP packets may be dropped. If the other router's ACL permits EIGRP, the neighbor forms partially, but queries may not be replied to, causing SIA.

Why this answer

When EIGRP neighbors form but routes are not exchanged and the neighbor is stuck in active (SIA) state, it indicates that EIGRP queries are being sent but replies are not received. In an IPsec VPN, if the crypto ACL permits EIGRP (protocol 88) only in one direction, queries from one router are encrypted and sent, but the remote router's crypto map does not match the reply packets, so they are dropped. This prevents the EIGRP query/reply process from completing, causing routes to remain in active state and not be exchanged.

Exam trap

Cisco often tests the misconception that EIGRP neighbor formation implies full route exchange, but the trap here is that a one-way crypto ACL permits neighbor formation (since hellos are multicast and may be permitted) but blocks query/reply unicast traffic, causing SIA routes.

How to eliminate wrong answers

Option A is wrong because EIGRP hello packets are multicast (224.0.0.10) and are encrypted by IPsec; asymmetric routing would cause a different issue (e.g., packet loss), not specifically SIA routes. Option C is wrong because K-value mismatch prevents neighbor formation entirely, not just route exchange; the neighbor forms here, so K-values must match. Option D is wrong because aggressive mode is an IKE phase 1 mode that does not affect multicast traffic; IPsec tunnels can transport multicast regardless of IKE mode, and EIGRP uses multicast for hellos, which would still work.

Practice this question →
42
MCQhard

Which authentication method is used by default in IKEv1 main mode for IPsec site-to-site VPN on Cisco IOS?

A.RSA signatures
B.Pre-shared keys
C.Elliptic Curve Digital Signature Algorithm (ECDSA)
D.No default; authentication must be explicitly configured
AnswerB

PSK is the default authentication method for IKEv1.

Why this answer

In Cisco IOS, IKEv1 main mode for IPsec site-to-site VPN defaults to pre-shared keys (PSK) as the authentication method. This is because PSK is the simplest to configure and does not require a public key infrastructure (PKI), making it the default choice when no other authentication method is explicitly specified. The configuration commands like 'crypto isakmp key' directly implement PSK authentication.

Exam trap

Cisco often tests the misconception that IKEv1 has no default authentication method, leading candidates to choose 'No default; authentication must be explicitly configured' when in fact pre-shared keys are the default.

How to eliminate wrong answers

Option A is wrong because RSA signatures require digital certificates and a PKI, which is not the default; they must be explicitly configured with commands like 'crypto isakmp identity' and certificate enrollment. Option C is wrong because ECDSA is not supported as an authentication method in IKEv1 on Cisco IOS; it is only available in IKEv2 with the 'authentication ecdsa-sig' command. Option D is wrong because there is a default authentication method (pre-shared keys) in IKEv1 main mode; authentication does not need to be explicitly configured unless a different method is desired.

Practice this question →
43
MCQmedium

Given this configuration on router R1: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 lifetime 86400 ! crypto isakmp key cisco123 address 192.168.1.2 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.2 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 ! access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 What will happen when traffic from 10.1.1.0/24 to 10.2.2.0/24 is generated?

A.The traffic will be dropped because the ACL denies it.
B.The traffic will be forwarded normally without encryption.
C.The router will attempt to establish an IPsec tunnel but fail because the crypto map is missing.
D.The router will create a dynamic crypto map entry automatically.
AnswerB

Since the crypto map is not applied, the router treats the traffic as normal and forwards it based on routing.

Why this answer

Option B is correct because the crypto map is not applied to any interface. Without the `crypto map CMAP` command under GigabitEthernet0/1, the router has no IPsec policy to enforce on that interface. Traffic matching access-list 101 will simply be forwarded normally as clear-text IP packets, since no encryption is triggered.

Exam trap

The trap here is that candidates often assume a crypto map is automatically applied to the interface it references (e.g., via the peer IP), but Cisco explicitly tests that the `crypto map` command under the interface is required for IPsec to function.

How to eliminate wrong answers

Option A is wrong because access-list 101 is a permit ACL used to identify interesting traffic for IPsec, not a deny ACL; it does not drop traffic. Option C is wrong because the crypto map is fully configured (with peer, transform-set, and match address), but it is not missing—it is simply not applied to any interface, so no tunnel establishment is attempted. Option D is wrong because dynamic crypto maps are used for responder-only scenarios (e.g., when the peer IP is unknown) and are not automatically created; a static crypto map must be explicitly applied to an interface.

Practice this question →
44
MCQmedium

A network engineer is troubleshooting an IPsec site-to-site VPN that stopped working after a recent configuration change. The engineer runs 'show crypto isakmp sa' and sees an active IKE SA, but 'show crypto ipsec sa' shows no IPsec SAs. What is the most likely cause?

A.The IPsec transform set on one router does not match the transform set on the other.
B.The pre-shared key is incorrect on one of the routers.
C.The tunnel interface is down.
D.The IKE proposal is mismatched.
AnswerA

Correct because during phase 2, the routers negotiate the transform set; if they do not match, the IPsec SA cannot be established.

Why this answer

An active IKE SA indicates that IKE phase 1 completed successfully, but no IPsec SAs means phase 2 failed. The most common cause is a mismatch in the IPsec transform set or the crypto map access list between the two routers.

Practice this question →
45
MCQhard

A network engineer is troubleshooting an IPsec site-to-site VPN where the tunnel is up, but the engineer notices that the 'show crypto ipsec sa' output shows that the number of packets encrypted is much higher than the number of packets decrypted on the remote side. What is the most likely cause?

A.The remote router has a misconfigured route that sends return traffic out the wrong interface.
B.The IPsec SA lifetime is set too low, causing frequent rekeying.
C.The crypto map on the local router is applied to the wrong interface.
D.The access list in the crypto map on the remote router is too permissive, encrypting extra traffic.
AnswerA

Correct because if the remote router does not have a route to the local LAN that points to the tunnel interface, the return traffic will be sent out the physical interface without encryption, and the local router will not see corresponding decrypted packets.

Why this answer

A significant mismatch between encrypted and decrypted packet counts suggests that some packets are being lost or dropped after encryption. The most common cause is a routing issue where the return traffic from the remote side is not taking the VPN tunnel, so the remote router does not decrypt those packets.

Practice this question →
46
MCQmedium

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# debug crypto isakmp *Mar 1 00:01:23.456: ISAKMP (0:0): received packet from 192.168.1.2 dport 500 sport 500 Global (N) NEW SA *Mar 1 00:01:23.457: ISAKMP: Created a peer struct for 192.168.1.2, peer port 500 *Mar 1 00:01:23.457: ISAKMP: New peer created peer = 0x12345678 peer_handle = 0x80000001 *Mar 1 00:01:23.457: ISAKMP: Locking peer struct 0x12345678, refcount 1 for crypto_isakmp_process_block *Mar 1 00:01:23.457: ISAKMP (0:0): SA request profile is (default) *Mar 1 00:01:23.457: ISAKMP: local port 500, remote port 500 *Mar 1 00:01:23.458: ISAKMP (0:0): found peer pre-shared-key matching 192.168.1.2 *Mar 1 00:01:23.458: ISAKMP (0:0): constructed NAT-T vendor ID *Mar 1 00:01:23.458: ISAKMP (0:0): sending packet to 192.168.1.2 my_port 500 peer_port 500 (I) MM_NO_STATE *Mar 1 00:01:23.458: ISAKMP (0:0): received packet from 192.168.1.2 dport 500 sport 500 Global (I) MM_NO_STATE *Mar 1 00:01:23.459: ISAKMP (0:0): processing SA payload. message ID = 0 *Mar 1 00:01:23.459: ISAKMP (0:0): Checking ISAKMP transform 1 against priority 1 policy *Mar 1 00:01:23.459: ISAKMP: encryption DES-CBC *Mar 1 00:01:23.459: ISAKMP: hash SHA *Mar 1 00:01:23.459: ISAKMP: default group 2 *Mar 1 00:01:23.459: ISAKMP: auth pre-share *Mar 1 00:01:23.459: ISAKMP (0:0): atts are not acceptable. Next transforms are not acceptable *Mar 1 00:01:23.460: ISAKMP (0:0): no offers accepted! What does this output indicate?

A.The ISAKMP SA is established successfully using pre-shared key authentication.
B.The ISAKMP transform set proposal is rejected due to a mismatch in encryption, hash, or DH group between peers.
C.The router is receiving the packet from an incorrect source IP address.
D.The router is unable to find a pre-shared key for the peer.
AnswerB

The output clearly states 'atts are not acceptable' and 'no offers accepted', which means the proposed transform does not match the local policy.

Why this answer

The debug output shows that the router received an ISAKMP proposal from the peer (192.168.1.2) and checked it against its own configured policy. The line 'atts are not acceptable' followed by 'no offers accepted' indicates that the transform set attributes (encryption DES-CBC, hash SHA, DH group 2) did not match any of the router's ISAKMP policies. This is a classic proposal mismatch, preventing the ISAKMP SA from being established.

Exam trap

Cisco often tests the distinction between a pre-shared key mismatch (which would show 'no pre-shared key found') and a transform set mismatch (which shows 'atts are not acceptable'), leading candidates to incorrectly blame the PSK when the actual issue is the encryption/hash/DH group.

How to eliminate wrong answers

Option A is wrong because the debug clearly shows 'no offers accepted', meaning the ISAKMP SA was not established; successful establishment would show 'ISAKMP (0:0): SA has been created' or similar. Option C is wrong because the router correctly identifies the source IP as 192.168.1.2 and processes the packet; there is no indication of an incorrect source IP. Option D is wrong because the debug explicitly states 'found peer pre-shared-key matching 192.168.1.2', so the pre-shared key is present and matched.

Practice this question →
47
MCQmedium

A network engineer runs the following command on Router R1: R1# show crypto ipsec sa peer 10.1.1.2 interface: Tunnel0 Crypto map tag: VPN-MAP, local addr 10.1.1.1 protected 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: 100, #pkts encrypt: 100, #pkts digest: 100 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 #send errors 0, #recv errors 0 Based on this output, what is the problem?

A.The tunnel is working correctly; all packets are being encrypted and decrypted.
B.The remote peer is not sending traffic back; check routing on the remote router.
C.The local crypto ACL is misconfigured; it is not matching traffic.
D.The IPsec SA is not established; the tunnel is down.
AnswerB

Outbound packets are being sent but none received; the remote side may not have a route back or the crypto ACL is misconfigured.

Why this answer

The outbound packet count (encaps) is 100, but inbound (decaps) is 0. This suggests that traffic is being sent through the tunnel but no responses are being received, possibly due to a routing issue on the remote side or a firewall blocking return traffic.

Practice this question →
48
MCQhard

An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on the outside interface of a router that terminates an IPsec site-to-site VPN. After the configuration, the VPN tunnel establishes, but traffic from the remote site is not forwarded correctly. The engineer verifies that the IPsec tunnel is up and that the routing table has the correct routes. What is the most likely explanation?

A.The IPsec tunnel uses transport mode, which does not encapsulate the original source IP, causing uRPF to see the remote router's physical IP as the source.
B.The return route for the remote site's physical IP points to the tunnel interface, but the packet arrives on the physical interface, so uRPF drops it because the source IP is not reachable via the incoming interface.
C.The uRPF configuration includes the 'allow-default' option, which allows packets with a default route, but the remote site's IP is not in the default route.
D.The IPsec transform set uses ESP with authentication, which changes the source IP of the packet.
AnswerB

Strict uRPF requires that the source IP of the incoming packet has a route back through the same interface. If the route points to the tunnel, the check fails, and the packet is dropped.

Why this answer

In strict mode, uRPF checks that the source IP address of an incoming packet is reachable via the exact interface on which the packet arrived. For IPsec site-to-site VPN traffic, the encapsulated (original) packet arrives on the physical outside interface, but the routing table's return route for the remote site's physical IP (the tunnel endpoint) points to the tunnel interface (e.g., a virtual tunnel interface or crypto map). Because the source IP is not reachable via the physical incoming interface, uRPF drops the packet, even though the IPsec tunnel is up and the routes are correct.

Exam trap

Cisco often tests the subtle interaction between uRPF strict mode and IPsec VPNs, where candidates mistakenly think the tunnel mode or encryption causes the issue, rather than the interface-specific reverse path check.

How to eliminate wrong answers

Option A is wrong because transport mode does not change the source IP of the original packet; it only encapsulates the IP payload, and uRPF checks the original source IP, not the outer IP header. Option C is wrong because the 'allow-default' option permits packets whose source IP matches a default route, but the remote site's IP is typically a specific address, not a default route, and the core issue is interface mismatch, not default route coverage. Option D is wrong because ESP with authentication (ESP auth) does not alter the source IP address of the packet; it only adds an authentication trailer to the ESP payload, leaving the IP header unchanged.

Practice this question →
49
MCQeasy

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# show crypto isakmp sa detail IPv4 Crypto ISAKMP SA C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap. 1001 192.168.1.1 192.168.2.2 ACTIVE des sha pre 2 23:59:21 1002 192.168.1.1 192.168.2.2 ACTIVE 3des sha pre 2 23:58:15 IPv6 Crypto ISAKMP SA What does this output indicate?

A.The IPsec VPN is functioning correctly with two redundant ISAKMP SAs.
B.There are two active ISAKMP SAs between the peers, which suggests a configuration error such as multiple ISAKMP policies or aggressive mode issues.
C.The ISAKMP SA is using DES encryption, which is weak and should be upgraded.
D.The ISAKMP SA lifetime is about 24 hours, which is the default.
AnswerB

Having two SAs is abnormal; it often results from misconfigured policies or aggressive mode causing duplicate SAs.

Why this answer

The output shows two active ISAKMP SAs between the same peers (192.168.1.1 and 192.168.2.2) with different encryption algorithms (DES and 3DES). Under normal operation, only one ISAKMP SA should exist per peer pair. Having multiple SAs indicates a configuration error, such as multiple ISAKMP policies that both match, or aggressive mode causing duplicate SAs.

This is not a sign of redundancy; ISAKMP SAs are not redundant by design.

Exam trap

Cisco often tests the misconception that multiple active ISAKMP SAs between the same peers are normal or provide redundancy, when in fact they indicate a configuration error that can break the VPN tunnel.

How to eliminate wrong answers

Option A is wrong because ISAKMP SAs are not designed for redundancy; having two active SAs between the same peers indicates a misconfiguration, not a functional redundancy feature. Option C is wrong because while DES is indeed weak, the output shows both DES and 3DES SAs, and the question asks what the output indicates—the core issue is the duplicate SAs, not the encryption strength. Option D is wrong because the lifetimes shown (23:59:21 and 23:58:15) are close to 24 hours, which is the default for ISAKMP, but this is not the key finding; the presence of two SAs is the abnormal condition.

Practice this question →
50
MCQhard

An engineer configures a DMVPN Phase 2 network with IPsec protection. Spoke-to-spoke tunnels form, but traffic between spokes is not being forwarded directly; it still goes through the hub. The engineer verifies that NHRP registrations are successful and that the spoke-to-spoke IPsec sessions are established. What is the most likely explanation?

A.The hub router is not configured with the 'no ip split-horizon' command for EIGRP or the 'neighbor' command for OSPF, preventing spoke-to-spoke route propagation.
B.The IPsec transform set on the spokes uses different encryption algorithms, preventing the spoke-to-spoke tunnel from passing traffic.
C.The NHRP authentication string is mismatched between spokes, causing NHRP resolution to fail.
D.The spoke routers have a static default route pointing to the hub, overriding the dynamic routes.
AnswerA

In DMVPN Phase 2, the hub must disable split horizon (EIGRP) or use a network type that allows route propagation (OSPF) so that spokes learn each other's subnets. Without this, spokes only have a default route via the hub, so traffic goes through the hub.

Why this answer

In a DMVPN Phase 2 network, spoke-to-spoke traffic requires that each spoke learns the remote spoke's prefix via the hub. For EIGRP, the hub must disable split horizon with 'no ip split-horizon eigrp <as>' to propagate routes learned from one spoke to other spokes. Without this, the hub advertises only its own routes, so spokes lack the necessary routing information to forward traffic directly, causing it to be sent through the hub despite working NHRP and IPsec.

Exam trap

Cisco often tests the subtle distinction between NHRP resolution success and actual routing table propagation—candidates assume that if NHRP and IPsec are working, traffic must flow directly, but they overlook the hub's routing protocol configuration that prevents spoke-to-spoke route advertisement.

How to eliminate wrong answers

Option B is wrong because mismatched IPsec transform sets would prevent the spoke-to-spoke IPsec session from establishing, but the scenario states that spoke-to-spoke IPsec sessions are already established. Option C is wrong because mismatched NHRP authentication would cause NHRP registrations and resolutions to fail, but the scenario confirms NHRP registrations are successful. Option D is wrong because a static default route pointing to the hub does not override dynamic routes for specific spoke prefixes; spokes would still use the dynamically learned routes for direct forwarding if they exist.

Practice this question →
51
MCQhard

In Cisco IOS, what is the default IKEv1 phase 1 authentication method when using a pre-shared key and no explicit authentication is configured?

A.RSA encrypted nonces
B.Pre-shared key
C.Digital signatures (RSA-SIG)
D.No default; authentication must be explicitly set
AnswerB

IOS defaults to pre-shared key authentication when not specified.

Why this answer

When no explicit authentication method is configured for IKEv1 phase 1 and a pre-shared key is used, Cisco IOS defaults to 'pre-shared key' authentication. This is because the pre-shared key itself defines the authentication mechanism; the router automatically selects the appropriate authentication method based on the configured key material.

Exam trap

Cisco often tests the misconception that authentication must always be explicitly configured, leading candidates to choose 'No default' when in fact the default is pre-shared key for pre-shared key configurations.

How to eliminate wrong answers

Option A is wrong because RSA encrypted nonces is a distinct IKEv1 authentication method that requires explicit configuration using the 'authentication rsa-encr' command; it is not the default when a pre-shared key is used. Option C is wrong because digital signatures (RSA-SIG) require a PKI certificate and the 'authentication rsa-sig' command; it is never the default for pre-shared key configurations. Option D is wrong because Cisco IOS does have a default authentication method for IKEv1 when a pre-shared key is configured; the default is pre-shared key, so authentication does not need to be explicitly set.

Practice this question →
52
Multi-Selecthard

Which TWO statements about IPsec transform sets and security associations (SAs) are true? (Choose TWO.)

Select 2 answers
A.A transform set can specify ESP encryption and ESP authentication simultaneously.
B.In tunnel mode, the original IP header is preserved and a new IP header is added.
C.Transport mode adds a new IP header to the packet.
D.The command 'crypto ipsec security-association lifetime' sets the IKE SA lifetime.
E.A single IPsec SA provides bidirectional secure communication.
AnswersA, B

Correct. For example, 'transform-set myset esp-aes esp-sha-hmac' provides both.

Why this answer

Option A is correct because an IPsec transform set can specify both ESP encryption (e.g., AES) and ESP authentication (e.g., HMAC-SHA256) simultaneously. This is a standard configuration where ESP provides both confidentiality and integrity/authentication in a single transform set, as defined in RFC 4303.

Exam trap

Cisco often tests the misconception that a single SA is bidirectional, but in reality, IPsec SAs are unidirectional and must be paired for two-way communication.

Practice this question →
53
MCQeasy

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# show crypto ipsec transform-set Transform set combined-des-sha: { esp-des esp-sha-hmac } will negotiate = { Tunnel, }, Transform set myset: { esp-3des esp-sha-hmac } will negotiate = { Tunnel, }, Transform set strong: { esp-aes 256 esp-sha-hmac } will negotiate = { Tunnel, }, What does this output indicate?

A.All transform sets are using strong encryption and are acceptable for production.
B.The transform set 'combined-des-sha' uses DES, which is not recommended due to security vulnerabilities.
C.The transform sets are not configured correctly because they do not specify the mode.
D.The transform set 'strong' is not supported because it uses AES 256.
AnswerB

DES is deprecated and insecure; AES should be used instead.

Why this answer

The output shows three transform sets, including 'combined-des-sha', which uses DES (Data Encryption Standard) with a 56-bit key. DES is considered cryptographically weak and has been deprecated due to known vulnerabilities, such as susceptibility to brute-force attacks. Cisco recommends using AES or 3DES as a minimum for production IPsec VPNs, making option B correct.

Exam trap

Cisco often tests the candidate's awareness of deprecated or weak cryptographic algorithms (like DES) versus strong ones (like AES), and the trap here is assuming that all listed transform sets are equally valid or that the missing mode keyword indicates a misconfiguration.

How to eliminate wrong answers

Option A is wrong because not all transform sets use strong encryption; 'combined-des-sha' uses DES, which is insecure and not recommended for production. Option C is wrong because the transform sets do specify the mode implicitly; the output shows 'will negotiate = { Tunnel, }', indicating that the default tunnel mode is used, and the configuration is valid without explicitly stating the mode in the output. Option D is wrong because AES 256 is fully supported by Cisco IOS and is a strong, recommended encryption algorithm for IPsec.

Practice this question →
54
MCQmedium

A network engineer is troubleshooting an IPsec site-to-site VPN between two routers. The tunnel interface is up/up, but traffic from the local LAN to the remote LAN is not passing. The engineer checks the crypto map and sees it is applied to the outside interface. What is the most likely cause of the traffic failure?

A.The crypto map is not applied to the tunnel interface.
B.The access list in the crypto map does not match the LAN-to-LAN traffic.
C.The IPsec transform set is missing the esp-aes encryption algorithm.
D.The IKE phase 1 proposal is mismatched between the two routers.
AnswerB

Correct because the crypto map uses an access list to define which traffic is encrypted; if it does not match the actual LAN subnets, traffic will be sent unencrypted and may be dropped by the remote router.

Why this answer

The tunnel interface being up/up indicates the GRE tunnel is operational, but traffic may still fail if the crypto map is not correctly triggering IPsec encryption for the actual data traffic. The most common cause is a missing or incorrect access list in the crypto map that defines interesting traffic.

Practice this question →
55
MCQeasy

In IPsec site-to-site VPN, what is the purpose of the 'match address' command under a crypto map?

A.It specifies the peer IP address for the tunnel.
B.It defines the encryption and authentication algorithms.
C.It identifies the traffic that will be encrypted and sent through the tunnel.
D.It sets the lifetime for the IPsec SA.
AnswerC

The ACL defines interesting traffic; only that traffic is protected.

Why this answer

The 'match address' command under a crypto map references an access list (ACL) that defines which traffic should be protected by IPsec. When a packet matches a permit entry in that ACL, it triggers the IPsec process to encrypt and tunnel the traffic to the remote peer. This is the fundamental mechanism for selecting interesting traffic in a site-to-site VPN.

Exam trap

Cisco often tests the distinction between 'match address' (traffic selection) and 'set peer' (tunnel endpoint), leading candidates to confuse the purpose of these two commands under a crypto map.

How to eliminate wrong answers

Option A is wrong because the peer IP address for the tunnel is specified using the 'set peer' command under the crypto map, not 'match address'. Option B is wrong because encryption and authentication algorithms are defined using the 'set transform-set' command, which references an IPsec transform set. Option D is wrong because the lifetime for the IPsec SA is set using the 'set security-association lifetime' command, either globally or under the crypto map, not by 'match address'.

Practice this question →
56
MCQmedium

A network engineer runs the following command on Router R1: R1# show crypto map Crypto Map "VPN-MAP" 10 ipsec-isakmp Peer = 10.1.1.2 Extended IP access list 100 access-list 100 permit ip 10.1.1.0 0.0.0.255 192.168.1.0 0.0.0.255 Current peer: 10.1.1.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ESP-AES256-SHA,} Interfaces using crypto map VPN-MAP: Tunnel0 Based on this output, which statement is correct?

A.The crypto map is applied to interface Tunnel0 and uses ACL 100 to define interesting traffic.
B.Perfect Forward Secrecy (PFS) is enabled.
C.The crypto map uses dynamic IPsec peer discovery.
D.The crypto map is not applied to any interface.
AnswerA

The output shows Tunnel0 uses this crypto map and ACL 100 defines the traffic.

Why this answer

The crypto map is applied to Tunnel0 and uses ACL 100 to match traffic from 10.1.1.0/24 to 192.168.1.0/24. This is a typical site-to-site VPN configuration.

Practice this question →
57
MCQeasy

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# show crypto engine connections active Crypto Engine Connections ID Type Algorithm Encrypt Decrypt LastSeqNo 1 IPsec ESP-3DES+SHA 0 0 0 2 IPsec ESP-3DES+SHA 0 0 0 3 IPsec ESP-AES+SHA 0 0 0 What does this output indicate?

A.The IPsec VPN is actively encrypting and decrypting traffic.
B.The IPsec SAs are established but no traffic is flowing, possibly due to routing or ACL issues.
C.The crypto engine is overloaded and cannot process packets.
D.The IPsec SAs are using the wrong transform set.
AnswerB

Zero packets suggest the SAs are idle; the issue is likely with traffic matching the crypto ACL or routing.

Why this answer

The output shows three IPsec Security Associations (SAs) with zero encrypted and zero decrypted packets, and a LastSeqNo of 0. This indicates the SAs are established (the tunnels are up) but no traffic is being processed through them. The most common causes are routing issues preventing traffic from reaching the tunnel interface, or ACLs that do not match the interesting traffic for encryption.

Exam trap

Cisco often tests the misconception that a non-zero number of SAs in 'show crypto engine connections active' automatically means traffic is flowing, when in fact the Encrypt/Decrypt counters must be checked to confirm actual data processing.

How to eliminate wrong answers

Option A is wrong because the Encrypt and Decrypt counters are both 0, which means no traffic is being encrypted or decrypted; active encryption would show non-zero counts. Option C is wrong because the crypto engine is not overloaded; an overloaded engine would typically show high packet counts or errors, not all zeros. Option D is wrong because the output does not indicate a transform set mismatch; mismatched transform sets would prevent SA establishment entirely, but here the SAs are listed (ID 1, 2, 3), meaning Phase 2 negotiation succeeded.

Practice this question →
58
MCQmedium

A network engineer runs the following command on Router R1: R1# show crypto isakmp sa dst src state conn-id slot status 10.1.1.2 10.1.1.1 MM_NO_STATE 1 0 ACTIVE Based on this output, what is the problem?

A.The IPsec SA is established and working correctly.
B.The IKE phase 1 negotiation has failed; the pre-shared key may be mismatched.
C.The tunnel is up but no interesting traffic is triggering the IPsec SA.
D.The ISAKMP SA is in MM_ACTIVE state, meaning phase 1 is complete.
AnswerB

MM_NO_STATE indicates no ISAKMP SA has been formed, often due to pre-shared key mismatch or firewall blocking UDP 500.

Why this answer

The MM_NO_STATE indicates that the IKE phase 1 negotiation has not progressed past the initial state. This typically means the peer is not responding to the ISAKMP proposals, often due to mismatched pre-shared keys or access-list blocking UDP port 500.

Practice this question →
59
Multi-Selecthard

Which TWO statements about IPsec site-to-site VPN troubleshooting using 'show crypto session' and 'show crypto ipsec sa' are correct? (Choose TWO.)

Select 2 answers
A.'show crypto session' displays the IKEv2 SA status and the IPsec SA status.
B.'show crypto ipsec sa' shows the number of packets that have been encrypted and decrypted.
C.'show crypto isakmp sa' is the correct command to view IKEv2 SAs.
D.The 'pkts encaps' counter in 'show crypto ipsec sa' increments on the inbound SA.
E.'show crypto map' displays the current packet count for each IPsec SA.
AnswersA, B

Correct. This command shows both IKE and IPsec session information.

Why this answer

Option A is correct because the 'show crypto session' command provides a concise summary of both IKEv2 SA (phase 1) and IPsec SA (phase 2) status, including the state (UP-ACTIVE) and peer IP. This makes it a quick troubleshooting tool for verifying that both security associations are established without needing separate commands for each phase.

Exam trap

Cisco often tests the distinction between IKEv1 and IKEv2 commands, so the trap here is that candidates mistakenly use 'show crypto isakmp sa' for IKEv2 SAs, not realizing that IKEv2 has its own dedicated 'show crypto ikev2 sa' command.

Practice this question →
60
MCQhard

R1 and R2 are connected via an IPsec VPN tunnel. They are running EIGRP over the tunnel. R1's show ip eigrp neighbors shows R2 as up, but R1's show ip eigrp topology shows all routes from R2 in passive state. However, R1's show ip route does not have any EIGRP routes from R2. What is the root cause?

A.R2 is using a route-map to set EIGRP metric to 4294967295, making routes inaccessible.
B.EIGRP variance is set to 1, preventing load balancing.
C.The tunnel interface is down on R2.
D.R1 has a passive interface for the tunnel.
AnswerA

EIGRP routes with metric 4294967295 are considered unreachable and are not installed in the routing table, even though they appear in topology.

Why this answer

The EIGRP metric of 4294967295 is the maximum possible metric (32-bit value), effectively making the route unreachable. When R2 applies a route-map to set this metric, R1 receives the routes but considers them inaccessible, so they appear in the topology table as passive (since the neighbor is up and the route is learned) but are not installed in the routing table. This matches the symptoms: neighbor adjacency is established, routes are in the topology table, but no EIGRP routes appear in the IP routing table.

Exam trap

The trap here is that candidates see routes in the EIGRP topology table as passive and assume they are installed in the routing table, but Cisco tests the distinction between the topology table (which stores all learned routes) and the routing table (which only stores feasible successors with valid metrics).

How to eliminate wrong answers

Option B is wrong because EIGRP variance controls load balancing among multiple feasible successors, not the installation of routes into the routing table; a variance of 1 is the default and does not prevent route installation. Option C is wrong because if the tunnel interface were down on R2, R1 would not have an EIGRP neighbor adjacency (show ip eigrp neighbors would show R2 as down or not present). Option D is wrong because if R1 had a passive interface for the tunnel, R1 would not form an EIGRP neighbor relationship with R2 at all, contradicting the fact that R2 is shown as an EIGRP neighbor.

Practice this question →
61
MCQhard

A network engineer is troubleshooting an IPsec site-to-site VPN between two Cisco routers. The tunnel is up, but traffic intermittently drops. The engineer notices that the 'show crypto ipsec sa' output shows the packet counters incrementing for both encrypt and decrypt, but the 'pkts encaps failed' counter is also increasing. What is the most likely cause?

A.The crypto map is not applied to the correct interface.
B.The IPsec transform set is misconfigured with incompatible algorithms.
C.The IKE keepalive timer is too short, causing frequent rekeying.
D.The MTU on the outside interface is too small, causing fragmentation.
AnswerA

Correct because if the route to the remote LAN points to an interface without the crypto map, the router will attempt to send the packet unencrypted, resulting in encapsulation failure.

Why this answer

The 'pkts encaps failed' counter indicates that the router is unable to encrypt packets that should be encrypted. This typically happens when the crypto map's access list matches traffic, but the route to the remote LAN points out an interface that does not have the crypto map applied, causing the router to try to send the packet without encryption.

Practice this question →
62
MCQhard

In IPsec site-to-site VPN, what is the default Diffie-Hellman (DH) group used in IKEv1 phase 1 on Cisco IOS?

A.DH group 1 (768-bit)
B.DH group 2 (1024-bit)
C.DH group 5 (1536-bit)
D.No default DH group; negotiation fails if not set
AnswerA

When no DH group is specified in IKE policy, Cisco IOS defaults to group 1.

Why this answer

In Cisco IOS, the default Diffie-Hellman group for IKEv1 Phase 1 is DH group 1 (768-bit). This is defined in the default ISAKMP policy (policy 100) that is automatically present when no custom policy is configured. If no DH group is explicitly specified, the router uses group 1 by default, which provides the lowest security level but ensures backward compatibility.

Exam trap

Cisco often tests the fact that there is a default DH group (group 1) in IKEv1 Phase 1, leading candidates to incorrectly assume that no default exists or that a stronger group like 2 or 5 is the default.

How to eliminate wrong answers

Option B is wrong because DH group 2 (1024-bit) is not the default; it must be explicitly configured using the 'crypto isakmp policy' command with 'group 2'. Option C is wrong because DH group 5 (1536-bit) is a stronger option but is never the default; it also requires explicit configuration. Option D is wrong because there is a default DH group (group 1) in IKEv1 Phase 1 on Cisco IOS; negotiation does not fail if no group is set—the router uses the default policy.

Practice this question →
63
MCQmedium

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?

A.Verify that the crypto map is correctly applied to the outside interface.
B.Check the IP connectivity between the two public IP addresses using ping.
C.Check the IPsec transform set configuration on both routers.
D.Verify the pre-shared key is identical on both routers.
AnswerB

Correct because without basic IP reachability, IKE packets cannot be exchanged, and the VPN cannot establish.

Why this answer

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.

Practice this question →
64
Multi-Selectmedium

Which TWO statements about IPsec site-to-site VPN configuration using IKEv1 are true? (Choose TWO.)

Select 2 answers
A.IKEv1 phase 1 establishes the ISAKMP SA, which is bidirectional.
B.IKEv1 phase 2 uses the crypto isakmp policy to negotiate IPsec SAs.
C.The 'crypto isakmp policy' command configures authentication, encryption, and DH group for phase 1.
D.IPsec SAs are unidirectional and require two SAs per tunnel.
E.The 'crypto ipsec transform-set' command defines the IKEv1 phase 1 policy.
AnswersA, C

Phase 1 creates a bidirectional ISAKMP SA used to protect IKE negotiations.

Why this answer

IKEv1 phase 1 establishes the ISAKMP Security Association (SA), which is used to securely negotiate the IPsec SAs in phase 2. This ISAKMP SA is bidirectional, meaning a single SA protects both inbound and outbound IKE traffic between the peers.

Exam trap

Cisco often tests the distinction between IKEv1 phase 1 (ISAKMP SA, bidirectional) and phase 2 (IPsec SAs, unidirectional), and candidates frequently confuse which commands apply to each phase, especially the 'crypto isakmp policy' versus 'crypto ipsec transform-set' commands.

Practice this question →
65
Multi-Selecthard

Which TWO statements correctly describe the use of IKEv2 for IPsec site-to-site VPNs? (Choose TWO.)

Select 2 answers
A.IKEv2 uses UDP port 500 and 4500 for NAT traversal.
B.IKEv2 supports only pre-shared keys for authentication.
C.IKEv2 uses aggressive mode to establish the IKE SA.
D.IKEv2 can authenticate using EAP (Extensible Authentication Protocol).
E.The default IKEv2 SA lifetime is 3600 seconds.
AnswersA, D

Correct. IKEv2 uses UDP 500 for initial exchanges and UDP 4500 when NAT is detected.

Why this answer

Option A is correct because IKEv2 uses UDP port 500 for initial IKE SA establishment and port 4500 for NAT traversal (encapsulating IPsec packets in UDP to pass through NAT devices). This is a standard behavior defined in RFC 7296, ensuring compatibility with NAT environments.

Exam trap

Cisco often tests the misconception that IKEv2 uses aggressive mode (like IKEv1) or that its default SA lifetime is 3600 seconds, when in fact IKEv2 uses a simpler exchange and a 24-hour default lifetime.

Practice this question →
66
MCQmedium

Which statement correctly describes the default behavior of Dead Peer Detection (DPD) in Cisco IOS for IPsec site-to-site VPN?

A.DPD is enabled by default with a 10-second interval
B.DPD is enabled by default with a 30-second interval
C.DPD is disabled by default
D.DPD is enabled only for IKEv2 by default
AnswerC

Cisco IOS requires explicit configuration to enable DPD.

Why this answer

Dead Peer Detection (DPD) is disabled by default in Cisco IOS for IPsec site-to-site VPNs. This means that without explicit configuration using the 'crypto isakmp keepalive' command, the router will not send DPD messages to verify the liveness of the remote peer. DPD must be manually enabled to detect peer failures and trigger failover or tunnel teardown.

Exam trap

Cisco often tests the misconception that DPD is enabled by default or that it has a fixed interval, when in fact it must be manually configured and the default state is disabled.

How to eliminate wrong answers

Option A is wrong because DPD is not enabled by default with a 10-second interval; DPD is disabled by default, and if enabled, the interval is configurable but not a fixed 10 seconds. Option B is wrong because DPD is not enabled by default with a 30-second interval; again, DPD is disabled by default, and the interval is not preset to 30 seconds. Option D is wrong because DPD is not enabled only for IKEv2 by default; DPD is disabled by default for both IKEv1 and IKEv2, and it must be explicitly configured for either version.

Practice this question →
67
MCQmedium

A network engineer is troubleshooting an IPsec site-to-site VPN that uses a GRE tunnel over IPsec. The GRE tunnel is up/up, but the routing protocol (EIGRP) running over the GRE tunnel is not forming an adjacency. The engineer checks the tunnel configuration and sees that the tunnel source and destination are correct. What is the most likely cause?

A.The crypto map access list does not match GRE protocol (47) traffic.
B.The EIGRP hello timer is set too high.
C.The tunnel interface is not configured with an IP address.
D.The IPsec transform set does not include ESP encryption.
AnswerA

Correct because GRE uses protocol 47; if the crypto map's access list only matches IP traffic between the LAN subnets, the GRE packets themselves are not encrypted and are dropped, causing the GRE tunnel to appear up but the routing protocol to fail.

Why this answer

For a GRE over IPsec tunnel, the GRE tunnel must be protected by the crypto map. If the crypto map is applied to the physical interface but the GRE tunnel traffic is not matched by the crypto map's access list, the GRE packets will be sent unencrypted and the remote router will drop them, preventing the routing protocol from forming an adjacency.

Practice this question →
68
MCQmedium

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# show crypto ipsec sa detail interface: Tunnel0 Crypto map tag: CMAP, local addr 192.168.1.1 protected vrf: (none) local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0) current_peer 192.168.2.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 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.2.2 path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0 current outbound spi: 0x0(0) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0x0(0) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } conn id: 0, flow_id: 0, sibling_flags 80000000, crypto map: CMAP sa timing: remaining key lifetime (k/sec): (0/0) IV size: 8 bytes replay detection support: N outbound esp sas: spi: 0x0(0) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } conn id: 0, flow_id: 0, sibling_flags 80000000, crypto map: CMAP sa timing: remaining key lifetime (k/sec): (0/0) IV size: 8 bytes replay detection support: N What does this output indicate?

A.The IPsec SA is fully established and encrypting traffic.
B.The IPsec SA is in a pending state; the SPI is 0, meaning the SA negotiation is incomplete or the SA has been deleted.
C.The IPsec SA is using PFS, which is causing the SA to be rekeyed frequently.
D.The crypto map is not applied to the interface, so the SA is not used.
AnswerB

SPI of 0 and zero lifetime indicate the SA is not active; it may have been cleared or never completed.

Why this answer

The output shows SPI values of 0x0 for both inbound and outbound ESP SAs, with zero packet encapsulation and encryption counts. This indicates that the IPsec Security Association (SA) negotiation is incomplete or the SA has been deleted, as a valid SA would have a non-zero SPI and active packet counters. The 'current_peer' and crypto map are present, but the SA is not operational.

Exam trap

Cisco often tests the misconception that a crypto map present in the output means the SA is active, but the SPI of 0x0 and zero packet counters are the definitive indicators of an incomplete or deleted SA.

How to eliminate wrong answers

Option A is wrong because the SPI of 0x0 and zero packet counters clearly show the IPsec SA is not established or encrypting traffic; a fully established SA would have non-zero SPIs and increasing packet counts. Option C is wrong because the output explicitly shows 'PFS (Y/N): N, DH group: none', indicating PFS is not enabled, so it cannot be causing frequent rekeying. Option D is wrong because the crypto map tag 'CMAP' is listed under interface Tunnel0, confirming the crypto map is applied to the interface, but the SA is not active.

Practice this question →
69
MCQhard

An engineer configures Control Plane Policing (CoPP) on a router that terminates multiple IPsec site-to-site VPN tunnels. After applying the CoPP policy, some IPsec tunnels fail to establish, while others work fine. The engineer verifies that the CoPP policy permits IKE (UDP 500) and ESP (protocol 50) traffic. What is the most likely cause of the failure?

A.The CoPP policy uses the 'class class-default' with a police action that drops traffic exceeding a low rate, and IKE/ESP packets are being classified into class-default because the ACL does not match them correctly.
B.The CoPP policy is applied to the wrong interface; it should be applied to the tunnel interface.
C.The IPsec tunnels use IKEv2, which uses UDP port 4500, and the CoPP policy only permits UDP 500.
D.The CoPP policy rate-limits traffic in bps, but IKE/ESP traffic is bursty, causing drops during the initial exchange.
AnswerA

If the ACL for the IKE/ESP class is misconfigured (e.g., wrong port or protocol), the packets fall into class-default, which may have a police or drop action, causing tunnel establishment to fail.

Why this answer

The most likely cause is that the CoPP ACL does not correctly match IKE (UDP 500) and ESP (protocol 50) packets, causing them to fall into the 'class-default' class. If the 'class-default' has a police action that drops traffic exceeding a low rate, these critical control-plane packets are dropped, preventing IPsec tunnel establishment. This explains why some tunnels work (those that happen to generate less traffic or are not rate-limited) while others fail.

Exam trap

Cisco often tests the concept that CoPP misclassification into class-default with a restrictive police action is a common cause of partial IPsec tunnel failures, leading candidates to overlook ACL matching errors and instead focus on interface application or protocol versions.

How to eliminate wrong answers

Option B is wrong because CoPP is applied to the control plane, not to interfaces; applying it to a tunnel interface would be incorrect and would not affect control-plane policing. Option C is wrong because IKEv2 can use UDP 500 for initial exchange and only switches to UDP 4500 if NAT traversal is detected; the question states the policy permits UDP 500, so this would not cause failure for all tunnels. Option D is wrong because CoPP rate-limits in packets per second (pps) by default, not bps, and while bursty traffic can cause drops, the core issue is misclassification into class-default, not the rate-limiting unit.

Practice this question →
70
Drag & Drophard

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5

Why this order

Start by verifying basic IP connectivity between peers, then check that the crypto isakmp policy and IKE proposals match. Next, confirm tunnel interface configuration and ACLs, then inspect IKE and IPsec SA states. Finally, enable debugs to isolate the specific failure.

Practice this question →
71
MCQhard

R1 and R2 are connected via a point-to-point serial link running OSPF. R1 has an IPsec tunnel protecting traffic between loopback0 (10.1.1.1/32) and R2's loopback0 (10.2.2.2/32). The crypto map is applied to the physical serial interface. OSPF adjacencies form, but routes are not installed correctly. R1's show ip route ospf shows a route to 10.2.2.2/32 via the serial interface, not the tunnel. What is the root cause?

A.The crypto map is applied to the physical serial interface instead of the tunnel interface.
B.OSPF network type on the serial interface is point-to-point, causing route preference over tunnel.
C.The tunnel interface has an incorrect IP address.
D.The IPsec transform set does not include ESP authentication.
AnswerA

Applying crypto to the physical interface encrypts OSPF traffic on that link, causing OSPF to form adjacency over the physical interface and install routes via the serial link, bypassing the tunnel.

Why this answer

When a crypto map is applied to the physical serial interface, IPsec encrypts the OSPF packets before they are sent, but the routing table still sees the next-hop via the physical interface (serial) rather than the tunnel interface. OSPF installs the route to 10.2.2.2/32 with the serial interface as the outgoing interface because the tunnel interface is not used for routing decisions; the route is learned via the physical interface adjacency. To have the route point to the tunnel interface, the crypto map must be applied to the tunnel interface (or a virtual tunnel interface like a GRE/IPsec tunnel) so that OSPF runs over the tunnel and installs the route via the tunnel interface.

Exam trap

Cisco often tests the misconception that applying a crypto map to the physical interface automatically makes OSPF routes point to the tunnel interface, but in reality, the routing table uses the interface over which the adjacency was formed, which remains the physical interface unless a tunnel interface is used.

How to eliminate wrong answers

Option B is wrong because the OSPF network type point-to-point on the serial interface does not cause route preference over the tunnel; it simply affects neighbor discovery and LSA flooding, not the interface used in the routing table. Option C is wrong because an incorrect IP address on the tunnel interface would prevent the tunnel from coming up or OSPF from forming an adjacency, but the question states OSPF adjacencies form, so the IP address is correct. Option D is wrong because the IPsec transform set lacking ESP authentication would cause IPsec to fail to establish or decrypt packets, but OSPF adjacencies form, indicating IPsec is working; authentication is not required for OSPF route installation.

Practice this question →
72
Multi-Selecthard

Which TWO actions will prevent an IPsec site-to-site VPN tunnel from coming up when using IKEv2 and pre-shared keys? (Choose TWO.)

Select 3 answers
A.The pre-shared key configured on one router does not match the key on the peer.
B.An ACL on the router's outside interface blocks UDP port 500.
C.An ACL on the router's outside interface blocks UDP port 4500.
D.The IPsec SA lifetime is set to 3600 seconds on one router and 7200 seconds on the peer.
E.The transform set on one router uses ESP-AES and the peer uses ESP-3DES.
AnswersA, B, E

Correct. Authentication will fail, and the IKE SA will not be established.

Why this answer

Option A is correct because IKEv2 uses pre-shared keys (PSK) for authentication during the IKE_SA_INIT exchange. If the PSK configured on one router does not match the key on the peer, the authentication check fails, and the IKEv2 session is terminated before any IPsec SAs can be established. This mismatch directly prevents the VPN tunnel from coming up.

Exam trap

Cisco often tests the misconception that blocking UDP port 4500 alone will prevent the tunnel, but the trap is that NAT-T uses port 4500 only after detecting NAT, and the initial IKE exchange always requires UDP port 500, so blocking only port 4500 does not stop the tunnel unless NAT is present and the router fails to negotiate port 500 fallback.

Practice this question →
73
MCQhard

A large enterprise is using a DMVPN Phase 2 hub-and-spoke topology with IPsec protection. Spoke routers R3 and R4 are both behind NAT. The hub R1 has a tunnel interface with IPsec profile and mGRE. Spoke-to-spoke dynamic tunnels do not form. R3 can ping R4's tunnel IP via the hub, but R3's show dmvpn detail shows no NHRP redirect or shortcut. R4's show crypto ipsec sa shows no inbound/outbound SA for the R3-to-R4 traffic. What is the root cause?

A.The hub is missing the 'ip nhrp redirect' command under the tunnel interface.
B.The IPsec profile on the hub does not include perfect forward secrecy (PFS).
C.The spokes are using different ISAKMP policies.
D.The NAT traversal feature is disabled on the hub.
AnswerA

Without NHRP redirect, the hub does not inform spokes of peer public addresses, preventing dynamic spoke-to-spoke tunnel formation.

Why this answer

In a DMVPN Phase 2 topology, spoke-to-spoke dynamic tunnels require the hub to send NHRP redirect messages to inform a spoke that the destination it is trying to reach is behind another spoke. Without the 'ip nhrp redirect' command on the hub's tunnel interface, the hub forwards traffic between spokes but never signals the source spoke to initiate a direct tunnel. This explains why R3 can ping R4's tunnel IP via the hub but no NHRP redirect or shortcut is seen, and no IPsec SA is built between the spokes.

Exam trap

Cisco often tests the distinction between DMVPN Phase 2 and Phase 3, where Phase 3 uses 'ip nhrp redirect' on the hub and 'ip nhrp shortcut' on spokes, and candidates may incorrectly assume that spoke-to-spoke tunnels form automatically without explicit NHRP redirect configuration.

How to eliminate wrong answers

Option B is wrong because PFS (Perfect Forward Secrecy) is not required for DMVPN Phase 2 spoke-to-spoke tunnel establishment; PFS is an optional security enhancement for IPsec key exchange and does not affect NHRP redirect or shortcut creation. Option C is wrong because if the spokes were using different ISAKMP policies, they would not be able to form IPsec SAs with the hub at all, but the problem states that R3 can ping R4's tunnel IP via the hub, indicating that both spokes have working IPsec tunnels to the hub. Option D is wrong because NAT traversal (NAT-T) is automatically enabled in IOS when a NAT device is detected and is not a command that needs to be explicitly enabled on the hub; disabling it would prevent the hub from establishing tunnels with NATed spokes, but the spokes already have connectivity to the hub.

Practice this question →
74
Drag & Dropmedium

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.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5

Why this order

Begin by checking the IKE Phase 1 SA to ensure the control plane is established, then verify the IPsec Phase 2 SA for data-plane encryption. Confirm the tunnel interface is up/up, examine the crypto map to ensure it is active, and finally test traffic flow with a ping or extended ping.

Practice this question →
75
MCQmedium

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?

A.The IPsec SA is established successfully with ESP 3DES and SHA.
B.The transform set on the remote peer does not match the local transform set, causing IPsec SA negotiation to fail.
C.The ACL for the crypto map is misconfigured, causing the traffic to not match.
D.The IKE phase 1 SA is not established before IPsec negotiation.
AnswerB

The debug explicitly states the proposal is not supported, meaning a mismatch in transform set.

Why this answer

The debug output shows that the IPsec SA request is generated, but the transform proposal (esp-3des esp-sha-hmac) is rejected with 'not supported for proxy'. This indicates that the remote peer does not support or is configured with a different transform set, causing the proposal to fail validation. The SA is created with placeholder SPIs (0x1234, 0x5678) but no actual inbound/outbound SPI, confirming negotiation failure due to transform set mismatch.

Exam trap

Cisco often tests the distinction between IKE phase 1 and phase 2 failures; the trap here is that candidates might assume the SA creation message with SPIs indicates success, but the 'no inbound or outbound SPI' line reveals the SA is incomplete, pointing to a transform set mismatch rather than ACL or IKE phase 1 issues.

How to eliminate wrong answers

Option A is wrong because the debug clearly shows 'proposal doesn't match' and 'no inbound or outbound SPI', meaning the SA is not established successfully. Option C is wrong because the debug output shows the correct proxy identities (src=192.168.1.0/24, dst=192.168.2.0/24), indicating the ACL is matching traffic; the failure is at the transform proposal validation stage, not ACL misconfiguration. Option D is wrong because the debug output shows an IPsec SA request is being processed, which implies IKE phase 1 (ISAKMP SA) has already been established; if IKE phase 1 were not up, the debug would not reach the IPsec SA negotiation stage.

Practice this question →
Page 1 of 2 · 76 questions totalNext →

Ready to test yourself?

Try a timed practice session using only IPsec Site-to-Site VPN questions.

Start 20-question session