Skip to content
AvailabilitySign inBook a DemoJoin Waitlist
All CCNP topics

2.0 VPN Technologies

IPsec & IKEv2 Practice Questions

IKEv2 peering/authentication, IPsec transform sets, and DMVPN tunnel protection.

One solved question, so you can see how these are marked

What information does an IKEv2 keyring store when a DMVPN design uses pre-shared-key authentication?

Pre-shared keys mapped to peer identities or address ranges, so different remote peers can be matched to different keys

An IKEv2 keyring holds one or more peer blocks, each matching a remote address or address range and associating a pre-shared key with it, which lets a single router use different PSKs for different remote peers instead of one global key.

Every question in the set below is marked like this. The answers stay hidden until you pick one.

All 19 IPsec & IKEv2 questions in this set

Answers and explanations appear when you work through the set above.

  1. A hub needs to accept IKEv2 sessions from many spokes whose addresses are not known in advance, using a single shared PSK for all of them. How should the keyring peer entry be written?

    • One peer statement per spoke, listed individually with a /32 mask
    • A single peer entry that matches a wildcard or summarized address range covering the spoke address space, with one shared pre-shared-key value
    • The keyring cannot support unknown peers; certificates are mandatory in this scenario
    • A peer entry with no address match at all, since IKEv2 always falls back to the default keyring

  2. What does an IKEv2 profile primarily define, as distinct from an IKEv2 keyring?

    • Only the ESP encryption algorithm used for the data plane
    • The set of nonnegotiable parameters for a peer relationship: identity/address matching criteria, local and remote authentication methods, and which keyring to use
    • The routing protocol and metric used across the resulting tunnel
    • The physical interface used as the tunnel source

  3. Which IKEv2 profile command family specifies how the local router proves its own identity to the remote peer?

    • authentication remote
    • authentication local
    • match identity remote
    • keyring local

  4. An IKEv2 profile is configured with authentication local pre-share and authentication remote pre-share, but the tunnel never negotiates. The keyring has a correctly matching peer entry. What else must the profile reference for PSK authentication to succeed?

    • A trustpoint pointing to a CA certificate
    • The keyring itself, via the keyring local command inside the profile
    • An access list permitting UDP/500 and UDP/4500
    • A transform set matching the peer's proposal

  5. A DMVPN spoke's tunnel source sits behind a front-door VRF (FVRF) named INTERNET. What must the IKEv2 profile include for negotiation to succeed?

    • A match fvrf INTERNET statement so IKEv2 looks up the peer in the correct VRF routing table
    • An ip vrf forwarding INTERNET command applied to the profile's virtual-template interface only
    • Nothing extra; IKEv2 always negotiates in the global routing table regardless of FVRF
    • A separate keyring per VRF is mandatory even when addresses do not overlap

  6. What does an IPsec transform set define?

    • The peer's authentication method and identity
    • The ESP/AH encryption and integrity algorithms to use, and whether the encapsulation is tunnel or transport mode
    • The DMVPN NHRP redirect behavior
    • The IKEv2 Diffie-Hellman group used during rekey

  7. Why is IPsec transport mode generally preferred over tunnel mode when protecting a GRE-based DMVPN tunnel?

    • Transport mode is mandatory for any traffic using ESP
    • GRE already provides its own outer IP header for delivery, so encrypting only the GRE payload in transport mode avoids adding a second, redundant outer IP header that tunnel mode would add
    • Transport mode supports multicast while tunnel mode does not
    • Transport mode removes the need for a tunnel protection profile

  8. What does an IPsec profile combine, in the context of a GRE/DMVPN protection design?

    • An access list and a crypto map sequence number
    • A transform set and the IKEv2 profile (or ISAKMP profile) that governs key negotiation, referenced together so the tunnel interface can protect traffic without a legacy crypto map
    • An NHRP network-id and a tunnel key
    • A route-map and a prefix-list used for redistribution

  9. Which interface-level command actually applies IPsec protection to a DMVPN GRE tunnel interface?

    • crypto map DMVPN-MAP applied under the tunnel interface
    • tunnel protection ipsec profile <profile-name>
    • ip nhrp map protection
    • crypto ipsec transform-set applied directly under the tunnel interface

  10. Which command shows negotiated IPsec security associations, including SPI values and encryption/authentication transforms in use, beyond the summary that show dmvpn detail provides?

    • show crypto isakmp policy
    • show crypto ipsec sa
    • show ip nhrp detail
    • show dmvpn

  11. In show dmvpn detail output, the encrypted and decrypted packet counters for a spoke's crypto session are steadily incrementing. What does this confirm?

    • That the NHRP registration interval has been reached
    • That user traffic is actually being encrypted/decrypted and traversing the protected tunnel, not just that Phase 1 IKE negotiation succeeded
    • That the spoke is running DMVPN Phase 3
    • That the transform set matches on both ends

  12. What does the IPsec anti-replay window control, and where is it configured?

    • It limits how many IKEv2 SA rekeys can occur before requiring reauthentication, configured under the IKEv2 profile
    • It defines how large a range of out-of-order but still valid sequence numbers is tolerated before a packet is dropped as a suspected replay, configured under the crypto IPsec security-association parameters (globally or per crypto map/profile)
    • It sets the maximum number of DMVPN spokes a hub can register, configured under the tunnel interface
    • It is not configurable and is fixed by the transform set

  13. Two routers negotiate IKEv2 successfully (show crypto ikev2 sa shows the SA up), but no traffic gets encrypted and show crypto ipsec sa shows zero packet counts on both sides. What is the most likely explanation?

    • The IKEv2 profile is missing an authentication remote statement
    • Interesting traffic never matched, or on a GRE/DMVPN tunnel the tunnel interface itself is down or not passing packets, so IPsec has nothing to protect even though the control-plane session is healthy
    • The transform set uses AES instead of 3DES
    • The pre-shared key is incorrect

  14. During IKEv2 negotiation, a hub's proposal offers AES-256/SHA-256/DH group 14 while a spoke's proposal offers AES-128/SHA-1/DH group 2, with no overlapping matching set configured on either side. What is the outcome?

    • IKEv2 automatically negotiates a hybrid of the two proposals
    • Negotiation fails because IKEv2 requires the initiator and responder to agree on a single common transform set out of their offered proposals; if none of the offered combinations match, no SA is formed
    • The tunnel forms using the stronger of the two proposals automatically
    • The tunnel forms in clear text since IKEv2 falls back to no encryption

  15. Which authentication approach lets a hub authenticate hundreds of DMVPN spokes without maintaining a matching PSK entry for every individual spoke address?

    • A single global PSK configured with crypto isakmp key applied to all peers, ignoring identity
    • RSA signature (certificate-based) authentication using a shared trustpoint/CA, since each spoke authenticates with its own certificate rather than a shared secret tied to its address
    • Disabling authentication remote entirely
    • Using AH instead of ESP

  16. A network engineer wants asymmetric authentication, where the hub authenticates to spokes using a certificate but spokes authenticate to the hub with a pre-shared key. Is this supported, and where would it be configured?

    • No, IKEv2 requires the same authentication method on both sides of a session
    • Yes; the IKEv2 profile's authentication local and authentication remote statements are independent, so local can use rsa-sig while remote uses pre-share (or vice versa)
    • Yes, but only in IKEv1, not IKEv2
    • Yes, but it requires two separate IKEv2 profiles per peer

  17. Which UDP ports must be reachable across the underlay path (and through any intervening firewall or NAT device) for IKEv2 and NAT-Traversal encapsulated ESP to establish successfully?

    • UDP/500 for IKE and UDP/4500 for NAT-T encapsulated ESP
    • TCP/500 and TCP/4500 only
    • UDP/50 for ESP and UDP/51 for AH
    • UDP/1701 and UDP/1723

  18. A DMVPN hub is being migrated from IKEv1 to IKEv2. Which existing configuration elements can still be reused largely unchanged?

    • Nothing; IKEv2 requires a completely separate crypto stack including new transform sets and IPsec profiles
    • The IPsec transform set and the tunnel protection ipsec profile application on the tunnel interface, since those are IKE-version-agnostic; what changes is the ISAKMP policy being replaced with an IKEv2 proposal/policy/profile/keyring set
    • The NHRP network-id, since it must change to match the new IKE version
    • The routing protocol configuration, which must be rebuilt for IKEv2

  19. A spoke's tunnel passes traffic normally but briefly drops at each periodic SA renewal. What should be investigated first?

    • The spoke's NHRP network-id changing automatically
    • Rekey failure or mismatched IKEv2/IPsec lifetimes, because a successful rekey should overlap SAs and avoid a recurring traffic interruption
    • A duplicate IP address on the tunnel subnet
    • The hub exceeding its NHRP cache size