| 6.4 |  | Site-to-Site IPSec VPN Using Pre-shared Keys |
| 6.4.1 |  | Tasks to configure IPSec |

| This section presents an overview of the major IPSec configuration tasks that must be performed to build a site-to-site IPSec VPN or a router-to-router IPSec VPN using pre-shared keys . Site-to-site IPSec VPNs can be established between any combination of routers, firewalls, concentrators, clients, and other devices that are IPSec compliant.

The use of pre-shared keys for authentication of IPSec sessions is relatively easy to configure, yet does not scale well for a large number of IPSec clients. The process for configuring IKE pre-shared keys in Cisco IOS software for Cisco routers consists of the following four major tasks:

- Task 1 is to prepare for IPSec. This task involves determining the detailed encryption policy, identifying the hosts and networks to protect, determining details about the IPSec peers, determining the needed IPSec features, and ensuring existing ACLs are compatible with IPSec.
- Task 2 involves configuring IKE. This task includes enabling IKE, creating the IKE policies, and validating the configuration.
- Task 3 is configuring IPSec. This task includes defining the transform sets, creating crypto ACLs, creating crypto map entries, and applying crypto map sets to interfaces.
- Task 4 is to test and verify IPSec. Using show, debug, and related commands to test and verify that IPSec encryption works. These commands can also be used to troubleshoot problems.

IKE peer authentication using pre-shared secrets is the simplest authentication to configure, but has several serious limitations. The authentication is based on a pre-shared secret (both peers share a secret string (password) between them; and this secret is exchanged securely out-of-band). During the IKE peer authentication process, peers perform a PPP CHAP-like exchange of random values, hashed with the pre-shared secret key. Authentication via pre-shared secrets uses hashing and is therefore very fast. IKE peer authentication using pre-shared secrets works in the following manner (the description is simplified for clarity):

1. Peer A randomly chooses a string and sends it to peer B.
2. Peer B hashes the received string together with the pre-shared secret and yields a hash value, dependent on the random string and the pre-shared secret.
3. Peer B sends the result of hashing back to peer A.
4. Peer A calculates its own hash of the random string, together with the pre-shared secret, and matches it with the received result from the other peer. If they match, peer B knows the pre-shared secret, and is considered authenticated.
5. Now peer B randomly chooses a different random string and sends it to peer A.
6. Peer A also hashes the received string with the pre-shared secret.
7. Peer A sends the authenticated hash back to peer B.
8. Peer B locally hashes the random value and the pre-shared secret and matches it against the received authenticated hash. If they are equal, peer A is also authenticated.

When both peers authenticate each other, the peer authentication procedure is complete. The main limitation of pre-shared secret authentication is the requirement to base the pre-shared secret on the IP address of the remote peer, not its IKE identity. This can impose significant problems in an environment with dynamic peer addresses such as dial-up users, DHCP users, and so on.