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?
Remote users can call internal users without issues, which indicates that their connections are generally configured correctly. However, they experience no audio on calls between other remote users. This suggests a problem with the connection between two external endpoints. To facilitate communication between two remote clients, a NAT policy that allows outside-to-outside communication is typically required. Therefore, the cause of the issue is that Cisco Secure Firewall Threat Defense needs a NAT policy allowing outside to outside communication.
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
Bubu3k great find. Here's the one that pertains to FTD. https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/216180-troubleshoot-common-anyconnect-communica.html#anc8:~:text=check%20that%20the%20correct%20inbound%20and%20outbound%20interfaces%20configuration%20is%20in%20place
Bubu3k is correct, "B" is the correct answer.
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
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
Though, the wording "is not available" it might be wrong. (hate Cisco for such a bad wording) It might also be D where there is an Extended ACL for split tunneling and there are missing subnets - rendering host from subnet A cannot call host from subnet B. A full tunnel gateway wont suffer from this thing and only the Spoke-to-Spoke command has to be taken care of (I am running such a deployment on FTD and RAVPN and I don't have any NAT configured but the U-turn and indeed in full-tunnel mode and the Cisco Jabber calls are working just fine)
I can't delete this. In case of a Full Tunnel there is a Hairpin when calling between VPN clients but the answer says "it is not available" which is false. I have changed the answer to D - sorry for this