This document describes how to troubleshoot some of the most common communication issues of the Cisco AnyConnect Secure Mobility Client on Firepower Threat Defense (FTD) when it uses either Secure Socket Layer (SSL) or Internet Key Exchange version 2 (IKEv2).
Cisco AnyConnect Secure Mobility Client, free and safe download. Cisco AnyConnect Secure Mobility Client latest version: A powerful tool for secure connections. Cisco AnyConnect Secure Mobility. I have a user reporting that when they connect to the VPN they loose their internet connection. They can still access company intranet. We use Cisco anyconnect to access the VPN. They are using Windows 7. Full disclosure. This is my first VPN troubleshooting ticket.
Contributed by Angel Ortiz and Fernando Jimenez, Cisco TAC Engineers.
Cisco recommends that you have knowledge of these topics:
Components Used
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
This guide explains how to troubleshoot some common communication issues that AnyConnect clients have when the FTD is used as Remote Access Virtual Private Network (VPN) gateway. These sections address and provide solutions to problems below:
Complete these steps:
Step 1. Verify Split tunnel configuration.
Navigate to Objects > Object Management > Access List > Edit the Access List for Split tunneling.
Step 2.Verify Network Address Translation (NAT) exemption configuration.
Remember that we must configure a NAT exemption rule to avoid traffic to be translated to the interface IP address, usually configured for internet access (with Port Address Translation (PAT)).
Note: When NAT exemption rules are configured, check the no-proxy-arp and perform route-lookup options as a best practice.
Step 3. Verify Access Control Policy.
Per your Access Control Policy configuration, ensure that traffic from the AnyConnect clients is allowed to reach the selected internal networks, as shown in the image.
There are two possible scenarios for this issue.
Ensure that the Group-Policy is configured for Split tunneling as Tunnel networks specifiedbelow and NOT as Allow all traffic over tunnel, as shown in the image.
2. Traffic destined for the Internet must go through the VPN tunnel.
In this case, the most common Group-Policy configuration for Split tunneling would be to select Allow all traffic over tunnel, as shown in the image.
Step 1. Verify NAT exemption configuration for internal network reachability.
Remember that we must still configure a NAT exemption rule to have access to the internal network. Please review Step 2 of the AnyConnect clients cannot access internal resource section.
Step 2. Verify hairpinning configuration for dynamic translations.
In order for AnyConnect clients to have internet access through the VPN tunnel, we need to ensure that the hairpinning NAT configuration is correct for traffic to be translated to the interface´s IP address.
Step 3. Verify Access Control Policy.
Per your Access Control Policy configuration, ensure that traffic from the AnyConnect clients is allowed to reach the external resources, as shown in the image.
There are two possible scenarios for this issue:
When Allow all traffic over tunnel is configured for AnyConnect means that all traffic, internal and external, should be forwarded to the AnyConnect headend, this becomes a problem when you have NAT for Public Internet access, since traffic comes from an AnyConnect client destined to another AnyConnect client is translated to the interface IP address and therefore communication fails.
Step 1. Verify NAT exemption configuration.
In order to overcome this problem a manual NAT exemption rule must be configured to allow bidirectional communication within the AnyConnect clients.
Step 2. Verify Access Control Policy.
Per your Access Control Policy configuration, ensure that traffic from the AnyConnect Clients is allowed, as shown in the image.
2. Anyconnect clients with Tunnel networks specified below Kyodai solitaire. configuration in place.
With Tunnel networks specified below configured for the AnyConnect clients only specific traffic is forwarded to through the VPN tunnel. However, we need to ensure that the headend has the proper configuration to allow communication within the AnyConnect clients.
Step 1. Verify NAT exemption configuration.
Please check Step 1, in the Allow all traffic over tunnel section.
Step 2. Verify Split tunneling configuration.
For AnyConnect clients to communicate between them we need to add the VPN pool addresses into the Split-Tunnel ACL.
Note: If there is more than one IP Pool for AnyConnect clients and communication between the different pools is needed, ensure to add all of the pools in the split tunneling ACL, also add a NAT exemption rule for the needed IP Pools.
Step 3. Verify Access Control Policy.
Ensure that traffic from the AnyConnect clients is allowed as shown in the image.
There are some scenarios where AnyConnect clients need to establish phone calls and video conferences over VPN.
AnyConnect clients can connect to the AnyConnect headend without any problem. They can reach internal and external resources, however phone calls cannot be established.
For this cases we need to consider the follow points:
By default, FTD and ASA have applications inspection enabled by default in their global policy-map.
In most cases scenarios the VPN phones are not able to establish a reliable communication with the CUCM because the AnyConnect headend has an application inspection enabled that modifies the signal and voice traffic.
For more information about the voice and video application where you can apply application inspection see the follow document:
In order to confirm if an application traffic is dropped or modified by the global policy-map we can use the show service-policy command as shown below.
In this case we can see how SIP inspection drops the traffic.
Moreover, SIP inspection can also translate IP addresses inside the payload, not in the IP header, causes different issues, hence it is recommended to disable it when we want to use voice services over AnyConnect VPN.
In order to disable it we need to complete the next steps:
Step 1. Enter the privileged EXEC mode.
For more information on how to access this mode see the next document:
Step 2. Verify the global policy-map.
Run the next command and verify if SIP inspection is enabled.
Step 3. Disable SIP inspection.
If SIP inspection is enabled, turn it off running command below from clish prompt:
Step 4. Verify the Global Policy-map again.
Ensure that SIP inspection is disabled from the global policy-map:
As mentioned in the previous section, a very common need for AnyConnect clients is to establish phone calls when connected to the VPN. In some cases the call can be established, however clients may experience lack of audio on it. This applies to the next scenarios:
In order to get this fixed, we can follow these steps:
Step 1. Verify Split tunneling configuration.
Step 2. Verify NAT exemption configuration.
NAT exemption rules must be configured to exempt traffic from the AnyConnect VPN network to the Voice Servers network and also to allow bidirectional communication within the AnyConnect clients.
Step 3. Verify that SIP inspection is disabled.
Please review the previous section AnyConnect clients cannot establish phone calls to know how to disable SIP inspection.
Step 4. Verify Access Control Policy.
Per your Access Control Policy configuration, ensure that traffic from the AnyConnect clients is allowed to reach the Voice servers and involved networks, as shown in the image.