Step 2-3 Configure Preshared Keys

IPSec peers authenticate each other during IKE negotiations using the preshared key and their IKE identity. The IKE identity can either be the device IP address or the host name. The router IOS defaults to the IP address and doesn’t add a line to the configuration, unless the host name option is used.

To use the host name identity method, use the global crypto isakmp identity command. The no form of this command resets the default value (address). The command syntax is as follows:

Rtr1(config)#[no] crypto isakmp identity {address | hostname}
Rtr1(config)#crypto isakmp identity hostname

Using the host name identity method makes the most sense if a DNS server is available on the network to resolve the name. If not, the following example shows using an IP Host command entry on the router to handle the name resolution:

Rtr1(config)#ip host Rtr2.domain.com 10.0.50.2

Use the global crypto isakmp key command to configure a preshared authentication key whenever you specify preshared keys in an ISAKMP policy. Use the no form of the command to delete a preshared authentication key. The command syntax for both the address and the host name option is as follows:

Rtr1(config)#[no] crypto isakmp key keystring address peer-address [mask]
Rtr1(config)#[no] crypto isakmp key keystring hostname peer-hostname

keystring	The preshared key. Any combination of alphanumeric characters up to 128 bytes. Must be identical on both peers.
mask	(Optional) Defines a subnet address for the remote peer. Indicates the remote peer ISAKMP identity will be established using the preshared key only. With the mask, keys are no longer restricted to only two users. Added v12.1(1)T.

A given preshared key is shared between two peer devices. While it’s possible for Rtr1 in the scenario to use the same key with all remote peers, the more secure approach is to use different keys with each pair of peers.

The next example shows IKE and preshared key (cisco123) for Rtr1 and Rtr2 using the address identity method. The IKE policies are compatible. Because the hash algorithm SHA-1 is the default value, it needn’t be configured.

Rtr1(config)#crypto isakmp key cisco123 address 10.0.50.2 
Rtr1(config)#crypto isakmp policy 100
Rtr1(config-isakmp)#authentication pre-share  
Rtr1(config-isakmp)#encryption 3des
Rtr1(config-isakmp)#group 2
Rtr1(config-isakmp)#lifetime 43200
Rtr1(config-isakmp)#exit

Rtr2(config)#crypto isakmp key cisco123 address 10.0.1.21 
Rtr2(config)#crypto isakmp policy 100
Rtr2(config-isakmp)#authentication pre-share  
Rtr2(config-isakmp)#encryption 3des
Rtr2(config-isakmp)#group 2
Rtr2(config-isakmp)#lifetime 43200
Rtr2(config-isakmp)#exit

Because both devices are under the administrative policies of a single entity, it makes sense that the policy priority value might be the same on both devices. That isn’t a requirement, though, and it would be unlikely when the two peers are from different organizations. The important thing is the parameters are the same.

Note

One exception to matching parameters is the lifetime can be shorter on the destination peer and that value will be used. The shorter of the two lifetimes is always used. A shorter lifetime, in theory, increases the security.

Step 2-4 Verify the IKE Configuration

Use the show crypto isakmp policy command to display configured and default policies. An example of IKE policy for Rtr1 is shown in the Step 2-2 section. The show running-config command can also be useful, but the parameters using default values are omitted for brevity.