Spoke to Spoke Connectivity for Remote Access VPN on FTD

Configure these features using Secure Firewall Management Center
Answer Correct 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.

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

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.

Community Insight

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.

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.

Community Discussion (4 comments)

Bubu3k 👍 7 Selected: 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
Silexis 👍 1 Selected: 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
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
aaInman 👍 3 Selected: B
Bubu3k is correct, "B" is the correct answer.

Comments & Corrections

No comments 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.

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.

Related Analysis

An organization created a custom application that is being f

A-Grade

Which two features can be used with Cisco Secure Firewall Th

S-Grade

An administrator receives reports that users cannot access a

A-Grade

← Back to 300-710 Study Guide