Tunnel is Established but Unable to Pass Traffic
If, over a period of time, the tunnel in the Administration > Administer Sessions page shows Established but the counters for Bytes Tx or Bytes Rx shows zero or the same number, then work through the following steps to troubleshoot the issue:
Step 1. Check the filter for the tunneled traffic.
If you have a filter for the tunneled traffic, choose None, and see if the traffic is flowing across the tunnel properly. To select None for the tunneled traffic filter, go to Configuration > Tunneling and Security > IPsec > LAN-to-LAN, and select your LAN-to-LAN Connection and click on Modify. On the next Window, select None for the Filter. If the traffic flows across the tunnel without problems, verify the Filter by going into Configuration > Policy Management > Traffic Management > Assign Rules to Filter for your specific filter rules. Check the rules being applied by going into Configuration > Policy Management > Traffic Management > Rules > Modify, and be sure the desired traffic is allowed by the rules.
Step 2. Check the routing issue.
If you have a routing issue, you might run into a problem with one side sending packets across the tunnel but the other side not responding. This can be verified by going to the Administration > Administer Sessions page. The Bytes Tx is for Transmit and Bytes Rx is for Receive. This problem might be caused by an overlap in the network. Take an example to illustrate this problem. Assume that you have a LAN-to-LAN tunnel between the central and remote site. Additionally, assume that your LAN segment for the remote site is 10.1.1.0/24, which overlaps with the LAN segment of the central site, which is 10.1.0.0/16. In this circumstance, if the Remote VPN Concentrator is the initiator of the tunnel, the tunnel will be built up, but the head end will be unable to route packets to the remote site with the default gateway. This is because you will have a more specific route for network 10.1.0.0/16 pointing to the 10.1.0.1 as the next hop, which is local to its network. So, to overcome this problem, in addition to your default gateway, you must have a more specific route for the 10.1.1.0/24 network pointing to the next hop, which is the default gateway for this Central side Concentrator.
Step 3. Check the Network Address Translation (NAT) issue.
When working with the IPsec tunnel, you can encounter two NAT issuesone when NAT is on the VPN Concentrator; and the other when NAT/PAT is between the Concentrators:
- NAT On the VPN Concentrator Having NAT on the VPN Concentrator is required if you have the same network on the LAN sides of both Concentrators. For instance, if you have 10.1.0.0/24 network on both sides of the tunnel, you need to translate one side of the tunnel to some other network address, so that addresses are unique. It is recommended to perform the translation on the head end (central site). Also note that for outbound traffic, NAT is applied on the source address, and for inbound traffic NAT is applied on the destination address. The destination NAT (d-NAT) is not supported on the Concentrator as of the writing of this book. For more details on how to apply NAT for LAN-to-LAN tunnels, refer to the following link: http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/4_7/config/polmgt.htm#wp1640172
You must be running VPN Concentrator version 3.6 to configure NAT for a LAN-to-LAN setup. More details on configuration can be found in the following location:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a00801ae24c.shtml
- NAT/PAT between the Concentrators If you have NAT/PAT configured between Concentrators, you must configure NAT-T (NAT-Transparency) on the VPN Concentrators so that the tunnel gets built up on UDP/4500. When the NAT-T is configured, both VPN Concentrators detect the presence of a NAT device, and tunnel negotiation takes place on UDP/4500. As the initial negotiation takes place using UDP/500, you need to open up UDP/500, UDP/ 4500, and ESP for successful tunnel establishment and for passing data traffic across the tunnel. For more details on this subject, go to the following links:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/4_7/config/tunnel.htm#wp1029463
For NAT-T configuration details between a VPN client and Concentrator (the same method can be used for VPN Concentrator LAN-to-LAN tunnel), refer to the following link:
http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2284/products_tech_note09186a00800946af.shtml
Interpretability issues with other vendors
Troubleshooting interoperability issues that occur between Cisco devices and devices from other vendors can be tricky sometimes, but if the devices are configured correctly, many problems can be avoided without even running a debug. All the techniques discussed in the preceding section are applicable for troubleshooting VPN 3000 concentrators with other vendor devices. Following are two suggestions that will help in interoperating a VPN 3000 appliance with other vendors' devices:
Start with configuring the two ends side-by-side with exact Matching policies (both phase I and Phase II). Table 8-5 lists the minimum required parameters for Phases I and II.
Table 8-5. Required Parameters for Phase I and II Phase I Parameters
Phase II Parameters
IKE authentication method
IPsec mode (tunnel or transport)
Hash algorithm
Encryption algorithm
DH group
Authentication algorithm
ISAKMP SA lifetime
PFS group
Encryption algorithm
IPsec SA Lifetime
Matching pre-shared secret
Interesting traffic definition
Turn off vendor-specific features such as Mode-config, x-Auth, IKE keepalive, Dead Peer Detection (DPD) and so on, and then build up the tunnel. Once the tunnel build-up is confirmed, start adding extra unique features that are supported by the concentrator.
Remote Access VPN Connection