CCNP Practice Question: Examine this configuration for a site-to-site VPN…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The crypto map uses IKEv2 for key exchange because the transform set uses SHA-256.

  Why it's wrong here

  The transform set's use of SHA-256 does not indicate IKEv2. IKE version is determined by the configuration commands: 'crypto isakmp' invokes IKEv1, whereas 'crypto ikev2' is required for IKEv2. SHA-256 is an authentication hash that can be used in both IKEv1 and IKEv2 transform sets, so it has no bearing on the IKE version. This option is incorrect because the presence of 'crypto isakmp' in the configuration confirms IKEv1, not IKEv2.

• ✓

  The access-list 101 defines the traffic that will be encrypted; traffic from 192.168.10.0/24 to 192.168.20.0/24 will be protected.

  Why this is correct

  Access-list 101 is referenced by the crypto map's 'match address 101' statement, which defines the interesting traffic that will be protected by IPsec. The ACL explicitly permits traffic from source network 192.168.10.0/24 to destination network 192.168.20.0/24, so only that traffic triggers the establishment of the IPsec security association. This is correct because without a matching ACL entry, no traffic would be encrypted and the VPN would not carry any payload.

• ✗

  The ISAKMP policy lifetime of 86400 seconds is too long and will cause the tunnel to fail.

  Why it's wrong here

  An ISAKMP policy lifetime of 86400 seconds is exactly the default lifetime for IKEv1 phase 1 SA, which is one day. This is a standard and acceptable value that does not cause the tunnel to fail. In fact, many production configurations use this default or even longer lifetimes to reduce the overhead of renegotiation. The tunnel failure would only occur if the lifetime were misconfigured in a way that causes a mismatch between peers, but 86400 is a common default.

• ✗

  The crypto map should be applied to the tunnel interface, not the physical interface.

  Why it's wrong here

  For a traditional site-to-site IPsec VPN using crypto maps, the crypto map must be applied to the physical interface (or a subinterface) that carries the encrypted traffic, not to a tunnel interface. Tunnel interfaces are used for other VPN technologies such as VTI (Virtual Tunnel Interface) or DMVPN, where the tunnel itself is the IPsec endpoint. Applying a crypto map to a tunnel interface is invalid because crypto maps are designed to be bound to the outside physical interface that faces the remote peer.