CCNA VPN Technologies Questions

The key server is a central component that manages group policies, generates and distributes keys, and authenticates group members. It uses the Group Domain of Interpretation (GDOI) protocol to securely send the GSA to members. Without a key server, group members cannot obtain the necessary keys to encrypt or decrypt traffic, making it a mandatory element in GET VPN deployments.

The show interfaces tunnel 0 command displays detailed information about the tunnel interface, including its status, encapsulation (GRE/IP), source and destination addresses, and other parameters. This command is essential for verifying that the tunnel is up and configured correctly. It provides the necessary details to confirm operational status and encapsulation type.

This is correct because the crypto ACL defines interesting traffic that should be encrypted. It must permit the specific source/destination subnet pair and implicitly deny everything else. The implicit deny ensures other traffic is not encrypted, and the ACL is used to match traffic for the VPN.

In FlexVPN, the IKEv2 keyring can contain multiple peer entries, each with a different pre-shared key and a match statement for the spoke's identity (e.g., IP address). This allows the hub to use a unique key for each spoke while maintaining a single keyring. The IKEv2 profile references this keyring, and the hub selects the appropriate key based on the peer's identity. This is the correct and scalable approach.

In FlexVPN, the IKEv2 authorization policy carries attributes such as the DNS server, the virtual IP pool, and the split-tunnel ACL that the headend pushes to the spoke. When the IKEv2 profile references the authorization policy, the headend can return the DNS server address in the IKE_AUTH exchange. This is the correct mechanism for delivering the requested DNS attribute to each spoke.

The QM FSM error during quick mode often indicates that the responder cannot find a matching transform set for the Phase 2 proposal. If the initiator offers a transform set that the responder does not support or has not configured, the responder may send a delete or fail to process the quick mode exchange, leading to the QM FSM error on the initiator.

The show crypto ipsec transform-set command lists all configured IPsec transform sets, including the name and the specific protocols and algorithms (e.g., esp-aes, esp-sha-hmac). This allows the engineer to compare the transform set on both routers and identify any mismatch in encryption or authentication algorithms that would cause Phase 2 negotiation to fail. It is the most direct way to verify the configured IPsec proposal.

NHRP redirect is a Phase 3 DMVPN feature where the hub sends an NHRP redirect message to the source spoke when it detects traffic that could be sent directly to another spoke. This enables the spoke to initiate an NHRP resolution for the destination spoke's NBMA address and build a direct tunnel, optimizing the path.

The set vrf command under a crypto map entry specifies the VRF that the IPsec tunnel will use for forwarding. It ensures that the encrypted traffic is routed within the correct VRF, enabling VRF-aware IPsec. This is the correct command to bind the tunnel to a VRF.

Phase 2 (IPsec SA) requires both peers to agree on the transform set, which specifies the encryption and integrity algorithms. The mismatch between esp-sha256-hmac and esp-sha512-hmac prevents the IPsec SA from being established. Configuring identical transform sets on both routers, such as esp-aes 256 esp-sha256-hmac, ensures both peers propose and accept the same algorithms, allowing Phase 2 to complete successfully.

The ip nhrp redirect command on the hub enables NHRP redirect messages, which inform the originating spoke that a better path exists directly to the destination spoke. This triggers the spoke to send an NHRP resolution request for the destination's NBMA address, allowing the spoke to build a direct tunnel, which is the defining behavior of DMVPN Phase 3.

GDOI is the Group Domain of Interpretation protocol used by GET VPN. The key server distributes the Group Encryption Key (used for traffic encryption) and the Group Anti-Replay key to all group members, enabling any group member to decrypt traffic from any other member without direct IPsec tunnels between them.

In DMVPN Phase 3, the hub uses ip nhrp redirect to inform a spoke that a better path exists directly to the destination spoke. When the hub receives a packet from one spoke destined to another, it sends an NHRP redirect message to the source spoke, which then initiates an NHRP resolution for the destination spoke's NBMA address. This enables spoke-to-spoke direct tunnels while the hub still advertises a default route, exactly as required.

Pinging the tunnel destination IP verifies reachability to the remote tunnel endpoint's physical interface. If the ping fails, the tunnel cannot pass traffic because the underlying transport is down. This is the first step to confirm connectivity before troubleshooting the tunnel itself.

In GET VPN, the key server manages the GDOI protocol and distributes encryption keys to group members. The `rekey` command configures the key server to send rekey messages, which contain new keys or policies, to group members. This ensures that group members can update their keys without re-registering, maintaining secure communication.

For GRE over IPsec, the crypto ACL must match the GRE packets, which are protocol 47. The ACL should permit GRE between the tunnel source and destination IPs. This ensures that the GRE-encapsulated packets are encrypted by IPsec. Without matching GRE, the tunnel traffic would not be encrypted.

Even if the IPsec tunnel is up, traffic will not pass if the router does not have a route to the remote subnet via the tunnel. The crypto ACL defines interesting traffic, but without a proper route, packets are either dropped or sent via the default route, not encrypted. This is a common oversight in site-to-site VPN configurations.

A crypto ACL (access control list) is used to define which traffic is protected by IPsec. It specifies the source and destination addresses and ports that should be encrypted. Traffic matching the ACL is sent through the IPsec tunnel, while traffic not matching is sent in clear text. This is the standard method to identify interesting traffic in Cisco IOS IPsec configurations.

Phase 2 failure often results from a mismatch in the IPsec transform set or profile, which defines the encryption and integrity algorithms for the data plane. If the transform sets do not match, the peers cannot agree on the IPsec SA parameters, and Phase 2 fails. Checking and aligning the transform set or profile on both routers is a critical troubleshooting step for this scenario.

'show interfaces tunnel 0' displays the tunnel interface status, including the source and destination addresses, and the tunnel protocol. It verifies that the tunnel source and destination are correctly configured and that the tunnel is up. If the tunnel is up but pings fail, it could be a routing issue over the tunnel.

NHRP redirect on the hub and NHRP shortcut on the spokes enable Phase 3 DMVPN. The hub sends redirect messages to spokes when traffic is received on the same tunnel interface, allowing the spoke to dynamically build a direct tunnel to the destination spoke. This reduces latency and hub load.

In FlexVPN, the IKEv2 authorization policy defines what an authenticated peer is allowed to receive, including the address pool used to assign an IP address to the spoke's virtual access interface. The hub references this policy in the IKEv2 profile so that after successful authentication the spoke is authorized and receives an address. This is the correct element for post-authentication address assignment.

For NHRP shortcut to install a direct path, the spoke must have a route pointing to the destination prefix through the tunnel, causing the packet to trigger an NHRP resolution request. Without reachability to the destination spoke subnet (often via a hub summary or default route), no resolution is triggered and traffic continues to hairpin through the hub.

Each group member needs a 'crypto gdoi group' configuration that includes the group identity number and the key server address, plus a 'crypto map' or 'crypto gdoi' reference. Without this, the member cannot initiate registration with the key server or match the group policy, so it never receives the group keys and cannot decrypt GET VPN traffic.

In IKEv1 main mode, the Phase 2 quick mode negotiation uses the crypto ACL to identify the traffic to protect, and the proxy IDs must be mirror images. If the source and destination subnets are reversed or mismatched, the peers cannot agree on the IPSec SA selectors, causing quick mode to fail even though Phase 1 is up and transform sets match.

The 'ip nhrp redirect' command is required on the hub in DMVPN Phase 3 to enable NHRP redirect messages. When a spoke sends traffic to the hub for a destination behind another spoke, the hub replies with an NHRP redirect, allowing the spoke to initiate a direct tunnel to the destination spoke. This is a key component of Phase 3 along with 'ip nhrp shortcut' on the spokes.

For multicast traffic to traverse a GRE tunnel, multicast routing must be enabled on the tunnel interface and the physical interface carrying the tunnel. Additionally, an appropriate multicast routing protocol (e.g., PIM) must be configured. Without enabling multicast routing, the router will not forward multicast packets into or out of the tunnel, even though unicast works. This is the most likely cause.

DMVPN Phase 3 requires NHRP redirect on the hub to inform spokes of a better path, and NHRP shortcut on the spokes to dynamically create direct tunnels. Without these, spokes continue to route through the hub. Enabling both features allows the spoke to resolve the remote spoke's NBMA address and build a direct GRE tunnel.

The match address in a crypto map references an extended ACL that defines the traffic to be encrypted. Permitting only traffic from the local 10.1.1.0/24 to the remote subnet ensures that only that traffic is protected, while other traffic is sent unencrypted because it does not match the ACL.

When encaps/decaps counters increment but packets are dropped, the router is successfully decrypting the packets. However, if there is no route back to the source or if Unicast RPF fails, the router drops the packets. This is a common issue where the decrypted packet's source is not reachable via the same interface it arrived on, triggering RPF drop.

The command 'show running-config | include crypto isakmp key' filters the running configuration to display lines containing 'crypto isakmp key'. This will show the configured pre-shared key, including the key string and the peer address. This is the most direct way to verify the pre-shared key on a Cisco IOS router. Note that the key is displayed in clear text, so handle with care.

The ip nhrp shortcut command is configured on spoke routers in a DMVPN Phase 3 topology. When a spoke receives an NHRP redirect from the hub, the shortcut command allows it to dynamically create a direct mGRE tunnel to the destination spoke, bypassing the hub for subsequent packets. Without this command, the spoke would continue sending traffic through the hub even after receiving the redirect.

The ip nhrp redirect command on the hub enables NHRP redirect messages that inform spokes of a better path to reach another spoke directly. When a spoke sends traffic to the hub for a destination behind another spoke, the hub sends an NHRP redirect, prompting the spoke to initiate a direct tunnel. This is a key requirement for DMVPN Phase 3 spoke-to-spoke communication.

NHRP redirect allows the hub to inform the source spoke that a better path exists, and shortcut switching enables the spoke to build a direct tunnel to the destination spoke. This is the core of DMVPN Phase 3, where the hub sends a redirect message and the spoke initiates an NHRP resolution for the destination, creating a direct spoke-to-spoke tunnel.

A transform set defines the encryption and hashing algorithms (e.g., esp-aes 256 and esp-sha-hmac) that will be used to protect the data. It is referenced by the crypto map or IPsec profile. This is the correct place to specify the algorithms for the IPsec SA. The transform set ensures both peers agree on the security parameters.

The 'crypto isakmp key' command is used to configure a pre-shared key for IKE authentication. It specifies the key string and the peer's IP address. In this scenario, the peer is 192.168.1.1. This command is part of the ISAKMP policy configuration and is required for Phase 1 authentication when using pre-shared keys. It must be configured on both peers with matching keys.

'show access-lists' displays the configured ACLs and their hit counters. By examining the crypto ACL referenced in the crypto map, you can see if the counters are incrementing for the interesting traffic. If the counters are not incrementing, the ACL may not match the traffic, indicating a mismatch. This is a key step in troubleshooting IPsec VPNs when the tunnel is up but traffic is not flowing.

The ip nhrp redirect command on the hub enables NHRP redirect messages, which notify spokes of a better path to another spoke, allowing direct spoke-to-spoke tunnels. This is a key requirement for DMVPN Phase 3. Without it, spokes continue to route through the hub. It works with ip nhrp shortcut on spokes to achieve dynamic spoke-to-spoke connectivity.

With NHRP shortcut, the spoke installs a host route for the destination spoke tunnel address after successful NHRP resolution. This route points at the tunnel interface and allows the spoke to send traffic directly to the peer, bypassing the hub. The host routes observed in the routing table are the visible result of NHRP shortcut operation.

For a GRE tunnel to come up, the tunnel destination must be reachable via the underlay network. If the destination is not reachable, the tunnel interface will show up, but line protocol will be down. The engineer should verify routing to the tunnel destination and ensure that the loopback interface is advertised and reachable. This is a common issue when the underlay routing is misconfigured.

In DMVPN Phase 3, a single IPsec profile applied to the tunnel interface on all routers can secure both hub-to-spoke and spoke-to-spoke traffic. The dynamic multipoint tunnels are established on demand, and the same IPsec profile is used because the tunnel interface is the encryption endpoint. This simplifies configuration and is a key advantage of DMVPN with IPsec.

Phase 2 requires both peers to agree on a matching IPsec proposal: encryption algorithm, hash or integrity algorithm, and, if perfect forward secrecy is configured, the Diffie-Hellman group. If any of these differ, the responder rejects the quick mode exchange and no IPsec SA is created even though Phase 1 is up. Verifying the proposal on both routers is the correct next step for this symptom.

In DMVPN Phase 3, the hub uses 'ip nhrp redirect' to inform spokes of a better path, but the spokes must have 'ip nhrp shortcut' to dynamically create a direct tunnel to the destination spoke. Without it, spokes continue to send traffic through the hub, and spoke-to-spoke communication fails to optimize.

This extended ACL precisely defines the interesting traffic that should be encrypted by the IPsec VPN. The source and destination addresses with wildcard masks match the specified subnets. Referencing it in the crypto map ensures only this traffic triggers the VPN tunnel, while other traffic is sent unencrypted, as required.

If NAT is applied to the outbound interface before the crypto map, the source IP of the packets may be translated to the router's public IP, which does not match the crypto ACL. The IPsec peer will then drop the packets because they do not match the expected source subnet. This is a common issue when NAT and IPsec are configured on the same interface. The solution is to configure NAT exemption for the VPN traffic.

The ip nhrp redirect command enables the hub to send NHRP redirect messages to spokes when it receives traffic on the same tunnel interface. This is essential for Phase 3 DMVPN, allowing spokes to learn a better path and build direct tunnels. Without it, spokes continue to route through the hub.

GDOI is the protocol used by GET VPN to distribute encryption keys and policies from the key server to group members. It operates over UDP port 848 and allows the key server to push rekey messages, ensuring all group members share the same security policy and keys. GDOI is essential for the scalable any-to-any communication that GET VPN provides.

NHRP redirect on the hub informs the originating spoke that a better path exists to the destination spoke. The hub sends an NHRP redirect message to the source spoke, which then initiates an NHRP resolution for the destination spoke's NBMA address. This enables the spoke to build a direct tunnel, bypassing the hub for subsequent packets.

Lowering the tunnel interface MTU and configuring TCP MSS clamping ensures that packets are sized appropriately before encryption and encapsulation, preventing fragmentation or drops. This maintains security because the packets are still encrypted and encapsulated correctly. It is a standard best practice for IPsec VPNs to account for the additional overhead of IPsec and GRE headers, especially when the underlying path has a lower MTU.

Within the crypto map configuration, the match address command specifies the extended ACL that defines interesting traffic. This ACL determines which packets are encrypted and sent through the tunnel. Here, match address 100 tells the router that traffic between 10.1.1.0/24 and 10.2.2.0/24 should be protected by IPsec, triggering the tunnel when such traffic is encountered.

In DMVPN Phase 3, the ip nhrp redirect command on the hub enables the hub to send NHRP redirect messages to spokes when it receives traffic that could be sent directly between spokes. This prompts the originating spoke to send an NHRP resolution request for the destination spoke's public IP, allowing a direct tunnel to be built. Without this, spoke-to-spoke traffic continues to traverse the hub.

The ip nhrp redirect command on the hub enables the hub to send a redirect message to the originating spoke when it detects that traffic is being routed through the hub to another spoke. This allows the spoke to initiate a direct NHRP resolution for the destination spoke's NBMA address, enabling spoke-to-spoke tunnels. Without redirect, spokes would continue to use the hub for all inter-spoke traffic.

For a GRE tunnel to pass traffic, the tunnel destination IP address must be reachable through the underlay network. If the destination is not reachable, the tunnel interface may still show up if keepalives are not configured, but packets will be dropped because they cannot be encapsulated and sent. Ensuring reachability via a route or directly connected network is essential.

The ip nhrp redirect command on the hub enables NHRP redirect messages to be sent to spokes when traffic arrives at the hub for a destination that is reachable via another spoke. This allows the ingress spoke to learn an optimal path and initiate a direct spoke-to-spoke tunnel, which is a key feature of DMVPN Phase 3.

OCSP (Online Certificate Status Protocol) allows the hub to query an OCSP responder in real time to check the revocation status of a spoke's certificate during IKEv2 authentication. This meets the real-time requirement. Cisco IOS supports OCSP for IKEv2, enabling immediate revocation checks.

The 'ip nhrp redirect' command on the hub enables NHRP redirect messages, which inform the originating spoke that a shorter path exists to the destination spoke. This allows the spoke to initiate a direct tunnel, achieving Phase 3 behavior. Without it, spokes continue to route through the hub.

The show crypto map command displays the crypto map configuration, including the transform set, peer, and ACL. It shows the transform set name configured for each crypto map entry, which is exactly what the engineer needs to verify. This command works regardless of Phase 2 status and is the correct choice for checking configuration.

GDOI is the protocol the key server uses in GET VPN to distribute the Group Security Association, including the rekey messages carrying updated keys and policies. Group members register with the key server over GDOI, receive the shared keys, and then encrypt traffic directly between themselves without per-pair tunnels. This matches the requirement for identical keys pushed from a single key server.

GET VPN rekey retransmission with acknowledgment lets the key server pace unicast retransmissions to members that did not receive the multicast rekey. When a large number of group members reboot together, the key server sends the multicast rekey, then retransmits at the configured interval to non-responding members, up to the retransmit limit. This prevents an overload of simultaneous unicast rekeys while still guaranteeing key delivery.

NHRP shortcut allows a spoke to dynamically create a direct tunnel to another spoke when it receives an NHRP redirect from the hub. This enables direct spoke-to-spoke communication, bypassing the hub, which is a key feature of DMVPN Phase 3.

GDOI is the group key management protocol used by GET VPN. The key server acts as the group controller/key server, and group members register with it using a group identity and IKE phase 1, then receive the rekey messages containing the IPsec SA policy and TEK/KEK keys. This allows automatic, scalable key distribution without per-member manual pre-shared key configuration, matching the scenario requirement exactly.

GET VPN group members use the GDOI protocol to register with the key server. GDOI operates on UDP port 848. Allowing this port through the firewall is essential for group members to register and receive keys and policies from the key server.

The 'ip nhrp redirect' command on the hub enables DMVPN Phase 3 functionality. When a spoke sends traffic to another spoke via the hub, the hub sends an NHRP redirect message to the originating spoke, informing it of a better path directly to the destination spoke. This allows the originating spoke to initiate a direct tunnel to the destination spoke, bypassing the hub for subsequent packets. This is a key component of DMVPN Phase 3.

By default, GET VPN key servers send rekeys via multicast to the group address. If the underlay network does not support multicast or the group members are not receiving multicast rekeys, enabling unicast rekey ensures each member receives the rekey directly. This is a common requirement in MPLS VPN or non-multicast-capable transport networks.

GDOI (Group Domain of Interpretation) is the protocol used in GET VPN to distribute group keys and policies from the key server to group members. It enables the key server to push encryption keys, rekey messages, and ACL policies to all group members, facilitating secure any-to-any communication without point-to-point tunnels.

NHRP redirect is a Phase 3 feature that allows the hub to inform spokes of a better path to another spoke. When the hub receives a packet from one spoke destined to another, it sends an NHRP redirect message to the originating spoke, which then resolves the destination NBMA address and builds a direct tunnel. Without NHRP redirect, spokes continue to route through the hub, defeating the purpose of Phase 3.

The crypto ACL (extended access list) defines which traffic is interesting and should be protected by the IPsec VPN. In this scenario, an ACL permitting traffic from 10.1.1.0/24 to 10.2.2.0/24 and vice versa would be referenced by the crypto map. This ACL is the element that specifies the traffic to be encrypted.

If the IPsec SAs are established but packet counters are not incrementing, the router is not forwarding interesting traffic into the tunnel. This often occurs when the route to the remote protected subnet points out of the physical interface instead of the tunnel interface, or when there is no route at all. Correcting the routing ensures that packets matching the crypto ACL are sent through the VPN.

For GRE over IPsec, the crypto ACL defines which traffic is encrypted. Since GRE encapsulates the multicast traffic, the outer IP packet uses IP protocol 47. Therefore, the crypto ACL must permit GRE traffic between the tunnel endpoints. This ensures that all GRE-encapsulated packets, including multicast, are encrypted by IPsec.

NHRP redirect is a Phase 3 feature that lets the hub inspect traffic arriving on its mGRE interface and send a redirect message to the originating spoke when a shorter path exists. The spoke then resolves the destination NBMA address and builds a direct tunnel to the target spoke. Without redirect, spokes keep sending all inter-spoke traffic through the hub, so this is required for shortcut behavior.

Phase 3 shortcut switching relies on the spokes having a default route pointing to the hub so they forward all unknown traffic to the hub initially. The hub advertises a default route rather than specific prefixes, which keeps the spoke routing tables small. When a spoke needs to reach another spoke, NHRP resolves the destination and installs a shortcut route, allowing traffic to bypass the hub while the default route remains for everything else.

In DMVPN Phase 3, the hub still needs to know how to reach all spoke networks to provide initial connectivity and to forward traffic when a direct tunnel is not yet established. This is typically achieved by running a routing protocol on the hub and spokes, or by configuring a summary route on the hub. Without this, the hub cannot route traffic to the correct spoke, and spoke-to-spoke communication may fail.

IKEv2 pre-shared key authentication on Cisco IOS requires the hub to match the peer's identity against an entry in the IKEv2 keyring, where the pre-shared key is defined per peer or per subnet. Without a matching keyring peer entry, the hub cannot retrieve the pre-shared key during IKE_AUTH even though the profile exists, and the exchange fails. Adding the spoke identity with the correct key resolves the failure.

For IPsec site-to-site VPNs, the crypto map ACL must be an extended ACL that defines the interesting traffic. It should permit IP traffic from the local subnet to the remote subnet. This ACL is used to match packets that need encryption. A standard ACL cannot specify destination addresses or protocols, so it is insufficient.

For certificate authentication in IKEv2, the router must know which trustpoint to use for its own certificate and for validating the peer certificate chain. Referencing the trustpoint in the IKEv2 profile with the pki trustpoint command supplies that binding. Without it, the router cannot select the correct CA chain or send the proper certificate during IKE_AUTH, so the negotiation fails even though certificates are installed.