Site-to-Site IPsec VPNs with Cisco IOS Routers - Secure Connectivity - Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Part IV: Secure Connectivity

Chapter 14. Site-to-Site IPsec VPNs with Cisco IOS Routers

Building a site-to-site IPsec VPN is an essential part of many plans to meet the security requirements of customers. In this chapter, you will learn how to use the command-line interface (CLI) to configure a site-to-site IPsec VPN to securely connect two or more subnets over the Internet or an intranet.

This chapter teaches you how to configure a site-to-site IPsec VPN with preshared keys, using Cisco Configuration Professional. This ability includes being able to meet these objectives:

• Evaluate the requirements and configuration of site-to-site IPsec VPNs

• Use Cisco Configuration Professional to configure site-to-site IPsec VPNs

• Use CLI commands and Cisco Configuration Professional monitoring options to validate the VPN configuration

• Use CLI commands and Cisco Configuration Professional monitoring options to monitor and troubleshoot the VPN configuration

Site-to-Site IPsec: Planning and Preparation

Site-to-site VPNs are the option of choice for organizations of all kinds in implementing a corporate network across public and private networks. Internet-based VPN environments and Multiprotocol Label Switching (MPLS) VPN environments benefit from the flexibility of deployment and standards-based implementation of cryptographic mechanisms.

The choice of device-terminating VPNs, such as a firewall or a router, becomes a key factor in implementing site-to-site VPNs. Organizations benefit from leveraging their existing network elements and using an integrated approach to VPN deployments. This chapter highlights the use of Cisco IOS routers as site-to-site VPN termination points in IP Security (IPsec) environments.

Site-to-Site IPsec VPN Operations

IPsec VPN negotiation can be broken down into five steps, as shown in Figure 14-1, including Phase 1 and Phase 2 of Internet Key Exchange (IKE):

Step 1. An IPsec tunnel is initiated when Host A sends “interesting” traffic to Host B. Traffic is considered interesting when it travels between the IPsec peers and meets the criteria that is defined in the crypto access control list (ACL).

Step 2. In IKE Phase 1, the IPsec peers (routers A and B) negotiate the established IKE SA policy. Once the peers are authenticated, a secure tunnel is created using ISAKMP.

Step 3. In IKE Phase 2, the IPsec peers use the authenticated and secure tunnel to negotiate IPsec SA transforms. The negotiation of the shared policy determines how the IPsec tunnel is established.

Step 4. The IPsec tunnel is created and data is transferred between the IPsec peers based on the IPsec parameters configured in the IPsec transform sets.

Step 5. The IPsec tunnel terminates when the IPsec SAs are deleted or when their lifetime expires.

Figure 14-1. Site-to-Site IPsec VPN

Planning and Preparation Checklist

The following items should be considered in planning and preparing for a site-to-site VPN deployment:

Verify connectivity between peers: IPsec uses distinct protocols and ports for its operations. Ensure that protocol 50 (Encapsulating Security Payload [ESP]), protocol 51 (Authentication Header [AH]), and UDP port 500 (ISAKMP) traffic is not blocked at interfaces that are used by IPsec.

Define interesting traffic: It is common in site-to-site VPNs to find deployments where some traffic will use the VPN and some traffic will bypass it. This concept is known as split tunneling. It is important to define which traffic will trigger the establishment of the VPN (interesting traffic) and which traffic will travel outside the tunnel (noninteresting traffic).

Determine the cipher suite requirements: The choice of encryption algorithms for Phase 1 and Phase 2 of IPsec, as well as for the different services (confidentiality, integrity, and authentication), define the strength of protection and capacity planning considerations. The cipher suite is defined by the assets the organization is trying to protect and the level of risk it is willing to take. However, other considerations apply, such as compliance regulations. It is important to know that the cipher suite can be different for different peers. Multiple policies can be built on a given device, and they are negotiated differently with different peers. The resulting tunnels will provide varying levels of risk.

Manage monitoring, troubleshooting, and change: It is important to build all three areas in the planning process. This chapter illustrates some of the tools that are available to accomplish these tasks.

Building Blocks of Site-to-Site IPsec

IPsec has specific procedures that require configuration on the security appliance for the successful establishment of a VPN tunnel.

Interesting Traffic and Crypto ACLs

Interesting traffic is defined by crypto ACLs in site-to-site IPsec VPN configurations. Crypto ACLs perform these functions, illustrated in Figure 14-2:

Outbound: For outbound traffic, the crypto ACL defines the flows that IPsec should protect. Traffic that is not selected is sent in plaintext.

Inbound: The same ACL is processed for inbound traffic. The ACL defines traffic that should have been protected by IPsec, and discards packets if they are selected but arrive unprotected (unencrypted).

Figure 14-2. Outbound and Inbound Access Control Lists

Ultimately, traffic will be processed against ACL statements. Traffic matching a permit action in the ACL will be protected and sent through the VPN. Traffic matching a deny action in the ACL will be sent outside the VPN in cleartext.

These recommendations apply when defining interesting traffic:

• Try to be as restrictive as possible when defining which packets to protect in a crypto ACL. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within thatpermit statement) that you do not want to be protected.

• Because crypto ACLs are processed for both outbound and inbound traffic, it is important to create mirrored crypto ACLs in each VPN endpoint.

Mirrored Crypto ACLs

When crypto ACLs are incorrectly configured or missing, traffic might only flow in one direction across the VPN tunnel, or it might not be sent across the tunnel at all. When a router receives encrypted packets from an IPsec peer, it uses the same ACL to determine which inbound packets to decrypt by viewing the source and destination addresses in the ACL in reverse order. Any unprotected inbound traffic that matches a permit entry in the crypto ACL for a crypto map entry that is highlighted as IPsec is dropped. This drop occurs because this traffic was expected to be protected by IPsec.

In Figure 14-3, the VPN protects traffic from both LANs behind each router acting as VPN peer. The crypto ACL created on router Site-1 is the exact mirror of the crypto ACL created on router IOS-FW. The definition of source traffic on router IOS-FW becomes the definition of destination traffic on router Site-1. Similarly, the definition of destination traffic on router IOS-FW becomes the definition of source traffic on router Site-1.

Figure 14-3. Mirrored Crypto ACLs

You will notice in Figure 14-3 that we have included all the HQ subnets in our crypto ACLs, thus the wildcard mask of 16 bits for 10.10.0.0. The branch office has only one subnet, 10.20.10.0, thus the wildcard mask of 24 bits.

Cipher Suite

The cipher suite selection should follow guidelines in terms of encryption algorithms, key sizes, and key lifetimes. Table 14-1 illustrates an example. Advanced Encryption Standard (AES), for instance, is considered a stronger encryption algorithm than Triple Data Encryption Standard (3DES). Similarly, Secure Hash Algorithm 2 (SHA-2) is considered a stronger hashing function than SHA-1 and Message Digest 5 (MD5). In fact, some of these algorithms might have been broken already, in real networks or in a lab.

Table 14-1. Example of Cipher Suite Selection Decision

Similar considerations apply to authentication methods, where digital certificates are considered a stronger method to uniquely identify VPN peers, and they are a more scalable solution in the presence of a high volume of peers. Diffie-Hellman (DH) groups define the size of encryption keys, and will have an effect on device performance.

Key lifetimes also define the level of risk and the strength of the cryptography solution. The shorter the lifetimes, the more frequently peers will perform rekeying and refresh the cryptography materials, mitigating the effect of man-in-the-middle attacks and other exploits that expose keys and other components.

Crypto Map

Crypto map entries that you create for IPsec combine the needed configuration parameters of IPsec SAs, including the following parameters:

• Which traffic should be protected by IPsec using a crypto ACL

• The granularity of the flow to be protected by a set of SAs

• Who the remote IPsec peer is, which determines where the IPsec-protected traffic is sent

• The local address that is to be used for the IPsec traffic (optional)

• Which IPsec security should be applied to this traffic, choosing from a list of one or more transform sets

Crypto maps, illustrated in Figure 14-4, are applied to router interfaces in order for the IPsec VPN to start working. You can apply only one crypto map set to a single interface. Crypto maps can negotiate different policies for different peers on the same interface. In that case, the same crypto map will have multiple entries. These multiple entries are known as a crypto map set.

Figure 14-4. Crypto Map and Its Role

You must create multiple crypto map entries for a given interface if any of these conditions exist:

• Different data flows are to be managed by separate IPsec peers.

• You want to apply different IPsec security to different types of traffic (to the same or separate IPsec peers). An example would be if you want traffic between one set of subnets to be authenticated and traffic between another set of subnets to be both authenticated and encrypted. In this case, you should define the different types of traffic in two separate ACLs, and you must create a separate crypto map entry for each crypto ACL.

• If you are not using IKE to establish a particular set of SAs, and you want to specify multiple ACL entries, you must create separate ACLs (one per permit entry) and specify a separate crypto map entry for each ACL.

Configuring a Site-to-Site IPsec VPN Using CCP

The following pages show you how to configure a site-to-site IPsec VPN with preshared keys by using Cisco Configuration Professional wizards. All screen shots and configuration examples that follow use the same scenario that is depicted in Figure 14-5. The goal is to establish a site-to-site VPN between router IOS-FW and router Site-1, protecting traffic that travels between the two LAN segments behind each router.

Figure 14-5. Scenario for Configuring a Site-to-Site IPsec VPN with Preshared Keys Using CCP VPN Wizard

To ensure secure communications, a strong cipher suite is required, which involves using preshared keys, AES, SHA-1, and DH5, as an example.

Initiating the VPN Wizard

The Cisco Configuration Professional VPN wizard can be used to simplify the process of configuring the site-to-site VPN. The wizard is located by following this option path: Configure > Security > VPN > Site-to-Site VPN.

The Create Site to Site VPN tab includes two types of wizard:

Create a Site to Site VPN: This option allows you to create a VPN network connecting two routers.

Create a Secure GRE Tunnel (GRE over IPsec): This option allows you to configure a Generic Routing Encapsulation (GRE) protocol tunnel between your router and a peer system.

As shown in Figure 14-6, click Create a Site-to-Site VPN and click Launch the Selected Task.

Figure 14-6. Launching CCP Site-to-Site VPN Wizard

As shown in Figure 14-7, the Site-to-Site VPN Wizard starts with a choice of quick setup or a step-by-step wizard:

• Using quick setup, CCP will automatically provide a default IKE policy to govern authentication, a default transform set to control the encryption of data, and a default IPsec rule that will encrypt all traffic between the router and the remote device. Quick setup is best used when both the local router and the remote system are Cisco routers using CCP. Quick setup will configure 3DES encryption if it is supported by the Cisco IOS image. Otherwise, it will configure DES encryption. If you need AES or Software-Optimized Encryption Algorithm (SEAL) encryption, you must use the step-by-step wizard. Using quick setup, you can view the default IKE policy, transform set, and IPsec rule that will be used to configure the one-step VPN.

Figure 14-7. Wizard Gives a Choice Between Quick Setup or Step-by-Step Approach

• Using the step-by-step wizard, you can configure a site-to-site VPN using parameters that you specify. The result is a custom configuration for the VPN, allowing the use of any of the CCP defaults that you need. The step-by-step wizard, selected in Figure 14-7, allows you to specify stronger encryption than the quick setup wizard allows.

VPN Connection Information

You can use the VPN Connection Information page of the Site-to-Site VPN Wizard, shown in Figure 14-8, to identify the IP address or hostname of the remote site that will terminate the VPN tunnel that you are configuring, to specify the router interface to use, and to enter the preshared key that both routers will use to authenticate each other.

Figure 14-8. VPN Connection Information Page

The VPN Connection Information page of the wizard has three distinct sections, as shown in Figure 14-8.

The first component of the VPN Connection Information page is the local router interface that will initiate and terminate the tunnel, shown in Figure 14-9. From the interface drop-down menu, select the interface on this router that connects to the remote site. The router presented in Figure 14-9 is the HQ IOS-FW. As also shown in Figure 14-9, you can click Details to view the details of the interface, in terms of other configured features, such as Network Address Translation (NAT), existing ACLs, quality of service (QoS) rules, or Cisco IOS Intrusion Prevention System (IPS) rules. This is important to determine the compatibility of those features with IPsec configurations on the same interface.

Figure 14-9. First Component of VPN Connection Information Page: Interface Selection

The second component of the VPN Connection Information page is the Peer Identity section, shown in Figure 14-10. Enter the IP address of the remote IPsec peer that will terminate the VPN tunnel that you are configuring. The remote IPsec peer might be another router, a VPN concentrator, or any other gateway device that supports IPsec. Three options are available in the Peer Identity section, the first two of which are located in the drop-down menu:

Peer(s) with dynamic IP addresses: Choose this option if the peers that the router connects to use a dynamically assigned IP address.

Peer with static IP address: Choose this option if the peer that the router connects to uses a fixed IP address.

Enter the IP address of the remote peer: This is enabled when Peer With Static IP Address is chosen. Enter the IP address of the remote peer.

Figure 14-10. Second Component of VPN Connection Information Page: Peer Identity

The third component of the VPN Connection Information page, the Authentication section, is where you specify the preshared key used for IPsec authentication, as shown in Figure 14-11.

Figure 14-11. Third Component of VPN Connection Information Page: Authentication

In the Authentication section of this page, you can click the Pre-shared Keys button if the VPN peers use a preshared key to authenticate connections from each other. This key must be the same on each side of the VPN. Question marks (?) and spaces must not be used in the preshared key. The preshared key can contain a maximum of 128 characters. Optionally, you can configure digital certificates as the authentication option. Click Next to move to the next page.

IKE Proposals

The next wizard page, IKE Proposals, shown in Figure 14-12, lists all of the IKE policies that have been configured on the router. If no user-defined policies have been configured, the page lists the Cisco Configuration Professional default IKE policy. IKE policies govern the way in which devices in a VPN authenticate themselves during Phase 1. The local router uses the IKE policies listed on this page to negotiate authentication with the remote router.

Figure 14-12. IKE Proposals Configured Through the VPN Wizard

The local router and the peer device must both use the same policy. The router that initiates the VPN connection offers all its policies to the receiver, which analyzes them starting with the lowest priority number first. If the remote system rejects that policy, it considers the policy with the next lowest number, and continues in this fashion until it finds a match, as shown previously in Figure 13-8. You must coordinate closely with the administrator of the peer system so that you can configure identical policies on both routers.

If you want to add an IKE policy that is not included in this list, you can click Add and create the policy in the Add IKE Policy dialog box that is displayed. You can edit an existing policy by selecting it and clicking Edit. CCP default policies are read-only and cannot be edited. In Figure 14-12, the Add IKE Policy dialog box displays the desired policy for the requirements, which are encryption using AES, authentication using preshared keys, hashing using SHA-1, and key exchange using DH 5.


Note

Adding a new policy creates a new line with a higher priority in the IKE policy list. In the Add IKE Policy dialog box, you can control the priority number and define the cipher suite of your choice. Be sure to select the new policy from the list of IKE policies before you click Nextto continue.


Transform Set

The next step of the VPN Wizard is to define the transform sets, which define the cipher suite for IPsec Phase 2. The Transform Set page, shown in Figure 14-13, lists the CCP default transform sets and the additional transform sets that have been configured on this router. These transform sets will be available for use by the VPN. A transform set represents a certain combination of security protocols and algorithms. During the IPsec security association negotiation, the peers agree to use a particular transform set for protecting a particular data flow. A transform describes a particular security protocol with its corresponding algorithms.

Figure 14-13. Transform Set Configured Through the VPN Wizard

A list of all configured transform sets is available in the Select Transform Set drop-down menu. Selecting one allows you to view the settings and add entries to the transform set.

Click Add to create the transform set in the Add Transform Set dialog box. You may choose to perform this action if the router is to negotiate different Phase 2 policies for different peers. This is common in hub-and-spoke VPN topologies. For nondefault transform sets, you can also click Edit to modify the settings.

In Figure 14-13, the Add Transform Set dialog box is configured with the desired policy. ESP is the IPsec protocol that will define authentication, integrity, and payload encryption to create Phase 2 tunnels, using SHA-1 as the integrity algorithm, and AES as the encryption algorithm. The default is tunnel mode.

Click Next to continue the wizard and the VPN configuration.


Note

Adding a new policy will add options to the Select Transform Set drop-down menu. Be sure to select the newly created policy from this drop-down menu before you click Next to continue with the wizard.


Traffic to Protect

The next step of the wizard is to define interesting traffic. The Traffic to Protect page, shown in Figure 14-14, lets you define the traffic that this VPN protects. The VPN can protect traffic between specified subnets, or protect the traffic that is specified in an IPsec rule that you select. There are two options available:

Protect all traffic between the following subnets: Use this option to specify a single source subnet (a subnet on the LAN) whose outgoing traffic you want to encrypt, and one destination subnet that is supported by the peer that you specified on the VPN Connection Information page. All traffic flowing between other source and destination pairs will be sent unencrypted.

Create/Select an access-list for IPSec traffic: Use this option if you need to specify multiple sources and destinations, or if you need to encrypt specific types of traffic. An IPsec rule can consist of multiple entries, each specifying different traffic types and different sources and destinations. Click the ... button next to the field and specify an existing IPsec rule that defines the traffic you want to encrypt, or create an IPsec rule to use for this VPN.

Figure 14-14. Protecting Traffic Through the VPN Wizard

In Figure 14-14, the protected networks from the perspective of router IOS-FW are 10.10.0.0/16 as the source (the LAN behind IOS-FW) and 10.20.10.0/24 as the destination (the LAN behind router Site-1).

Click Next to continue the wizard and the VPN configuration.

Configuration Summary

The last step of the wizard is to review and accept the configuration, as shown in Figure 14-15. This page shows you the VPN configuration that you created. After you review the configuration on this page, you can either click the Back button to make changes if you want, or click Finish to complete the wizard. Note that a testing option is available. You can check the Test VPN Connectivity After Configuring check box to test the VPN connection you have just configured. The results of the test will be shown in another window. This option is demonstrated later in this chapter.

Figure 14-15. Summary of the Site-to-Site VPN Wizard Configuration


Note

If NAT is configured on this router, a CCP warning box, shown in Figure 14-16, will appear after you click Finish; this warning will offer to convert your NAT rules with route maps in order for the VPN to work properly. CCP assumes, rightly so, that you would like to skip the NAT process for traffic going through the IPsec tunnel. Therefore, traffic from 10.10.0.0/16 will appear with its original (real) IP address when transiting on the 10.20.10.0/24 network and vice versa. In other words, sessions between 10.10.0.0/16 and 10.20.10.0/24 will not have their source address translated.

Figure 14-16. VPN Wizard Warning About NAT Rules


Creating a Mirror Configuration for the Peer Site

Site-to-site VPNs require both sides to be configured with matching policies. You also need to create mirrored crypto ACLs in each VPN endpoint and ensure that the peers know each other’s IP addresses. Typically, the same process that is configured by the wizard has to be replicated on the other peer. In Cisco Configuration Professional, you can navigate to Configure > Security > VPN > Site-to-Site VPN, click the Edit Site-to-Site VPN tab, and then click Generate Mirror to automatically create a mirror configuration for the peer.

Clicking this button, as shown in Figure 14-17, creates a text file that captures the VPN configuration of the local router so that a remote router can be given a VPN configuration that enables it to establish a VPN connection to the local router. This button is disabled if you have selected a dynamic site-to-site VPN tunnel.

Figure 14-17. Creating a Mirror Configuration for the Peer Router


Note

The text file that you generate must not be copied into the configuration file of the remote system, but it must be edited and used only to show what has been configured on the local router so that the remote device can be configured in a way that is compatible. Identical names for IPsec policies, IKE policies, and transform sets may be used on the remote router, but the policies and transform sets may be different. If the text file is simply copied into the remote configuration file, configuration errors are likely to result.



Note

Any previously configured VPN connections that are detected by Cisco Configuration Professional that do not use ISAKMP crypto maps will appear as read-only entries in the VPN connection table and cannot be edited.


Verifying the IPsec Configuration Using CCP and CLI

You can verify the VPN configuration on the Edit Site to Site VPN tab, as shown in Figure 14-18. Use this tab to manage the VPN connections to remote systems.

Figure 14-18. Editing VPN Configuration Using CCP

The Status column shows the status of the connection, which is indicated by the intuitive icons. You can also create, edit, and delete VPN connections, and reset existing connections.

The Clear Connection, Generate Mirror, and Test Tunnel buttons are also available from this tab.

Verifying IPsec Configuration Using CLI

The Cisco IOS CLI can also be used to verify the site-to-site VPN configuration. Table 14-2 shows some of the available commands.

Table 14-2. Commands to Verify IPsec Configuration

Verifying IKE Policy Using the CLI

Use the show crypto isakmp policy command to display configured IKE policies and the default IKE policy settings. This command is useful because it reveals your ISAKMP (IKE) configuration with one command.

The command output, shown in Example 14-1, displays all sections of the IKE policy for router Site-1 according to the topology originally presented in Figure 14-5. The numbers that identify each section (in this example, section numbers 1 and 2) are used to process different sections for peers with different IKE policies. Sections are processed in order, from lower to higher numbers.

If you do not configure IKE policies, or if traffic does not match any configured policy, a default policy is processed. The default policy includes several sections that start with high section numbers (65507) in order to guarantee their processing as an option of last resort. This default policy can be displayed with the show crypto isakmp default policy command.

Example 14-1. Output of show crypto isakmp policy Command


IOS-FW# show crypto isakmp policy
Global IKE policy
Protection suite of priority 1
encryption algorithm: Three key triple DES
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #2 (1024 bit)
lifetime: 86400 seconds, no volume limit


Verifying IKE Phase 2 Policy Using the CLI

You can use the show crypto ipsec transform-set command to show all of the configured transform sets. Because transform sets determine the level of protection that your data will have as it is tunneled, it is important to verify the strength of your IPsec protection policy.

In Example 14-2, the first transform set was created by Cisco Configuration Professional for our example. The remaining transform sets are preconfigured as part of the default policy.

Example 14-2. Output of show crypto ipsec transform-set Command


IOS-FW# show crypto ipsec transform-set
Transform set ESP-3DES-SHA: { esp-3des esp-sha-hmac }
will negotiate = { Tunnel, },
Transform set #$!default_transform_set_1: { esp-aes esp-sha-hmac }
will negotiate = { Transport, },
Transform set #$!default_transform_set_0: { esp-3des esp-sha-hmac }
will negotiate = { Transport, },


Verifying Crypto Maps Using the CLI

To see all of the configured crypto maps, use the show crypto map command, as shown in Example 14-3. This command verifies configurations and shows the configured and current peers, as well as the crypto ACL that defines traffic flows to be protected. The output also shows the interface where the crypto map is assigned.

The information provided by the crypto ACL is most important, as it allows you to monitor and troubleshoot the accuracy and validity of interesting traffic.

The show running-config command also reveals many of these same settings.


Note

In production, you could reduce the length of the show run command by using the show run brief command or the show run | section crypto command. The equivalent command on a Cisco ASA firewall would be show run crypto.


Example 14-3. Output of show crypto map Command


IOS-FW# show crypto map
Crypto Map "SDM_CMAP_1" 1 ipsec-isakmp
Description: Tunnel to200.200.20.2
Peer = 200.200.20.2
Extended IP access list 101
access-list 101 permit ip 10.10.0.0 0.0.255.255 10.20.10.0 0.0.0.255
Current peer: 200.200.20.2
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Transform sets={
ESP-3DES-SHA: { esp-3des esp-sha-hmac },
}
Interfaces using crypto map SDM_CMAP_1:
FastEthernet0/0


Monitoring Established IPsec VPN Connections

Cisco Configuration Professional monitoring is streamlined by using the VPN Status window, which displays a tree of VPN connections that are possible on the router, including all types of VPNs (remote access, site-to-site, and others).

Site-to-site tunnels are displayed as IPsec tunnels. This group displays statistics about each IPsec VPN that is configured on the router. Each row in the table represents one IPsec VPN. You will need to click Update to refresh the IPsec tunnel table and display the most current data from the router.

Figure 14-19 showcases the Monitor Tunnel and Test Tunnel options, which are essential to the troubleshooting process.

Figure 14-19. Monitoring VPN Status with CCP

IKE Policy Negotiation

The Test Tunnel option allows you to send simulated data through the VPN tunnel. You can click the Start button to start the test. The results are shown on the left side of Figure 14-20.

Figure 14-20. Testing Site-to-Site IPsec Tunnel

If the test fails, a popup window prompts you to confirm the initiation of a troubleshooting phase, used by CCP to generate simulated traffic and enable IPsec debugging, in order to automate the troubleshooting process. Clicking Yes to accept this debugging phase presents additional options to either allow CCP to simulate VPN traffic or let you define the profile of the simulated traffic by specifying a destination IP address.

VPN Troubleshooting

Figure 14-21 illustrates the report window of a failed VPN test. The icons shown in Figure 14-20 provide visual cues to determine the severity of the test and to define which of the multiple tests performed by CCP passed or failed. The panel at the bottom suggests the failure reason and spells out recommended actions to resolve the problem.

Figure 14-21. VPN Troubleshooting Status Window

Monitoring IKE Security Association

Monitoring and troubleshooting can also be accomplished by using the Cisco IOS CLI. The show crypto isakmp sa command shows the status and settings of IKE Phase 1 SAs.

Notice the status of the tunnel under the Status column. Also notice the difference between the Status column and the State column. State refers to the progress of the negotiation within Phase 1, while status refers to VPN high availability (HA), showing a state of ACTIVE for SAs on the HA active router, and STANDBY for the SAs on the standby router. This means that a status of ACTIVE is not related to active tunnels; in fact, the Status column is not an indication of health of each Phase 1 SA. A state of QM_IDLE is considered normal for an established Phase 1 tunnel.

Table 14-3 and 14-4 list and describe the possible values for state and status.

Table 14-3. Values for IKE Security Association State

Table 14-4. Values for IKE Security Association Status

Monitoring IPsec Security Association

IPsec Phase 2 can also be monitored by using the show crypto ipsec sa command, as shown in Example 14-4. Increasing encrypt and decrypt counters are a general indication of an operational IPsec Phase 2 tunnel.

Example 14-4. Output of the show crypto ipsec sa Command


RouterA# show crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: SDM_CMAP_1, local addr 200.200.1.2

protected vrf: (none)
local ident (addr/mask/prot/port): (10.10.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.20.10.0/255.255.255.0/0/0)
current_peer 200.200.20.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4030, #pkts encrypt: 4030, #pkts digest: 4030
#pkts decaps: 4033, #pkts decrypt: 4033, #pkts verify: 4033
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0



Note

The show crypto ipsec sa command shows different information depending on whether it is issued from a Cisco IOS router or an ASA firewall:

Cisco IOS router: IPsec SAs show the local and remote identities even if the tunnel is not up. The key item to look for is the presence of inbound and outbound Security Profile Indexes (SPI). Increasing encapsulation/decapsulation counters are also a way to confirm that actual traffic is going through the tunnel.

ASA devices: IPsec SAs do not show identities unless the tunnel is up. Also, the presence of encapsulated packets but no decapsulated packets (or vice versa) is usually a sign of bad routes on one end of the tunnel and/or an ACL in the middle of the flow that is blocking ESP or UDP 4500 (NAT-T) traffic.


Summary

The key points covered in this chapter are as follows:

• Planning an IPsec site-to-site VPN includes selecting the cipher suite and building monitoring and contingency planning into the IPsec site-to site VPN configuration checklist.

• Cisco Configuration Professional provides a step-by-step wizard to guide configuration.

• Use the Monitor Tunnel options to verify configuration.

• Use the Test VPN option and CLI commands to test and troubleshoot.

References

For additional information, refer to these resources:

Carmouche, J. H. IPsec Virtual Private Network Fundamentals (Cisco Press, 2007).

Cisco Systems, Inc. “Cisco IOS IPsec,” http://www.cisco.com/en/US/products/ps6635/products_ios_protocol_group_home.html.

Deal, R. The Complete Cisco VPN Configuration Guide (Cisco Press, 2005).

Review Questions

Use the questions here to review what you learned in this chapter. The correct answers are found in the Appendix, “Answers to Chapter Review Questions.”

1. Which command is best suited to show that traffic is flowing through the VPN tunnel?

a. show crypto map

b. show crypto ipsec transform-set

c. show crypto isakmp policy

d. show crypto ipsec sa

2. Which command would help troubleshoot a Phase I issue?

a. debug crypto sa

b. debug crypto phase 1

c. debug crypto isakmp

d. show crypto sa

3. Which command would be the most helpful to compare the configuration of peer, ACL, SA lifetime, and transform sets?

a. debug crypto sa

b. show crypto isakmp sa

c. show crypto map sa

d. show crypto map

4. You are deploying IPsec VPNs with the Cisco Configuration Professional wizard. Which of the following is true about traffic that is denied by the crypto ACL?

a. The traffic will be denied access to the VPN.

b. The traffic will be dropped if it does not match the crypto policy.

c. The traffic is permitted if it matches the crypto policy.

d. The traffic is permitted in cleartext.

5. Which of the following options is available in the VPN Status window of Cisco Configuration Professional?

a. Create Mirror

b. Monitor Tunnel

c. Clear Connection

d. Add Policy

6. Which of the following is considered a stable state for a Phase 1 security association in IPsec VPNs, using the show crypto isakmp sa command?

a. QM_IDLE

b. QM_NO_STATE

c. QM_ACTIVE

d. QM_ESTABLISHED

7. You issue the command show crypto isakmp sa. You discover that the IKE tunnel is down. Issuing the show crypto ipsec sa command will be helpful at troubleshooting the connectivity problem. True or false?

a. True

b. False

8. You use the Test Tunnel option of CCP. The test fails. What, if any, happens next?

a. CCP returns a fail message and the Test Tunnel option closes.

b. CCP pings automatically the IP address of the peer to ensure that it is live.

c. CCP presents a popup window prompting you to confirm the initiation of a troubleshooting phase.

d. CCP opens a CLI window and issues show crypto commands to the router.