EFT Deployment Guide for Cisco Tunnel Control Protocol on Cisco EasyVPN
PDF(364.5 KB) View with Adobe Reader on a variety of devices
Updated:March 13, 2015
This early field testing deployment guide highlights the steps to configure the Cisco® Tunnel Control Protocol (cTCP) feature on Cisco IOS® Easy VPN Servers, Easy VPN Remotes, and Cisco VPN Clients. With this feature enabled, VPN users will be able to establish VPN tunnels from the client/remote to the Easy VPN Server through a third-party Network Address Transport (NAT) device or firewall.
There are many situations where customers require a VPN client to operate in an environment where standard ESP (Protocol 50) or UDP 500 (IKE) can either not function, or not function transparently (without modification to existing firewall rules).
Situations where standard ESP or UDP 500 are not permitted include:
• Small/home office router performing Network/Port Address Translation (NAT/PAT). This router sits between the EasyVPN Remote/Client and the Server and usually supports both TCP and UDP translation by default with no restrictions, but ESP might not be permitted.
• PAT-provided IP address behind a large corporation. This could exist if a service provider provides non-public addresses to clients and then performs PAT. This scenario is identical to that documented above. However, in the corporation scenario, it is common that only predefined TCP applications are permitted (TCP 80, TCP 443, etc.) for added network protection. These devices include Cisco PIX® security appliances, large Cisco IOS Software-based routers, Checkpoint firewalls, etc. A hotel providing private address space to guests could fall under this category, or the first.
• Non-NAT Firewall (Packet Filtering or Stateful). This scenario is common at companies that wish to use routable address space on their internal networks. Often in this environment, only particular TCP applications will function, but UDP outbound is not permitted because it is considered to be a potential corporate security hole. Our customers are sometimes consultants or employees located at these networks, trying to tunnel back into another corporation from behind an existing firewall. These devices include Cisco IOS routers and Cisco PIX firewalls, either operating as a stateful firewall or a stateless packet filter.
• Proxy server. If a proxy server is smart enough to look at each packet to confirm that the activity occurring is the defined activity, our solution may not work. However, for proxy servers that simply proxy TCP service ports (such as Borderware firewalls) our solution should work in this situation.
To solve this problem without modifying the rules configured in the firewall, Cisco has come up with a protocol called Cisco Tunneling Control Protocol. When cTCP is enabled on client and headend device, IKE and ESP traffic will be encapsulated in the TCP header, so that the firewalls in between the client and the headend device would simply permit this traffic, considering it as TCP traffic.
cTCP is also called TCP over IPsec, or TCP traversal.
The information in this document is based on the following software and hardware versions:
• Cisco 2821 Router with Cisco IOS Software Release 12.4(9)T as EasyVPN Server
• Cisco 871w Router with Cisco IOS Software Release 12.5(1st)T as EasyVPN Remote
• Cisco VPN Client Version 4.0.5
• Cisco 1811 Router as firewall
This document uses the network setup shown in Figure 1.
Figure 1. Network Setup
After the topology is set, make sure Host-1, Host-2, and Host-3 are able to reach the server.
A few things to remember when deploying cTCP:
• The client initiates a cTCP connection using a random, unused (unused at the time of selecting the port) TCP port number as the source port. Any application that later uses that port may not work.
• Session setup and teardown: cTCP session initiation follows a fixed number of retransmissions (that is not configurable) before declaring failure. Just like the server, the client does not react to a TCP RST received on the source port (for the same reasons of anyone being able to generate such a packet). It will close the session only when the VPN session on top of the cTCP session is closed, and will then send a TCP RST (that the server ignores).
• Keepalive: cTCP client needs to send periodic keepalives to keep NAT/firewall sessions alive. To this end, cTCP client sends a TCP ACK ack'ing the last sequence number received from the hub. The keepalive interval defaults to 5 seconds; however, it can be configured.
Configure cTCP on Cisco Easy VPN
• Configure a typical EasyVPN server tunnel setup, using either crypto map or DVTI.
• Enable ctcp option on the server. Configure up to 10 ports on the server to listen to. (e.g., crypto ctcp port <port number1> ... <port number10>)
• Configure ezvpn profile on the remote router (e.g., crypto ipsec client ezvpn easy)
• Enable ctcp option under the ezvpn profile on the remote router (e.g., ctcp enable <port number>)
• Configure the interface on remote that is connected to host-1, as Easyvpn `inside interface'.
• Configure the interface on remote that is connected to firewall, as Easyvpn `outside interface'.
• Configure ip inspect rule on the middle router that acts as firewall (e.g., ip inspect name <name> tcp). Apply this rule on the interface that is connected to ctcp-client to inspect the incoming tcp requests (e.g., ip inspect <name> in).
• Configure the access-list policy on the firewall (e.g., ip access-list extended <name>). Apply this policy on the interface that is connected to server (e.g., ip access-group <name> in).
Sample Configuration and Troubleshooting Output
Server Configuration Using Virtual Tunnel Interface
aaa authentication login USERAUTH local
aaa authorization network branch local
aaa session-id common
username newuser password 0 cisco123
username 871-ctcp password 0 cisco123
!!! Enabling ctcp on server
crypto ctcp port 10001 10002 10003
!!! The following is a typical EasyVPN configuration
*Mar 9 23:33:37.450: cTCP: encapsulating IKE packet
*Mar 9 23:33:37.450: cTCP: updating LOCAL Seq number to B9B5FD4C
*Mar 9 23:33:38.822: %LINK-3-UPDOWN: Interface Loopback0, changed state to up
*Mar 9 23:33:39.822: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
ctcp-remote#sh cry ctcp
Remote Local VRF Status
184.108.40.206:10001 220.127.116.11:25690 CTCP_ACK_S
ctcp-remote#sh crypto ipsec clie ezvpn
Easy VPN Remote Phase: 8
Tunnel name : branch
Inside interface list: Vlan1
Outside interface: Virtual-Access2 (bound to FastEthernet4)
Current State: IPSEC_ACTIVE
Last Event: MTU_CHANGED
DNS Primary: 172.19.217.95
Default Domain: cisco.com
Save Password: Allowed
Configuration URL [version]: 
Config status: not applied, Last successfully applied version: 0
Current EzVPN Peer: 18.104.22.168 (
ctcp-remote#sh crypto sess detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal,
T - cTCP encapsulation
X - IKE Extended Authentication
Session status: UP-ACTIVE
Peer: 22.214.171.124 port 500 fvrf: (none) ivrf: (none)
IKE SA: local 126.96.36.199/500 remote 188.8.131.52/500 Active
Capabilities:CXT connid:2005 lifetime:23:51:41
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 4524266/3117
Outbound: #pkts enc'ed 3 drop 0 life (KB/Sec) 4524265/3117
cTCP is available for all EasyVPN Servers and Remotes, including Cisco integrated services routers, VPN 3000 concentrators, and adaptive security appliances. Cross testing has been done between the Cisco IOS Router headend and the Cisco VPN 3002 hardware client, Cisco VPN 3000 headend and Cisco IOS Remote, and Cisco ASA headend and Cisco IOS Remote.
Cisco VPN 3000
Figure 3 shows the cTCP configuration on the VPN 3000 concentrator. It enables IPsec over TCP and specifies the TCP ports for the concentrator to listen to.