Cisco VPN Clients that connect to a VPN headend using IPsec over TCP
might connect to the headend fine, but then the connection fails after some
time. This document describes how to switch to IPsec over UDP or native ESP
IPsec encapsulation in order to resolve the issue.
In order to encounter this specific problem, Cisco VPN Clients must be
configured to connect to a VPN headend device using IPsec over TCP. In most
instances, network administrators configure the ASA to accept Cisco VPN Client
connections over TCP Port 10000.
The information in this document is based on Cisco VPN Client.
For more information on document conventions, refer to
Technical Tips Conventions.
When the VPN client is configured for IPsec over TCP (cTCP), the VPN
client software will not respond if a duplicate TCP ACK is received asking for
the VPN client to re-transmit data. A duplicate ACK might be generated if there
is packet loss somewhere between the VPN client and the ASA headend.
Intermittent packet loss is a fairly common reality on the Internet. However,
since the VPN endpoints are not using the TCP protocol (recall that they are
using cTCP), the endpoints will continue transmitting and the connection will
In this scenario, a problem occurs if there is another device such as a
firewall tracking the TCP connection statefully. Since the cTCP protocol does
not fully implement a TCP client and server duplicate ACKs do not receive a
response, this can cause other devices in-line with this network stream to drop
the TCP traffic. Packet loss must occur on the network causing TCP segments to
go missing, which triggers the problem.
This is not a bug, but a side effect of both packet loss on the network
and the fact that cTCP is not a real TCP. The cTCP tries to emulate the TCP
protocol by wrapping the IPsec packets within a TCP header, but that is the
extent of the protocol.
This issue typically occurs when network administrators implement an
ASA with an IPS, or do some sort of application inspection on the ASA that
causes the firewall to act as a full TCP proxy of the connection. If there is
packet loss, the ASA will ACK for the missing data on behalf of the cTCP server
or client, but the VPN client will never respond. Since the ASA never receives
the data it is expecting, communication cannot continue. As a result, the
In order to resolve this problem, perform any of these actions:
Switch from IPsec over TCP to IPsec over UDP, or native encapsulation
with the ESP protocol.
Switch to the AnyConnect client for VPN termination, which uses a
fully implemented TCP protocol stack.
Configure the ASA to apply tcp-state-bypass for these specific
IPsec/TCP flows. This essentially disables all security checks for the
connections that match the tcp-state-bypass policy, but will allow the
connections to work until another resolution from this list can be implemented.
For more information, refer to
State Bypass Guidelines and Limitations.
Identify the source of the packet loss, and take corrective action in
order to prevent the IPsec/TCP packets from dropping on the network. This is
usually impossible or extremely difficult since the trigger to the issue is
usually packet loss on the Internet, and the drops cannot be