It depends on the problems with the VPN.

Note 1:

If the VPN is not being established, the first step is to check the access-list hit counts. On IOS, the command is "show ip access-list". This will display all configured access-lists including a hit counter to show which ones have been invoked. VPN tunnel initiation, via the crypto map, requires an access-list to specify candidate encryption traffic. If the access-list is not being invoked, IPSec will not generate the VPN. This is a fairly common problem. Often, access-lists are not written correctly to adequately identify candidate encryption traffic. A common mistake involves port operators in access-lists. If one wants to initiate reciprocal http traffic between two sites, two crypto access-list statements are required. Here's the scenario:

User at private network site A wants to web browse to web-server at private network site B. As this is private traffic between sites, the administrator configures crypto access-lists to stimulate a VPN connection between the respective private network sites. The crypto access-list on the VPN router at private network site A should be configured as follows:

SITE A ROUTER

!

access-list 101 permit tcp 10.1.1.0 0.0.0.255 host 10.2.2.10 eq www

!

When used in a crypto map, this access list stimulates encryption for all traffic in the 10.1.1.0 subnet destined for host 10.2.2.10 (the web server at private network site B). Site B must have a reciprocal access-list to encrypt traffic from the web-server back to the client at site A.

Router B

!

access-list 101 permit tcp host 10.2.2.10 eq www 10.1.1.0 0.0.0.255

!

This access-list on the private network site B router encrypts return traffic from the web-server. Because replies to a web-browser will come from port 80 on the web-server, the access-list must specify this return traffic for encryption. If both private network site A and B have web-servers that will be accessed from clients on the other network, then both routers must have access-lists as follows:

ROUTER A

!

access-list 101 permit tcp 10.1.1.0 0.0.0.255 host 10.2.2.10 eq www

access-list 101 permit tcp host 10.1.1.10 eq www 10.2.2.0 0.0.0.255

!

ROUTER B

!

access-list 101 permit tcp 10.2.2.0 0.0.0.255 host 10.1.1.10 eq www

access-list 101 permit tcp host 10.2.2.10 eq www 10.1.1.0 0.0.0.255

!

Notice that the first access-list statement encrypts outbound-initiate traffic from a client to a web-server and the second access-list encrypts outbound-reply traffic from a web-server to a client. Both statements must be reciprocal in order to stimulate creation of the IPSec VPN tunnel.

Note 2:

IPSec is a two-step process. Step one uses IKE to negotiate the parameters for IPSec encryption, hash protocols, and encryption key exchange for subsequent IKE traffic. This step is known as IKE Main_Mode (MM) - also known as or IKE Phase 1. IKE uses MM negotiation to protect subsequent traffic that will negotiate actual IPSec date encryption and hashing protocols. The point is, IKE does not want to perform the IPSec data encryption and hash protocol negotiation in the open, so it first negotiates encryption and hash protocols to protect its own messaging traffic. If IKE MM completes successfully, IKE enters Quick Mode (QM) - also known as IKE Phase 2. IKE QM negotiates the encryption, hash protocols, and key exchange to protect actual data traffic. IKE QM establishes security associations (SA) between peer VPN devices that constitute a profile for how to transform VPN traffic vis-à-vis specific encryption and hashing protocols. In sum, IPSec needs a total of three SAs per session, per peer VPN devices. IKE generates an SA for its own traffic during IKE MM, and two SAs for protecting actual data traffic during IKE QM. IKE QM negotiates two SAs for IPSec data protection because these SAs are unidirectional in nature. One SA is explicitly for outbound traffic from the head-end site to the remote-site. The other SA is explicitly for inbound traffic from the remote-site to the head-end site - ergo, one SA for each direction. Additionally, each SA will use the same encryption and hash protocol profiles.

All of the steps involved in getting IPSec SAs up and running to protect data traffic are quite complex. Failures can occur during any of the IPSec negotiation steps, causing VPN initiation to fail.

Some common points of failure are as follows:

Problem: IKE MM negotiation fails

Solutions:

· IKE policy profiles must be identical on both routers used to form the VPN tunnel.

· IKE keys must be identical on both routers used to form the VPN tunnel.

· Detection:

· You can tell if IKE policy profiles do not match by studying the output of the IKE debug: "debug crypto isakmp". If you see a statement during IKE MM negotiation to the effect "atts. not acceptable", this is a clue that the profiles on both devices do not match. Atts. stands for attributes.

· You can tell if IKE key strings do not match by also studying the output of the IKE debug. If you see a statement during IKE MM negotiation to the effect "sanity check failed", this is your clue that the IKE keys do not match.

Problem: IKE QM negotiation fails

Solutions:

· IPSec policy profiles must be identical on both routers used to form the VPN tunnel.

· Access-lists must be mirrored and reciprocal on both routers used to form the VPN tunnel.

· Detection:

· You can tell if IPSec policy profiles do not match by studying the output of the IKE debug: "debug crypto isakmp". If you see a statement during IKE QM negotiation to the effect "atts. not acceptable", this is a clue that the profiles on both devices do not match.

· Likewise, if the access-list statements are not mirrored and appropriately reciprocal, you will see an "atts. not acceptable" message.

Note 3:

It is important to ensure VPN services on a Cisco router can keep up with encryption demands. Cisco offers hardware-assist encryption accelerators for the following routers: 1700, 2600,3600, 7100, and 7200 series. The encryption accelerators dramatically boost the encryption performance of the above-mentioned routers by off-loading the encryption, hash, and key derivation process from the main-CPU. In many cases this can yield a 10-fold or more increase in performance.

Before using encryption accelerator cards there are a couple issues to consider.

First of all, one should consider the speed of the outbound link sending encrypted traffic. If one is using a fractional T-1 with a 128 or 256Kb/s Frame Relay CIR, then the performance boost from the accelerator is wasted. Remember, encryption performance is only as useful as the slowest outbound link. Why boost the encryption performance of a 1720 router to 3Mb/s when a slow link can’t even send traffic at the encryption rate?

Second of all, one should specify candidate encryption traffic as granular as possible. Consider what specific traffic between VPN routers truly must be encrypted. Should all traffic between sites be encrypted? Usually, the answer is no. ICMP traffic might not need to be encrypted. Outbound Internet traffic should not be encrypted. Site-to-site http traffic might or might not need to be encrypted. Site-to-site SQL traffic may need to be encrypted. By narrowing the scope of encrypted traffic, the router will save processing cycles and operate more efficiently.

These recommendations constitute a general approach to dealing with VPN problems. Some IOS software versions handle IPSec traffic with greater stability then other IOS versions. Specific bugs and maddening configuration problems should be dealt with by referencing on-line documentation or contacting Cisco's TAC (Technical Assistance Center).

Good luck!