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.
|
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 |
|
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.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 |
TCP |
Data |
|||
|
-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
|
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.
|
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 (128 bit encryption) |
|
|
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-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 SocondsFigure 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 SetThe 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 LifetimesThe 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 ACLsThe 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.
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 InterfaceFor 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
Continue reading here: Advanced IPsec VPNs Using Cisco Routers and CAs Was this article helpful? |
||||||||||||||||||||||||