Spoke to Spoke Connectivity for Remote Access VPN on FTD

300-710 Last updated

Configure these features using Secure Firewall Management Center

Short answer

C The Enable Spoke to Spoke Connectivity through Hub option must be selected on the FTD device to allow VPN client-to-client communication.

Question

Remote users who connect via Cisco Secure Client to the corporate network behind a Cisco Secure Firewall Threat Defense device are reporting no audio on calls when calling between remote users using their softphones. These same users can call internal users on the corporate network without any issues. What is the cause of this issue?

  1. The hairpinning feature is not available on Cisco Secure Firewall Threat Defense
  2. Cisco Secure Firewall Threat Defense needs a NAT policy that allows outside to outside communication
  3. The Enable Spoke to Spoke Connectivity through Hub option is not selected on Cisco Secure Firewall Threat Defense Correct Answer
  4. Split tunneling is enabled for the Remote Access VPN on Cisco Secure Firewall Threat Defense

Key Takeaways

The question tests VPN client-to-client communication (hairpinning) on FTD, where the common trap is assuming a manual NAT policy is required instead of using the native FMC checkbox.

When remote VPN users cannot communicate with each other but can reach internal hosts, the issue is typically the lack of intra-interface routing. This page establishes that enabling spoke-to-spoke connectivity resolves the audio issue between remote peers.

Common mistake: Selecting B, believing a manual outside-to-outside NAT policy is required, which is an ASA-centric approach rather than the FMC-managed checkbox method.

Expert Analysis

Why the Answer Is Correct

Option C is correct because the "Enable Spoke to Spoke Connectivity through Hub" option in the FMC Remote Access VPN policy is the specific configuration that permits intra-interface traffic for VPN clients. Without this option selected, the FTD device drops traffic attempting to route between two remote VPN peers, resulting in no audio for softphone calls between them.

Why the Other Options Are Wrong

Option A is incorrect because the hairpinning feature is fully available on FTD; it simply needs to be enabled. Option B is incorrect because while NAT exemption is necessary, on FTD this is automatically handled by the spoke-to-spoke checkbox, making a manual outside-to-outside NAT policy the wrong approach. Option D is incorrect because split tunneling dictates whether traffic bypasses the tunnel, not whether traffic hairpins between two tunneled users.

Community Comment Notes

Some learners incorrectly favor a manual NAT policy as in option B, as Bubu3k referenced a general troubleshooting guide. However, as Silexis noted, "When a VPN Client calls another VPN Client, there will be a P2P communication", which requires U-turn or hairpin capabilities, handled natively in FTD by the spoke-to-spoke option, not just NAT. Ricckku also pointed out that "The hair-pinning feature is definitely required", refuting option A's claim that it is unavailable.

Official Reference

https://www.cisco.com/c/en/us/td/docs/security/firepower/670/configuration/guide/fpmc_config_guide_670/remote_access_vpn_policies_for_ftd.html

Exam Strategy

For FTD VPN issues involving client-to-client communication, look for the "Enable Spoke to Spoke Connectivity through Hub" option. Do not confuse FTD's FMC-managed checkboxes with ASA's CLI manual NAT and same-security-traffic configurations.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 4 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.

From public community threads 4

  1. Bubu3k 👍 7 Answered B
    Based on the following scenarios I'd be leaning more on B: -No audio on the call between an AnyConnect Client and an external number. -No audio on the call between an AnyConnect Client and another AnyConnect Client. https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client-v4x/220337-troubleshoot-common-anyconnect-communica.html
  2. aaInman 👍 3 Answered B
    Bubu3k is correct, "B" is the correct answer.
  3. ricckku 👍 2
    A is the correct answer. The hair-pinning feature is definitely required. https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215875-configure-anyconnect-vpn-client-on-ftd.html#toc-hId-1618727688
  4. Silexis 👍 1 Answered A
    Option B is wrong. When a VPN Client calls another VPN Client, there will be a P2P communication, so the first thing which is passing through my mind in HairPin or Spoke-to-Spoke communication. This means that traffic entering through the tunnel interface from one client, it will return to the same interface when calling the other client (an U-turn or hairpin). So, the command: same-security-traffic permit intra-interface .......is missing. This is why I will stick with A

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Changing FTD from Routed to Transparent Mode

S-Grade

How Do You Isolate BVI Traffic on a Routed FTD?

S-Grade

Cisco FTDv Licensing Model Valid Statements

S-Grade

← Back to 300-710 Study Guide