156-215.81.20 VPN Basics Practice Question

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 'Shared Secret' for GW-C is different from the one used by GW-A and GW-B.

  Why it's wrong here

  A mismatched shared secret would prevent the tunnel from establishing, but it would not cause traffic to be unencrypted while other tunnels work. If the shared secret were wrong, IKE negotiation would fail, and no tunnel would be created. The symptom is that traffic between GW-A and GW-C is not encrypted, which could be due to a missing tunnel, but a shared secret mismatch would typically result in a tunnel failure, not silent unencrypted traffic. Moreover, in a Mesh community, a single shared secret is often used for all gateways. The more likely cause is that GW-C is not a participating gateway.

• ✗

  The 'VPN Domain' of GW-C does not include the networks behind GW-A.

  Why it's wrong here

  The VPN Domain of GW-C should include the networks behind GW-A only if GW-C needs to initiate traffic to those networks. However, in a Mesh community, each gateway's VPN Domain typically includes its own local networks. For traffic from GW-A to GW-C, GW-A's VPN Domain must include GW-C's networks, and GW-C's VPN Domain must include GW-A's networks to allow return traffic. If GW-C's VPN Domain is missing GW-A's networks, return traffic might fail, but the initial encryption would still occur if GW-A initiates. The issue described is that traffic is not encrypted at all, which points to a more fundamental problem like missing community membership.

• ✓

  GW-C is not included in the VPN community's 'Participating Gateways' list.

  Why this is correct

  In a Mesh VPN community, all gateways that should communicate securely must be listed as participating gateways. If GW-C is not in the list, it is not part of the community, and no VPN tunnel will be established between GW-A and GW-C. The fact that GW-A to GW-B works indicates that GW-B is correctly listed. This is the most likely cause of the missing encryption between GW-A and GW-C.

• ✗

  The 'Encryption Domain' of GW-A does not include the networks behind GW-C.

  Why it's wrong here

  If GW-A's encryption domain does not include GW-C's networks, traffic from GW-A to GW-C would not be encrypted and would be sent in clear text. However, the administrator confirmed that traffic between GW-A and GW-B is encrypted, so GW-A's encryption domain likely includes GW-B's networks. For the issue to be specific to GW-C, it is more likely that GW-C is not part of the community, rather than a missing network in GW-A's encryption domain. Additionally, encryption domains are typically configured per gateway, and if GW-C is not in the community, its networks would not be part of the community's encryption domain.