Configuring a Cisco Router for IPsec Using Preshared Keys

IPsec is not a protocol but a framework of open-standard protocol suites that provides origin authentication, data integrity, data confidentiality, and antireplay protection. IPsec runs over IP and uses Internet Key Exchange (IKE) to negotiate the security association (SA) between the peers. Parameters must be configured for both IKE and IPsec SAs.

How IPsec Works

Five specific steps are required to create and terminate an IPsec VPN tunnel. The endpoints perform different functions to establish the encrypted connection at each step. Figure 19-3 describes the steps required to create and terminate the IPsec tunnel.

Figure 19-3. Creating an IPsec VPN Tunnel t'1 Sou

[View full size imagel

S»p 1

Step?

Step 3

4

Step 5

CûfljMCteyi TurmiitfirJ

New York f

Destination

Step 1. The user at the source computer in San Francisco initiates a connection to the destination system in New York. The router in San Francisco recognizes the traffic as "interesting traffic" because of the configured ACL and initiates the IKE process with the router in New York.

Step 2. The endpoint routers use IKE to authenticate each other as IKE peers and negotiate the IKE SA. At this time, a secure channel is established allowing for negotiation of the IPsec SA. This is referred to as IKE Phase 1.

Step 3. IKE is again used to negotiate the IPsec SA between the peers. When the negotiation is completed, the IPsec peers have an established SA and are prepared to transfer data. This is referred to as IKE Phase 2.

The tunnel is established and the IPsec SA information is stored in the SA database on both SA peers. Further key negotiations take place per the parameters negotiated during Phase 2.

Step 4. The connection terminates when it times out or is deleted from either peer.

This section describes configuring VPN routers with preshared keys for site-to-site connectivity with VPNs.

Note

Internet Key Exchange (IKE) is a protocol based on ISAKMP/Oakley, which stands for Internet Security Association and Key Management Protocol (with Oakley distribution), and supports IPsec by providing a private, authenticated key management channel through which the peers can communicate and negotiate session keys for AH and ESP and to negotiate encryption, authentication, and compression algorithms for the session. IKE is used to perform authentication for IPsec peers, negotiation of IKE and IPsec SAs, and establishment of keys for the encryption algorithms used by IPsec. The terms IKE and ISAKMP are used interchangeably throughout this chapter.

To configure IPsec encryption on the Cisco router, you must complete four steps. Each task includes specific subtasks:

Step

1.

Select the IKE and IPsec parameters.

Step

2.

Confiaure IKE.

Step

3.

Confiaure IPsec.

Step

4.

Test and verify the IPsec configuration.

Step 1: Select the IKE and IPsec Parameters

The process for configuring a router for an IPsec VPN is not a difficult one. It is, however, a complex process with multiple tasks and subtasks and requires significant attention to detail. The first task involves selecting the initial configuration parameters for the VPN connection and determining which configuration is most appropriate. If you make all the configuration decisions prior to configuring either device, you can greatly reduce the risk of a configuration error. This task is divided into five subtasks:

Step 1. Define the IKE (Phase 1) policy.

Step 2. Define the IPsec policies.

Step 3. Verify the current router configuration.

Step 4. Verify connectivity.

Step 5. Ensure compatible access lists.

Define the IKE (Phase 1) Policy

The importance of IKE Phase 1 is that it provides the negotiation to create a secure channel through which the Phase 2 negotiation can take place. You must consider several items when determining the IKE Phase 1 policies. Following is a list of each item with its specific purpose:

• Select a key distribution method This item is usually determined by the expected size of the network. For networks that only require a few VPN peers, you can manually distribute the keys (configure each peer manually). For large networks, it is recommended to use a certificate authority (CA) server. This method allows for significant growth because a trusted CA identifies each IPsec peer. If you are not manually distributing the keys, you need to implement the ISAKMP to support the method of key distribution you have selected.

• Select an authentication method There are several ways to configure the routers to authenticate themselves during Phase 1 of the IKE negotiation when establishing the SA. The configuration to be used is usually determined by the number of VPNs connected to the router and how dynamic the network environment will be. Three different configuration types are used:

- Preshared keys If your organization only requires VPN connectivity with few locations, you might want to use a static configuration on the router. This static configuration is referred to as preshared keys because the keys are manually configured on both peers. Preshared keys are alphanumeric keys (similar to passwords) configured on each router and must match exactly for the routers to negotiate the connection. Management of multiple VPN connections using preshared keys can become cumbersome as the number of connections grows.

- RSA signatures RSA is a public key cryptography system using digital certificates authenticated by RSA signatures.

- RSA-encrypted nonces An RSA nonce is a random value generated by the peer that is encrypted using RSA encryption. This method requires you to configure the RSA public key and designate the peer. This method is more secure because a different nonce is created with every negotiation.

• Identify the ISAKMP peer The ISAKMP peer is the router at the other end of the VPN connection that is functioning as the termination point. It is the device that you negotiate with to create the VPN tunnel. The IPsec peer is identified either by IP address or host name.

• Select the ISAKMP policies for the connection It is important that the ISAKMP policies for both peers match. If the configurations differ on each peer, they cannot negotiate the VPN connection. You can configure multiple policies on each router, however, because each router will search for a matching policy. The following items must be determined when selecting the ISAKMP policies:

- Message-encryption algorithm Cisco IOS VPN routers support two encryption algorithms:

Data Encryption Standard (DES) DES is a 56-bit symmetric encryption algorithm. It uses a 64-bit block of plain text and converts it into cipher text of the same size, encrypting it with a secret key. The key length is also 64 bits, but 8 bits are used for parity, leaving the effective key length at 56 bits. Although still widely used, DES is a somewhat outdated algorithm and should not be used if your data is highly sensitive. It is commonly used for VPN connections to locations outside the United States that cannot purchase higher levels of encryption because of U.S. technology export policies.

Triple Data Encryption Standard (3DES) 3DES is a 168-bit symmetric encryption algorithm. 3DES just applies three different phases of DES, effectively tripling the key length to 168 bits. The data is encrypted using three stages of DES using a different 56-bit key for each stage. - Message-integrity (hash) algorithm The hash algorithm converts message input into a fixed-length output called the message digest. The message digest is then put into a digital signature algorithm, and the output becomes a digital signature for the message. Because the message digest is usually much smaller than the actual message, it is more efficient to sign the digest rather than the message itself. Keyed-Hashing for Message Authentication (HMAC) is a variant that provides an additional layer of security by performing additional cryptographic keying and a secret key for calculation and verification of the message authentication values. HMAC is a variant that can be added to the supported hash algorithms. Cisco IOS VPN routers support two hash algorithms:

Secure Hash Algorithm l (SHA-l) The output of SHA-1 is 160 bit. Because the output is larger than MD5, SHA-1 is considered to be more secure; however, it requires more CPU cycles to process.

Message Digest 5 (MD5) The output of MD5 is 128 bit. MD5 is slightly faster to process because of its smaller message digest.

- Peer-authentication method This is the method that each peer uses to authenticate itself to the other peer. The three methods are explained in the previous section (preshared keys, RSA signatures, and RSA-encrypted nonces).

- Diffie-Hellman key exchange Diffie-Hellman is a public key cryptography protocol used between two IPsec peers to derive a shared secret over an unsecured channel without transmitting it to each other. There are seven Diffie-Hellman groups with varying key lengths. This chapter focuses on the first two Diffie-Hellman groups because they are currently the most commonly used on VPN enabled routers: group 1 is 768 bits, and group 2 is 1024 bits.

- IKE SA lifetime The SA lifetime is the time that each system waits before initiating another key exchange. This allows the systems to constantly renegotiate the connection, greatly reducing any chance of an unauthorized listener being able to decrypt the connection.

Table 19-2 lists the IKE policy parameters that can be used when determining the IKE Phase 1 policies.

Table 19-2. IKE Policy Parameters (Phase i)

Parameter

Strong

Stronger

Encryption algorithm

DES

3DES, AES, AES-192, AES-265

Parameter

Strong

Stronger

Hash algorithm

MD5

SHA-1

Authentication method

Preshare

RSA signature RSA-encrypted nonce

Diffie-Hellman key exchange

Group 1

Group 2 Group 5

SA lifetime

86,400 seconds

<86,400 seconds

The peers cannot negotiate the connection if the policies on both peers do not match. Figure 19-4 depicts the peer configurations for the VPN connection between New York and San Francisco.

Figure 19-4. VPN Peer Configuration (New York and San Francisco)

[View full size image]

San Francisco

SO TS2.16S3.J

Paismoter

San Franoieço

York

EneryjUton Algorithm

AES 256

AES 256

hash Algorithm

SHA-1

SHA-i

AulhenSieation Mel hod

Prestiarod Koy

Prashared Ksy

Di1!i£ -KS Ilmart Key Exchange

2

2

SALIIoli™

afi.4M Seconds

85.400 SectHids

Post Address

192.163.1.1

192.163.3.1

EC mto 1.254

As Figure 19-4 illustrates, the IKE configuration parameters on both routers must match for the negotiation to complete successfully. Define the IPsec Policies

IPsec uses two different modes for VPNs. Each of these modes has a specific purpose, and it is important to select the correct mode when configuring your VPN. The two VPN modes are as follows:

• Tunnel mode The tunnel mode is commonly used for both site-to-site VPNs and access VPNs where the destination is not the VPN endpoint. Both the source and destination (in the original IP header) information are encrypted when using the tunnel mode and are not decrypted until they reach the destination endpoint.

• Transport mode The transport mode is most commonly used when the destination is the VPN endpoint. The original IP header is not encrypted when using the transport mode.

The IPsec policies are often referred to as the IKE Phase 2 policies because they occur during Phase 2 of the IKE negotiation. IKE Phase 1 establishes a bidirectional secure tunnel known as the IKE SA, which is used to complete the negotiation of the IPsec SA. The routers must negotiate two separate unidirectional IPsec SAs to facilitate bidirectional traffic between the peers.

Many configuration options are available when configuring IPsec. It is important to select the best possible configuration for the VPN connection. Follow these steps when defining the IPsec parameters:

Step 1. Identify the IPsec protocol necessary for the type of traffic. Two different IPsec protocols perform specific functions:

Encapsulating Security Payload (ESP) ESP provides data authentication, encryption, and antireplay services. ESP is protocol number 50 assigned by the Internet Assigned Numbers Authority (IANA). ESP is primarily responsible for getting the data from the source to the destination in a secure manner, verifying that the data has not been altered, and ensuring that the session cannot be hijacked. ESP provides origin authentication, data integrity, and antireplay protection. ESP can also be used to authenticate the sender either by itself or in conjunction with AH. ESP can be configured to encrypt the entire data packet or only the payload of the packet. Figure 19-5 shows how ESP encapsulates the normal IPv4 packet in the transport mode and in the tunnel mode.

Figure 19-5 illustrates the normal IPv4 packet before and after encapsulation by ESP.

Figure 19-5. ESP and the IPv4 Packet

[View full size imagel

IPV4 Packet without ESP Encapsulation

Origina! IP Header

Data

IPv4 Packet with Encapsulation

Original IP Header

ESP Header

TCP

Data

ESP Trailer

ESP Authentication

-AultwrtJaated-

--

• Authentication Header (AH) AH provides data authentication and antireplay services. AH is protocol number 51 assigned by the IANA. The primary function of AH is origin authentication. AH does not provide any data encryption; it provides only origin authentication or verification that the data is from the sender. This functionality also prevents session hijacking. It is important to note that ESP only authenticates the payload, whereas AH authenticates the IP header. AH is not compatible with Network Address Translation (NAT) or Port Address Translation (PAT) because they change the source IP address, making it different from the source address in the authentication header. The IPsec peer then rejects the traffic because the source address in the IP header and the authentication header do not match. Figure 19-6 shows how AH effects the normal IPv4 packet in both the transport and tunnel modes.

Figure 19-6. AH and the IPv4 Packet

IPV4 Packet without Authentication Header

Original IP Header

TCP

Data

IPV4 Packet with Authentication Header

Original IP Header

Authentication Header

TCP

Data

Step 2. Select the appropriate IPsec transforms. Transforms and transform sets are the defined combination of IPsec algorithm and encryption algorithm. The combination you select can focus more on authentication, encryption, or combine to cover both. The following protocols, algorithms, and so on, are combined to create your transforms:

• IPsec protocol AH and ESP

• Encryption algorithm DES, 3DES, or AES

• Hash algorithm SHA-1 and MD5 (with or without HMAC)

Table 19-3 lists the possible combinations for transforms. When combined, the transforms make a transform set.

Table 19-3. IPsec Transforms

AH Transform

Description

ah-md5-hmac

AH, MD5 hash, HMAC variant (authentication)

ah-sha-hmac

AH, SHA-1 hash, HMAC variant (authentication)

AH Transform

Description

ESP Encryption Transform

Description

esp-null

ESP, Null encryption

esp-des

ESP, DES (56 bit encryption)

esp-aes

ESP, AES (128 bit encryption)

esp-3des

ESP, 3DES (168 bit encryption)

esp-aes 192

ESP, AES-192 (192 bit encryption)

esp-aes 256

ESP, AES-256 (256 bit encryption)

ESP Authentication Transform

Description

esp-md5-hmac

ESP, MD5 hash (HMAC variant)

esp-sha-hmac

ESP, SHA-1 hash (HMAC variant)

Step 3. Define the IPsec peer. You must define the router at the other end of the VPN connection by either host name or IP address.

Step 4. Define the local hosts or networks. Identify which local hosts or networks are allowed to send traffic through the VPN connection. This is completed by configuring ACLs on the router to define "interesting traffic," which will initiate the encryption.

Step 5. Select the type of SA initiation. Determine whether the IPsec SA should be negotiated by IKE or by using manual IPsec.

Verify the Current Router Configuration

You must verify that the current configuration of the router will not conflict with the new items that you want to add. You can use three commands to display the current router configuration:

• show running-configuration This command displays the current configuration that is running on the router. The show configuration command shows the last configuration that was saved to memory but does not display any changes that took place but were not saved. This command is the same as the show startup configuration because it displays the configuration the router will have when it startsany unsaved configuration changes are lost during a reboot.

• show crypto isakmp policy This command displays the current ISAKMP policy that is configured on the router. You can then verify that your planned configuration will not conflict with the current configuration.

• show crypto map This command can include the interface or the map name and displays any crypto map entries configured on the router. The crypto map includes the name, interface, and local address of the router; peer address; crypto access list; SA lifetime; and transform set name. The show crypto map command also tells you whether Perfect Forward Secrecy has been enabled for that connection. Perfect Forward Secrecy is a key-establishment protocol that generates a new public/private key pair with each session. The result is a dynamic key exchange that prevents an eavesdropper from decrypting messages using keys derived from previously captured data.

Verify Connectivity

Remember that encryption adds complexity to any network connection. You should always ensure connectivity between the SA peers before attempting to create a VPN connection. The best way to verify your connectivity is to attempt the type of connection that you intend to use after the encrypted connection is established. By doing so, you can ensure that you do not have any filters preventing the connection. If there is no connectivity between the peers, it will be impossible for them to negotiate the IKE SA and build the encrypted tunnel.

Ensure Compatible Access Lists

You must ensure that the access lists on the perimeter routers allow IPsec traffic. IKE runs over UDP port 500. If your perimeter routers are blocking UPD 500, you cannot negotiate the IKE SA. In addition, ESP and AH are protocol numbers 50 and 51, respectively. It is important that you verify that your current access lists do not block these protocols.

Step 2: Configure IKE

Now that you understand the importance of planning the configuration beforehand, refer to Figure 19-7 for the configuration settings for task 2.

Figure 19-7. IKE Configuration Settings

[View full size imagel

[View full size imagel

IKE Phase 1 Policy

Key Dislribution

tSAKMP

AullifiiHitatiCin

Pré -Shared Key

Encryption AbgOnlhfi

AES-25G

Hash Algorithm

SHA-1

Difiw-Hellrnan Group

2

IKE: SALilalimii

e&ioo

San Francisco so iteiffiji

Naw York

SiW.18.1 I

EQ 10.1Q t.iSJ

Figure 19-7 shows the standards that you plan to use when configuring IKE on both peers. This section shows the configuration of the router in New York for the VPN between New York and San Francisco. Configuration steps and commands are common for the Cisco certification exams. This exercise is designed to familiarize you with the different commands for configuring IKE, the purpose for each command, and how the commands interact. To configure IKE on the router, follow these four steps:

Step l. Enable IKE.

Step 2. Create the IKE policy.

Step 3. Configure the preshared key.

Step 4. Verify the IKE configuration.

Each of these steps is discussed in detail in the following sections.

Enable IKE

IKE is enabled by default. You should verify that it is enabled when you check the current configuration. IKE is enabled globally (on all interfaces) and must be enabled before you can use it on the router. Example 19-1 shows the command for enabling IKE on the router.

Example l9-l. Enabling IKE

NewYork#configure terminal

NewYork (config)#crypto isakmp enable

Create the IKE Policy

You can configure multiple IKE policies on a single router. The router runs through each policy in order based on the policy priority. The policy priority is a number between 1 and 10,000 assigned when the policy is created: the lower the number, the higher the priority. Because the router checks each policy in order, it is a good idea to give the most secure policy the lower number. The crypto isakmp policy command is input from the global configuration mode and will put you in the config-isakmp mode. Example 19-2 shows the command for creating the IKE policy.

Example l9-2. Creating IKE Policy

NewYork#configure terminal

NewYork (config)#crypto isakmp policy 100

NewYork (config-isakmp)#authentication pre-share

NewYork (config-isakmp)#encryption aes 256 NewYork (config-isakmp)#hash sha NewYork (config-isakmp)#group 5

Configure Preshared Key

Preshared keys (also known as preshared secrets) are alphanumeric keys manually configured on each peer. You must identify the peer and the key when performing the configuration. The peer is identified either by host name or IP address. The command for configuring the preshared key is as follows:

crypto isakmp key keystring address peer-address [mask]

or crypto isakmp key keystring hostname peer-hostname

Example 19-3 shows the command for defining the preshared key and the peer.

Example 19-3. Defining the Preshared Key and Peer

NewYork#configure terminal

(config)#crypto isakmp policy 100 (config-isakmp)#authentication pre-share (config-isakmp)#encryption aes 256

(config-isakmp)#hash sha (config-isakmp)#group 5 (config-isakmp)#lifetime 3600

(config)#crypto isakmp key abc123 address 192.168.3.1 255.255.255.255

Verify the IKE Configuration

Before moving on to the next task, it is a good idea to verify the changes you have just completed. It is much easier to correctly configure each step rather than troubleshoot the configuration if the VPN does not work. The show crypto isakmp policy command enables you to view the current configuration, and the output should match the combined examples listed previously. Example 19-4 shows the output from show crypto isakmp policy.

Example 19-4. Verifying the IKE Policy

NewYork#configure terminal config)#crypto isakmp key abc123 address 192.168.3.1 255.255.255.255 config)#crypto isakmp policy 100 config-isakmp)#authentication pre-share config-isakmp)#encryption aes 256

config-isakmp)#hash sha config-isakmp)#group 5 config-isakmp)#lifetime 86400

config-isakmp)#exit

NewYork#sh crypto isakmp policy

Global IKE policy

Protection suite of priority 10C

encryption algorithm: AES - Advanced Encryption Standard (256 bit keys). hash algorithm: Secure Hash Standard authentication method: Pre-Shared Key Diffie-Hellman group: #5 (1536 bit)

lifetime: 86400 seconds, no volume limit

Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard

Step 3: Configure IPsec

Just like the IKE configuration, it is important that the IPsec configuration matches on both peers for them to negotiate the IPsec SA. Figure 19-8 shows the configuration settings for Step 3.

Figure 19-8. IPsec Configuration Settings

[View full size image]

[View full size image]

IKE Phase 1 Policy

Key DislribuLitr>

tSAKMP

Aulhanncation

Pra-Sharefl Kay

Ëneryjiliixi AlgorrKim

AÈS-2EÎ

HasTi Algorithm

SHA-1

DiMi&'Hollman Group

i

IKE SA Lifetime

IPSec Policy AuLticnrication Tiarislorm osp-sha-îimac Encryjuion Trartsfonn e&p-aes-2S6

IPSec SA Liffilimo

3600 Soconds

Figure 19-8 shows all the information needed to configure IPsec on both peers. This exercise configures only the router in New York. To configure IPsec on the router, follow these five steps:

Step 1. Create the IPsec transform set.

Step 2. Configure IPsec SA lifetimes.

Step 3. Create the crypto access lists.

Step 4. Create the crypto map. Step 5. Apply the crypto map.

Each of these steps is discussed in detail in the following sections.

Create the IPsec Transform Set

The IPsec transform set defines the parameters that each peer uses when negotiating the VPN connection. It is possible to configure multiple transform sets on the router. When negotiating the connection, each router compares transform sets until finding a match. (This negotiation takes place during IKE Phase 2.) This is not to say that the routers negotiate the transform sets; they just compare the transform sets until they find a match. If the routers do not find transform sets that match, they cannot create the VPN tunnel. Figure 19-9 depicts how the routers compare the transform sets when negotiating the VPN connection.

Figure 19-9 shows the routers comparing transform sets until they find a match at esp-aes 256 esp-sha-hmac.

Figure 19-9. Transform Set Comparison

[View full size image]

The command syntax for creating the IPsec transform set is as follows:

crypto ipsec transform-set transform set name [ trans form1 ][ transform2 ][ transform3 ]

Example 19-5 shows the command for creating the IPsec transform set.

Example 19-5. Creating the IPsec Transform Set

NewYork#configure terminal

NewYork (config)#crypto ipsec transform-set 20 esp-aes 256 esp-sha-hmac

Configure IPsec SA Lifetimes

The IPsec SA lifetime determines at what interval the routers renegotiate the connection. A constantly changing connection is extremely difficult to decrypt because the data sample continues to change, leaving no consistent data available for a cryptographer to decrypt. If a cryptographer were able to discover the keys for a connection, it would take more than the hour that those keys are valid. The global IPsec SA lifetime is configured in either seconds or kilobytes (amount of data that pass through the tunnel). The command syntax for defining the global IPsec SA lifetime is as follows:

crypto ipsec security-association lifetime { .seconds #### | kilobytes ####}

The default value is 3600 seconds (1 hour) or 4,608,000 kilobytes. The global IPsec SA lifetime is overridden by the SA lifetime that is added to the crypto map, and Cisco recommends that you use the default values. Example 19-6 shows the command for configuring the global IPsec SA lifetime to 30 minutes, or 4,400,000 kilobytes.

Example 19-6. Configuring the Global IPsec SA Lifetime

NewYork#configure terminal

NewYork (config)#crypto ipsec security-association lifetime seconds 1800

NewYork (config)#crypto ipsec security-association lifetime kilobytes 4400000

Create the Crypto ACLs

The crypto ACL defines interesting traffic for the router. Interesting traffic is the traffic protected by the VPN connection. Crypto ACLs determine which outbound traffic is encrypted and which goes out as clear text. Inbound traffic is also compared to the crypto ACL. If traffic comes in as clear text and should be encrypted, the router drops the traffic. When creating the crypto ACL, the terms permit and deny refer to encrypt and do not encrypt, respectively. The syntax of the command is as follows:

access-list ACL-number permit | deny protocol source-ip source wildcard destination-ip destination wildcard

Example 19-7 shows the command for configuring the crypto ACL for the connection from New York to San Francisco to encrypt all TCP traffic between those networks.

Example 19-7. Crypto ACL on the New York Router

NewYork#configure terminal

NewYork (config)#access-list 105 permit ip 10.10.1.0 0.0.0.255 10.10.3.0 0.0.0.255

With the preceding configuration, the router encrypts all traffic from the internal network at New York (10.10.1.0/24) destined for the San Francisco network (10.10.3.0/24) and expects that all traffic from San Francisco be encrypted. It is important that the crypto ACLs match at both ends of the connection to ensure that the traffic is able to flow.

Note

Because the IPsec SA is a unidirectional connection, you can configure the peers to only allow encrypted traffic to travel in one direction.

Create the Crypto Map

The crypto map is the component that consolidates all the IPsec configuration pieces. The following items are defined in the crypto map:

• Which traffic is to be encrypted (reference to the access list)

• How granular the protected data flow should be

• Where the encrypted data should be sent (the SA peer)

• The local address used for encrypted data (local router interface address)

• What security should be applied to the traffic (reference to transform sets)

• How the IPsec SA should be established (manual or IKE)

• Any other parameters for the IPsec SA

This command requires multiple lines. Each line of the command addresses a different portion of the configuration. The syntax of the crypto map command is as follows:

crypto map map-name seq-number connection

The command crypto map is entered from the global configuration mode and identifies the crypto map by name and sequence number. It also configures how the IPsec SA should be established. Table 19-4 lists the possible commands for configuring the IPsec SA.

Table 19-4. Crypto Map IPsec SA Commands

Readers' Questions

  • gregorio
    How to enable on a cisco router ipv4 ipsec authentication?
    5 months ago
    1. Configure your router's interface IP address(es).
    2. Configure the encryption domain.
    3. Enable IKE (IPsec key exchange protocol).
    4. Configure the preshared key.
    5. Configure the tunnel protection.
    6. Select a CA (Certificate Authority) for authentication.
    7. Create a certificate on the CA.
    8. Install the certificate on the router.
    9. Ensure that tunnel protection is enabled on both peers.
    10. Test the connection.
    • eyob
      What is a more recent and more powerful encryption algorithm widely available in most routers?
      7 months ago
    • AES (Advanced Encryption Standard) is a more recent and more powerful encryption algorithm widely available in most routers. AES is used for symmetric key encryption, meaning it uses the same key for both the encryption and decryption process. AES is currently one of the strongest and most secure encryption algorithms available.
      • vincent
        What encryption algorithm uses the same preshared key to encrypt and decrypt data?
        7 months ago
      • Symmetric encryption algorithms, such as the Advanced Encryption Standard (AES), use the same preshared key to encrypt and decrypt data.
        • luis
          When using ipsec, how can you ensure that each computer uses its own private key pair?
          7 months ago
        • You can use a certificate authority (CA) to issue each computer its own unique private key pair. The CA is responsible for verifying the identity of a node in an IPsec network and issuing it a private keypair. The private keypair is then stored securely on the node, and the public key is passed to the other nodes in the network. This ensures that each computer has its own private key pair and only those nodes in the network can access it.
          • jayden
            Which program would you use to configure your ipsec connections?
            8 months ago
          • The program you would use to configure your IPsec connections is an IPsec VPN client. The most popular IPsec VPN clients are FortiClient, Shrew Soft VPN, OpenVPN, and Cisco AnyConnect.
            • habte
              Does isakmp and ipsec use the same preshared key?
              1 year ago
            • No, Isakmp and IPsec use different preshared keys. Isakmp uses an authentication key (sometimes called an "extended authentication key" or "EAKEY") to authenticate the identity of the two communicating parties, while IPsec uses a "shared secret" to encrypt and decrypt data sent between the two parties.

              Disclosure: Some of the links above are affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.

              Command

              Description

              cisco

              This is the default value and indicates that IPsec will not be used but will be replaced with CET. This transform is being phased out.

              ipsec-manual

              This value indicates that IKE will not be used to establish the IPsec SA.

              ipsec-isakmp

              This value indicates that IKE will be used to establish the IPsec SA.

              dynamic

              This optional command specifies that a pre-existing static crypto map be referenced for the correct configuration. This option is only available after the ipsec-isakmp parameter.

              Example 19-8 shows the command for configuring the crypto map for the connection from New York to San Francisco.

              Example 19-8. Crypto Map on the New York Router

              NewYork#configure terminal

              NewYork(config)#crypto map SanFran 120 ipsec-isakmp

              NewYork(config-crypto-map) NewYork(config-crypto-map) NewYork(config-crypto-map) NewYork(config-crypto-map) NewYork(config-crypto-map)

              fmatch address 105 f set peer 192.168.3.1 fset pfs group5 set transform-set 20

              iset security-association lifetime seconds 1800

              If you want to create the same type of VPN connection to another IPsec peer, you can add another set peer line to the crypto map if the traffic matches that same access list.

              Apply the Crypto Map to the Correct Interface

              For the crypto map to take effect, it must be applied to the interface facing the peer. You must enter the interface configuration mode to apply the crypto map. Example 19-9 shows the command applying the crypto map to the Serial 0 interface on the router in New York.

              Example 19-9. Applying the Crypto Map to Interface S0

              NewYork#configure terminal

              NewYork(config)#interface fa0/1 NewYork(config-if)#crypto map SanFran

              Step 4: Test and Verify the IPsec Configuration

              It is best to verify your configuration beforehand instead of having to troubleshoot the connection if it is not working. Various show and debug commands enable you to check the current configuration, including the following:

              • show crypto isakmp policy Displays the configured IKE policies.

              • show crypto ipsec transform-set Displays the configured transform sets.

              show crypto ipsec sa Displays the current state of your IPsec SAs.

              • show crypto map Displays your current crypto maps.

              • show crypto dynamic-map Displays your dynamic crypto map set.

              debug crypto isakmp Enables debugging of IKE events. This command generates a tremendous amount of output and should be used only when traffic is low.

              • debug crypto ipsec Enables debugging of IPsec events. This command generates a tremendous amount of output and should be used only when traffic is low.

              Remembering that the configurations must match on both peers, it is best to compare the configuration from each router if possible. Figure 19-10 shows the configuration settings for this task.

              Figure 19-10. Configuration Settings Between New York and San Francisco

              [View full size imagel a

              IKE Phase 1 Policy

              Key Disuibutlon

              ISAKMP

              Autnenlieation

              Pre-Sharea Kay

              Encryption Aigofilfim

              AES-Î&6

              Hasti Algorithm

              SHA-1

              Diflie-Hsllnian QrouD

              2

              IKE 5A UTsltmo

              San Francisco —New York — / Internet \----— i

              SO 192,163.3.1

              SO 192.188.1.1

              IPSec Policy Authentication Transform osp-siia-hmae Encryption Transform esp-aes-256

              EO 10.10.1.254

              IPSec SA Lifetime

              3600 Seconds

              Example 19-10 shows the output from each command. You must verify that the configurations are sufficient for the VPN to function between New York and San Francisco, as shown in Example 19-10.

              Example 19-10. show Command Output from Peers

              [View full width]

              NewYork#show crypto isakmp policy

              Global IKE policy

              Protection suite of priority 10C

              encryption algorithm: hash algorithm: authentication method: Diffie-Hellman group: lifetime:

              Default protection suite encryption algorithm: hash algorithm: authentication method: Diffie-Hellman group: lifetime: NewYork#

              (256 bit keys)

              AES - Advanced Encryption Standard Secure Hash Standard Pre-Shared Key #5 (1536 bit)

              86400 seconds, no volume limit

              DES - Data Encryption Standard (56 bit keys) Secure Hash Standard Rivest-Shamir-Adleman Signature #1 (768 bit)

              86400 seconds, no volume limit

              San Francisco#show crypto isakmp policy

              Global IKE policy

              Protection suite of priority 10C

              encryption algorithm: hash algorithm: authentication method: Diffie-Hellman group: lifetime:

              Default protection suite encryption algorithm: hash algorithm: authentication method: Diffie-Hellman group: lifetime: SanFrancisco#

              (256 bit keys)

              AES - Advanced Encryption Standard Secure Hash Standard Pre-Shared Key #5 (1536 bit)

              86400 seconds, no volume limit

              DES - Data Encryption Standard (56 bit keys) Secure Hash Standard Rivest-Shamir-Adleman Signature #1 (768 bit)

              86400 seconds, no volume limit

              NewYork#show crypto ipsec transform-set

              Transform set 20: {esp-256-aes esp-sha-hmac} will negotiate = { Tunnel, },

              NewYork#

              San Francisco# show crypto ipsec transform-set

              Transform set 10: (esp-3des)

              Transform set 20: {esp-256-aes esp-sha-hmac}

              will negotiate = { Tunnel, }, Transform set 30: (esp-3des esp-md5-hmac) Will negotiate = (Tunnel, ),

              Transform set 40 (esp-3des ha-md5-hmac) Will negotiate = (Tunnel, ),

              NewYork#show crypto ipsec sa interface: FastEthernet0/1

              Crypto map tag: SanFran, local addr. 192.168.1.1 protected vrf:

              local ident (addr/mask/prot/port): (10.10.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.10.3.0/255.255.255.0/0/0) current_peer: 192.168.3.1:500 PERMIT, flags={origin_is_acl,} #pkts encaps: 321, #pkts encrypt: 321, #pkts digest 321 #pkts decaps: 321, #pkts decrypt: 321, #pkts verify 321 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 4, #recv errors 0

              local crypto endpt.: 192.168.1.1, remote crypto endpt.: 192.168.3.1 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1 current outbound spi: AE399F1B

              inbound esp sas: spi: 0xFE4F2F8(266662 64 8)

              transform: esp-256-aes esp-sha-hmac , in use settings ={Tunnel, }

              slot: 0, conn id: 2000, flow id: 1, crypto map: SanFran sa timing: remaining key lifetime (k/sec): (4 57 0617/1455) IV size: 16 bytes replay detection support: Y

              inbound ah sas:

              inbound pcp sas:

              outbound esp sas:

              spi: 0xAE3 9 9F1B(2 923 0118 67)

              transform: esp-256-aes esp-sha-hmac , in use settings ={Tunnel, }

              slot: 0, conn id: 2001, flow id: 2, crypto map: SanFran sa timing: remaining key lifetime (k/sec): (4 57 0617/1453) IV size: 16 bytes replay detection support: Y

              outbound ah sas:

              outbound pcp sas: NewYork#

              NewYork#show crypto map

              Crypto Map "SanFran" 120 ipsec-isakmp

              Peer = 192.168.3.1 Extended IP access list 105 access-list 105 permit ip 10.10.1.0 0.0.0.255 10.10.3.0 0.0.0.255 Current peer: 192.168.3.1

              Security association lifetime: 4608000 kilobytes/1800 seconds PFS (Y/N): Y DH group: group5 Transform sets={20, } Interfaces using crypto map SanFran: FastEthernet0/1

              NewYork#

              San Francisco#show crypto map

              Crypto Map "NY" 120 ipsec-isakmp

              Peer = 192.168.1.1 Extended IP access list 105 access-list 105 permit ip 10.10.3.0 0.0.0.255 10.10.1.0 0.0.0.255 Current peer: 192.168.1.1

              Security association lifetime: 4608000 kilobytes/1800 seconds PFS (Y/N): Y DH group: group5 Transform sets={20, } Interfaces using crypto map NY: FastEthernet0/1

              SanFrancisco#

              Continue reading here: Advanced IPsec VPNs Using Cisco Routers and CAs

              Was this article helpful?

              0 0