The “ping” command has been the “de facto” troubleshooting protocol used mainly for testing connectivity and communication between two hosts. As we all know, the ping command sends “ICMP” packets to the other end and waits for ICMP reply packets to come back.
From ASA 8.4(1) and later, Cisco introduced an enhanced version of the ping command. This is the “ping tcp”. It allows the ASA device to send any TCP packet (instead of ICMP) from any source IP to any destination IP on any port (source or destination).
This is great for troubleshooting purposes as we will see in the example below. By sending TCP packets you can also verify if remote services are up and running, in addition to verifying that routing and connectivity is also established.
Let’s see a troubleshooting scenario that you can use the “ping tcp” command. This has to do with a VPN site-to-site network as shown below:
From the diagram above, we have the following (popular) scenario:
The two sites (HQ Site – ASA1 and Remote Site – ASA2) are connected over the Internet with a site-to-site IPSEc VPN tunnel.
The tunnel is established between the two public IP addresses of the firewalls (22.214.171.124 and 126.96.36.199). Also, the only traffic allowed to pass through the VPN tunnel is traffic between the two private LAN subnets (192.168.1.0/24 and 192.168.2.0/24).
You are the firewall administrator located in the main HQ Site and you are trying to troubleshoot if the VPN is working or not between HQ Site and Remote Site.
Also, assume that you don’t have any hosts connected yet on the Remote Site LAN (or maybe you don’t have access to any of the hosts there). However, from the HQ Site you are able to connect (with SSH for example) to ASA2 on the Remote Site.
We want to make sure that VPN tunnel is established, that traffic can flow between 192.168.1.0 and 192.168.2.0 (and vice-versa), and also that hosts in “Remote Site” will be able to access the “RDP Server” (192.168.1.100) located in HQ Site using Remote Desktop Protocol (TCP port 3389).
Assume we are connected to ASA2. Let’s use the “ping tcp” command for troubleshooting:
ASA2# ping tcp
Target IP address: 192.168.1.100 <— This is the RDP Server in HQ Site
Destination port: 3389 <— Specify port of RDP Server
Specify source? [n]: y
Source IP address: 192.168.2.1 <— use a source IP from Remote Site LAN
Source port:  1000 <— any source port you want
Repeat count: 
Timeout in seconds: 
Type escape sequence to abort.
Sending 5 TCP SYN requests to 192.168.1.100 port 3389
from 192.168.2.1 starting port 1000, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 50/50/50 ms
With the above we have verified that everything is working fine. Traffic from source IP 192.168.2.1 can reach the RDP Server (192.168.1.100) on port 3389 over the VPN tunnel.
You can use also the commands “show crypto ipsec sa” and “show crypto isakmp sa” to see that VPN packets are encrypted/decrypted etc.