Remote users who connect via Cisco AnyConnect to the corporate network behind a Cisco FTD device report that they get no audio 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?
The issue is that the Enable Spoke to Spoke Connectivity through Hub option is not selected on the FTD. When remote users connect through a VPN, their traffic often needs to be routed or hairpinned through the VPN concentrator to allow communication between devices on the same VPN. If this option is not enabled, the FTD will not route traffic between two remote users, leading to communication issues such as no audio during calls.
https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/216180-troubleshoot-common-anyconnect-communica.pdf see section: AnyConnect clients cannot communicate between each other that leaves us with A and B, I would go for A, the way B is formulated "Split tunneling is enabled for the Remote Access VPN on FTD" is a bit odd, the fact that split tunnel is enabled is not a problem, but if you tunnel specific networks you need to make sure the VPN pool addresses in the Split-Tunnel ACL.
Correct Harpinning is mentioned for internet access and NAT for audio issues in this doc
Not C because it is a feature enabled by default
its D, see: https://www.cisco.com/c/en/us/td/docs/security/firepower/70/configuration/guide/fpmc-config-guide-v70/firepower_threat_defense_site_to_site_vpns.html#:~:text=Enable%20Spoke%20to%20Spoke%20Connectivity%20through%20Hub%E2%80%94Disabled%20by%20default.%20Choosing%20this%20field%20enables%20the%20devices%20on%20each%20end%20of%20the%20spokes%20to%20extend%20their%20connection%20through%20the%20hub%20node%20to%20the%20other%20device.
we are not talking about a ipsec l2l connection
I think C is the answer, here is an explanation for the hairpinning feature: https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215875-configure-anyconnect-vpn-client-on-ftd.html#anc14:~:text=NAT%20exemption%20configuration.-,Step%202.%20Hairpin%20Configuration,turn)%20is%20responsible%20to%20route%20the%20traffic%20from%20outside%20to%20outside.,-A%20VPN%20pool
Definatley A …packets to other users in the RAVPN pool will be NATed to interface IP ( for example) and they will never reach the other RAVPN users.
Step 2. Hairpin Configuration Also known as U-turn, this is a translation method that allows the traffic to flow over the same interface the traffic is received on. https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215875-configure-anyconnect-vpn-client-on-ftd.html
So the answer is NOT C because it is available according to your reference.
The answer is without a doubt A. I've set many of these up on ASAs and FTDs alike all the way back to the ASA w/ Firepower sensors and even set one up like a month ago. I've even had a ticket at work about this exact problem, audio between Anyconnect users. It is not a "feature" but just a normal part of NAT, setting it up with nat (outside,outside) instead of the standard nat (inside,outside). However, the test banks I've studied always say the answer is C, but that is not correct. Never been more sure of anything in my life. Sometimes Cisco asks questions in a weird way to intentionally confuse you to the wrong answer, but I'm not seeing it in this one.
And its not B because split tunneling wouldn't matter. With VPNs, you have split-tunnels and full tunnels, so you have to have one or the other with a remote access VPN and neither would fix the problem without a hairpin NAT statement. Split-tunnels is essentially where the network specifies which subnets and hosts are to go across the VPN and which terminate locally out of your modem like normal internet traffic, hence the splitting of the tunnel. Another term for a hairpin is U-Turn, because it essentially leaves your home, goes into the outside interface of the firewall, makes a U-Turn and goes right back out the outside interface of the firewall to the Anyconnect users computer, wherever they may be in the world. It is not D because that is for a site-to-site VPN, not a remote access VPN.
Read my comment below for a full explanation, but it is without a doubt 100% A. But the test bank I bought swears it is C, but its wrong. Hairpinning is not a feature but a normal part of NAT, just written in a specific way of (outside,outside).
A is correct. Hairpinning is not a "feature" but a configuration that needs some steps on the ASA, less on the FTD. Here you just have to have the no-nat and a acp allowing the traffic. NAT is correct.
The cause of this issue is likely option B, which is that split tunneling is enabled for the Remote Access VPN on FTD. Split tunneling allows the remote user's traffic to be split between the corporate network and the Internet. This means that when a remote user is on a call with another remote user using their softphone, the audio traffic may be sent directly between the two remote users and not through the corporate network. If split tunneling is enabled, the audio traffic would not be routed through the corporate network and would fail to reach the remote users. To resolve this issue, the network administrator should disable split tunneling on the Remote Access VPN configuration in the FTD device. This will force all traffic to be routed through the corporate network, allowing the audio traffic to reach the remote users.
https://www.cisco.com/c/en/us/td/docs/security/firepower/623/configuration/guide/fpmc-config-guide-v623/firepower_threat_defense_remote_access_vpns.html
I'd go with B. If you have split tunel, than only LAN networks are working.
But if you define that network in split tunnel it will work :)
A, B and C are all valid answers. A: If you do not have NO-NAT policy, outside to outside traffic will be NAT-ed to outside interface B: If you have split tunneling, then you are only allowed to specific subnets in ACL. Here I'm not sure if traffic from same subnet ( IP pool for DHCP) is allowed C: ASA does not line same traffic entering outside interface and at the same time exiting interface, to combat this problem, Hairpining must be enabled. To be honest, I'd go with A here.
Tested in LAB. The right one is C. For the same subnet you do not ned NO-NAT rule, but you must have Hairpinig for the same interface enabled. Regarding Split-Tun config. Like NAT, you do not need it for same subnet. So ONLY C
Disregard this comment. The right answer is A. A is 100% a must for this traffic, B: If split tunneling is enabled this also mean that the my local subnet can be defined and in that way i can communicate wit local network. C: Hairpining or U-turn is supported on fmc : https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215875-configure-anyconnect-vpn-client-on-ftd.html#anc16 So only A
C is the correct one. I am running such a setup in production from the last 4 years. Also a Split Tunnel can create such an event if the extended ACL is used and not all subnets are there - resulting in LAN A to LAN B to be sent in Internet rather than into the tunnel iface. The HAIRPIN is needed because such calls will require P2P communications
C is the correct one. I am running such a setup in production from the last 4 years. Also a Split Tunnel can create such an event if the extended ACL is used and not all subnets are there - resulting in LAN A to LAN B to be sent in Internet rather than into the tunnel iface. The HAIRPIN is needed because such calls will require P2P communications
Disregard this comment. The right answer is A. A is 100% a must for this traffic, B: If split tunneling is enabled this also mean that the my local subnet can be defined and in that way i can communicate wit local network. C: Hairpining or U-turn is supported on fmc : https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215875-configure-anyconnect-vpn-client-on-ftd.html#anc16 So only A
C is the correct one. I am running such a setup in production from the last 4 years. Also a Split Tunnel can create such an event if the extended ACL is used and not all subnets are there - resulting in LAN A to LAN B to be sent in Internet rather than into the tunnel iface. The HAIRPIN is needed because such calls will require P2P communications
C is the correct one. I am running such a setup in production from the last 4 years. Also a Split Tunnel can create such an event if the extended ACL is used and not all subnets are there - resulting in LAN A to LAN B to be sent in Internet rather than into the tunnel iface. The HAIRPIN is needed because such calls will require P2P communications
C is correct.
https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215875-configure-anyconnect-vpn-client-on-ftd.html#toc-hId-809586599
Thats just the Cisco page on how to setup a hairpin on an FTD, furthering proof that its inherent to the FTD and that the answer is A.