Building a Site-to-Site IPsec VPN Solution

Building a Site-to-Site IPsec VPN Solution

Exploring the Basics of IPsec

This section begins by identifying the characteristics of an IPsec VPN. You will learn about various protocols that make IPsec VPNs possible, including IKE protocols and the ESP and AH protocols. Although you can have a Cisco IOS router act as a VPN termination device, Cisco has other network devices that can serve in this capacity, and you will be introduced to the Cisco VPN product family. Finally, you are presented with a collection of Cisco best practices for configuring an IPsec VPN.

Introducing Site-to-Site VPNs

Much of today’s workforce (approximately 40 percent according to Cisco) is located outside of a corporate headquarters location. Some employees work in remote offices, and others telecommute. These remote employees could connect to the main corporate network using a variety of WAN technologies (for example, leased lines and PVCs, found in Frame
Relay and/or ATM networks). However, these WAN technologies typically cost more than widely available broadband technologies, such as DSL and cable, which might also offer faster speeds.

As illustrated in Figure 15-1, these broadband technologies can be used to support virtual private network (VPN) connections between these geographically dispersed offices. These VPN connections are often called VPN tunnels. Even though a VPN tunnel might physically pass through multiple service provider routers, it appears to be a single router hop from the perspective of the routers at each end of the tunnel.

A remote-access VPN allows a user, with software on her client computer, to connect to a centralized VPN termination device. A site-to-site VPN interconnects two sites without requiring the computers at those sites to have any specialized VPN software installed. Table 15-2 defines the elements of a site-to-site VPN, which is the focus of this chapter.

Overview of IPsec

Broadband technologies such as cable and DSL, in addition to other VPN transport mechanisms, often traverse an untrusted network, such as the Internet. Therefore, a primary concern with using a broadband technology as a VPN transport is security.

Different VPN technologies (for example, IPsec, GRE, L2TP, and L2F) offer different features. IPsec VPNs offer security features. Specifically, IPsec offers the following protections for VPN traffic:

• Confidentiality: Data confidentiality is provided by encrypting data. If a third party intercepts the encrypted data, he could not interpret it.
• Integrity: Data integrity ensures that data is not modified in transit. For example, routers at each end of a tunnel could calculate a checksum value or a hash value for the data. If both routers calculate the same value, the data most likely has not been modified in transit.
• Authentication: Data authentication allows parties involved in a conversation to verify that the other party is who he claims to be. Various authentication methods exist:
  • Usernames and passwords
  • One-time passwords (OTP)
  • Biometric technologies (such as fingerprint analysis or retina scan)
  • Preshared keys
  • Signed digital certificates

IPsec not only becomes an attractive VPN technology because of its security enhancements. IPsec also scales to a wide range of networks. It operates at Layer 3 of the OSI model (the Network layer). As a result, IPsec is transparent to applications. That is, applications do not require any sort of integrated IPsec support.

IKE Modes and Phases

IPsec uses a collection of protocols to provide its features. One of the primary protocols it uses is Internet Key Exchange (IKE). Specifically, IPsec can provide encryption between authenticated peers using encryption keys, which are periodically changed. IKE does, however, allow an administrator to manually configure keys.

IKE can use three modes of operation to set up a secure communication path between IPsec peers. These modes are explained in Table 15-3.

The IKE modes reflect the two primary phases of establishing an IPsec tunnel. For example, during IKE Phase 1, a secure ISAKMP session is established, using either main mode or aggressive mode. During IKE Phase 1, the IPsec endpoints establish transform sets (that is, a collection of encryption and authentication protocols), hash methods, and other parameters needed to establish a secure ISAKMP session (sometimes called an ISAKMP tunnel or an IKE Phase 1 tunnel). As a reminder, this collection of parameters is called a security association (SA). With IKE Phase 1, the SA is bidirectional, meaning that the same key exchange is used for data flowing across the tunnel in either direction.

IKE Phase 2 occurs within the protection of an IKE Phase 1 tunnel, using the previously described quick mode of parameter negotiation. A session formed during IKE Phase 2 is sometimes called an IKE Phase 2 tunnel, or simply an IPsec tunnel. However, unlike IKE Phase 1, IKE Phase 2 performs unidirectional SA negotiations, meaning that each data flow uses a separate key exchange.

Although an IPsec tunnel can be established using just IKE Phase 1 and IKE Phase 2, an optional IKE Phase 1.5 can be used. IKE Phase 1.5 uses the Extended Authentication (XAUTH) protocol to perform user authentication of IPsec tunnels. Like IKE Phase 2, IKE Phase 1.5 is performed within the protection of an IKE Phase 1 tunnel. The user authentication provided by this phase adds a layer of authentication for VPN clients. Also, parameters such as IP, WINS, and DNS server information can be provided to a VPN client during this optional phase.

Authentication Header and Encapsulating Security Payload

In addition to IKE, which establishes the IPsec tunnel, IPsec relies on either the Authentication Header (AH) protocol (IP protocol number 51) or the Encapsulating Security Payload (ESP) protocol (IP protocol number 50). Both AH and ESP offer origin authentication and integrity services, which ensure that IPsec peers are who they claim to be and that the data was not modified in transit.

However, the main distinction between AH and ESP is encryption support. ESP encrypts the original packet, whereas AH does not offer any encryption. As a result, ESP is far more popular on today’s networks. In fact, AH is no longer supported in some Cisco implementations.

Both AH and ESP can operate in one of two modes—transport mode or tunnel mode. Figure 15-2 illustrates the structure of an ESP transport mode packet versus an ESP tunnel mode packet.

The following is a detailed description of the two modes:

• Transport mode: Transport mode uses a packet’s original IP header, as opposed to adding a tunnel header. This approach works well in networks where increasing a packet’s size could cause an issue. Also, transport mode is frequently used for remoteaccess VPNs, where a PC running VPN client software connects to a VPN termination device at a headquarters location.

NOTE You might be concerned that transport mode allows the IP address of the IPsec peers to remain visible during transit, because the original packet’s IP header is used to route a packet. However, IPsec is often used in conjunction with the GRE tunneling protocol. In such a scenario, the original IP packet is encapsulated inside a GRE tunnel packet, which adds a new GRE tunnel header. The GRE packet is then sent over an IPsec tunnel. Even if the IPsec tunnel were running in transport mode, the original packet’s IP header would still not be visible. Rather, the GRE packet’s header would be visible.

One reason a GRE tunnel might be used with an IPsec tunnel is a limitation on the part of IPsec. Specifically, an IPsec tunnel can transmit only unicast IP packets. The challenge is, large enterprise networks might have a significant amount of broadcast and/or multicast traffic (for example, routing protocol traffic). GRE can be used to take any traffic type and encapsulate the traffic in a GRE tunnel packet, which is a unicast IP packet that can then be sent over an IPsec tunnel. Consider, for example, a multicast packet used by a routing protocol. Even though IPsec cannot directly transport the multicast packet, if the packet is first encapsulated by GRE, the GRE packet can then be sent over an IPsec tunnel, thereby securing the transmission of the multicast packet.

• Tunnel mode: Tunnel mode, unlike transport mode, encapsulates an entire packet. As a result, the encapsulated packet has a new header (that is, an IPsec header). This new header has source and destination IP address information that reflects the two VPN termination devices at different sites. Therefore, tunnel mode is frequently used in an IPsec site-to-site VPN.

Cisco VPN Product Offerings

Cisco offers a wide array of VPN termination hardware:

• Cisco VPN-enabled routers and switches
• Cisco VPN 3000 series concentrators (which have reached end-of-sale [EOS] status)
• Cisco ASA 5500 series appliances
• Cisco 500 series PIX Security Appliances
• Hardware acceleration modules

Cisco VPN-Enabled Routers and Switches

Many enterprise networks already contain Cisco IOS routers and/or switches that can serve as VPN termination devices. Examples of these Cisco IOS routers include the Cisco Integrated Services Routers (ISR), shown in Figure 15-3.

With an appropriate feature set, a Cisco IOS router could act not only as a VPN termination device, but also as a firewall and intrusion prevention system (IPS) device. However, focusing on IOS-based VPN features, a Cisco router with an appropriate IOS offers the following:

• Voice and video-enabled VPN: A voice and video-enabled VPN, sometimes called a V3PN, applies quality-of-service (QoS) features to traffic traveling over a VPN to treat different types of traffic with different levels of priority. For example, these QoS features could allow voice traffic to be sent over a VPN before sending less latencysensitive traffic.
• IPsec stateful failover: Because IPsec site-to-site VPNs can be mission-critical links, failover and redundancy should be considered in their configuration. Fortunately, Cisco IOS supports stateful failover for IPsec VPN connections, meaning that if one IPsec tunnel fails, and another IPsec tunnel takes over as a backup, the backup IPsec tunnel is aware of the previous session’s parameters. Therefore, those parameters do not need to be renegotiated. Examples of redundancy and resiliency features supported by Cisco IOS include dead peer detection (DPD), Hot Standby Router Protocol (HSRP), Reverse Route Injection (RRI), and Stateful Switchover (SSO).
• Dynamic multipoint VPN: Consider a hub-and-spoke VPN topology in which multiple remote sites have a site-to-site VPN connection to a headquarters location. In such a topology, if one remote site wanted to communicate securely with another remote site, the traffic would travel between the sites via the headquarters location, rather than directly between the sites. One fix for this suboptimal pathing issue would be to create a full mesh of IPsec site-to-site VPN connections, which would provide a direct IPsec VPN connection between any two remote sites. Such a solution, however, could be complex and expensive to configure and maintain.A more economical solution to providing optimal pathing without necessitating a fullmesh topology is the Dynamic Multipoint VPN (DMVPN) feature. DMVPN allows a VPN tunnel to be dynamically created and torn down between two remote sites on an as-needed basis. Consider Figure 15-4, which shows a hub-and-spoke topology, with the headquarters acting as the hub. Branch B and Branch C want to communicate with one another. Therefore, a DMVPN tunnel is created between these two locations. NextHop Resolution Protocol (NHRP), Multipoint GRE (MGRE), and IPsec VPN features are required to support a DMVPN topology.

• Integration of IPsec with MPLS: Many service providers use Multiprotocol Label Switching (MPLS) to intelligently forward traffic through a service provider’s
  network, as opposed to using less efficient routing tables. Cisco IOS supports the mapping of an IPsec session into an MPLS session, which allows a service provider’s VPN service to extend beyond the service provider’s boundary.
• Cisco Easy VPN: The Cisco Easy VPN feature helps facilitate VPN installations for remote-office and teleworker environments. The two components of Cisco Easy VPN are the Easy VPN Remote and the Easy VPN Server. The Easy VPN Remote component allows a variety of devices (including Cisco IOS routers) to receive security policies from a Cisco Easy VPN Server. The Easy VPN Server allows a variety of devices (including Cisco IOS routers) to push security policies from a central site to remote sites.

Cisco VPN 3000 Series Concentrators

Although Cisco 3000 series concentrators have reached EOS status, you still might encounter existing concentrators in some enterprise networks. A Cisco VPN 3000 series concentrator serves as a dedicated VPN appliance, as opposed to sharing VPN duties with other features, as is the case with a Cisco IOS router.

Consider the following features offered by Cisco VPN 3000 series concentrators:

• Users can access a VPN via a web browser, as opposed to first installing VPN client software, using the Cisco WebVPN feature. This clientless access is made possible through the downloading of a small Java applet to the user’s computer.
• Robust endpoint security is provided via the Cisco Secure Desktop feature.
• For terminal service applications, Cisco VPN 3000 series concentrators offer Citrix support. This support does not necessitate the installation of SSL VPN client software on end systems.
• Cisco VPN 3000 series concentrators can be managed and monitored via a web interface.
• Groups of Cisco 3000 series concentrators can be combined into a cluster. This clustering provides scalability and load balancing to VPN designs.
• Cisco VPN 3000 series concentrators allow users to be authenticated using a variety of approaches, including one-time passwords, RADIUS, Microsoft Active Directory (AD), Security Dynamics International (SDI) Secure ID, and digital certificates.

Cisco ASA 5500 Series Appliances

Unlike a dedicated firewall, a dedicated VPN concentrator, or a dedicated IPS sensor, the Cisco Adaptive Security Appliances (ASA) can adapt to a variety of network security needs. For example, a Cisco ASA 5500 series appliance can simultaneously act as a VPN concentrator, a firewall, and an IPS sensor. However, because this chapter focuses on VPNs, consider the following VPN features offered by Cisco ASA 5500 series appliances:

• Support for both IPsec and SSL tunnels
• Scalability through clustering
• Support for Cisco Easy VPN
• Support for updating user computers with new Cisco VPN Client software
• Support for Cisco IOS WebVPN
• QoS support for converged voice, video, and data networks
• Management via the Cisco Adaptive Security Device Manager (ASDM) graphical interface Cisco ASA 5500 series appliances are available in a variety of models to meet the needs of a wide range of networks. As an example, Figure 15-5 shows a Cisco ASA 5540 appliance.

A network designer must choose an appropriate ASA model in addition to appropriate ASA licensing. Cisco ASA 5500 series appliances support the following types of licenses:

• Feature licenses: Feature licenses allow a security appliance to support security contexts (with the Security Context license) and General Packet Radio Service (GPRS) Tunneling Protocol (GTP) (with the GTP Inspection license).
• Encryption licenses: Encryption licenses enhance a security appliance’s ability to perform encryption by adding support for 3DES and AES encryption.
• Platform licenses: Platform licenses dictate the scalability of a security appliance (for example, by limiting the number of concurrent VPN connections). As the name suggests, these licenses are platform-specific.
  Table 15-4 compares various Cisco ASA 5500 series appliance models.

Cisco 500 Series PIX Security Appliances

Traditionally, Cisco PIX appliances performed firewall functions. The current line of Cisco PIX devices is the Cisco 500 series PIX Security Appliances, an example of which is shown in Figure 15-6.

Not only do Cisco 500 series PIX Security Appliances offer traditional firewall features, but they also offer a robust set of VPN features:

• Enhanced support for spoke-to-spoke VPNs, allowing encrypted traffic to enter and exit the same interface
• Support for Cisco TCP and UDP NAT traversal
• The ability to enforce the use of security products on an end system (for example, Cisco Security Agent [CSA]) and to verify end-system VPN properties (for example, VPN client version and security policies)
• The ability to block VPN connections based on the type of Cisco VPN client being used
• Support for OSPF routing over an IPsec VPN
• Integrated hardware acceleration on some Cisco 500 series PIX appliance models

Hardware Acceleration Modules

VPN operations, such as encryption, can become processor-intensive. Fortunately, Cisco offers the following hardware acceleration modules to offload much of a device’s VPN processing:

• Advanced Integration Module (AIM): This is a daughter board that can connect to the motherboard of a Cisco router. The AIM can then be used to offload processorintensive encryption algorithms from a router’s main processor. A variety of AIMs, such as the AIM-VPN 3660, shown in Figure 15-7, are available for several models of Cisco routers.

• Cisco IPsec VPN Shared Port Adapter (SPA): This is a module that can be inserted into either a Cisco Catalyst 6500 series switch or a Cisco 7600 series router, offering a scalable VPN solution to these modular devices.
• Scalable Encryption Processing (SEP): This module can be inserted into a Cisco VPN 3000 series concentrator to offload DES, 3DES, and AES encryption processing.
• Cisco PIX Security Appliance VPN Accelerator Card+ (VAC+): This can be installed into a Cisco 500 series PIX Security Appliance to boost the throughput of encrypted traffic. Specifically, the VAC+ supports a throughput of up to 425 Mbps for traffic traversing an IPsec-protected tunnel using DES, 3DES, or AES encryption.

VPN Design Considerations and Recommendations

When designing VPN connectivity for your network, the VPN components of the design should be as transparent as possible to end users and applications while still providing the security, performance, and reliability features expected from a VPN. Network design decisions vary based on specific network requirements. However, consider the following prioritized list of objectives when creating your VPN design:

• Providing secure connectivity
• Meeting reliability, performance, and scalability requirements
• Offering options for availability
• The ability to authenticate VPN users
• Implementing security features for traffic before and after it passes through the IPsec VPN tunnel

As a reference, consider the following best-practice recommendations for identity and IPsec access control, IPsec, Network Address Translation, and selecting a single-purpose device or multipurpose device.

Best-Practice Recommendations for Identity and IPsec Access Control
A VPN design should provide a mechanism that allows VPN devices to be securely identified. This process of identification is called authentication. IPsec VPNs can use either preshared keys or digital certificates for authentication. Consider the following best practices:

• VPN termination devices at each end of a site-to-site VPN tunnel can be configured with preshared keys (or can securely determine a preshared key using the DiffieHellman algorithm). Group preshared keys (which are associated with a group name identity) can be used only with remote-access VPNs. Also, wildcard preshared keys (in which all network devices use the same key) should be avoided in site-to-site VPNs.
• Because digital certificates scale better than preshared keys, consider using digital certificates for VPN networks consisting of more than 20 devices. Also, because digital certificates have an associated lifetime, ensure time synchronization for devices using the digital certificates.
• Certificate Revocation Lists (CRL) should be checked to make sure that a certificate appearing in a Certificate Trust List (CTL) has not been revoked (that is, it is still valid). Also, consider using an external certificate authority (CA) to vouch for the validity of a signed certificate when your VPN extends beyond corporate boundaries.
• Evaluate the practicality of protecting digital certificates and preshared keys using a hardware-based solution, as opposed to a (typically less secure) software-based solution.
• To filter unwanted traffic, consider applying inbound access control lists (ACL) on VPN devices.

Best-Practice Recommendations for IPsec
IPsec-protected VPNs offer a collection of features and options to select from. To help you make appropriate design decisions for your environment, consider the following Cisco best practices:

• Use IPsec to provide integrity checking in addition to encryption. You can do this by selecting the previously described ESP option, as opposed to the AH option.
• Use strong encryption algorithms, such as 3DES and AES, as opposed to a weaker standard such as DES.
• Use Secure Hash Algorithm (SHA) instead of Message Digest 5 (MD5) as a hashing algorithm because of SHA’s increased security and speed.

NOTE There are legal limitations on exporting strong encryption algorithms outside the U.S. Consult the following URL for more information: http://www.cisco.com/wwl/ export/crypto.

• You can attain an even greater level of security by reducing the lifetime of the Security Association (SA) being used or by enabling Perfect Forward Secrecy (PFS), which helps provide secure key generation. Cisco recommends that you avoid manipulating these parameters unless the data is highly sensitive. The reason for such a counterintuitive recommendation is the increased processor burden placed on the VPN device.

Best-Practice Recommendations for Network Address Translation

Network Address Translation (NAT) can help preserve a network’s limited address space. However, some incompatibilities might arise when you use NAT in conjunction with an IPsec VPN. Therefore, when feasible, Cisco recommends avoiding the use of NAT for VPN traffic.

The only case in which Cisco does recommend the use of NAT for VPN traffic is when the network address spaces at the different ends of the VPN tunnel overlap. In that event, NAT can be used to accommodate the overlapping address spaces.

Best-Practice Recommendations for Selecting a Single-Purpose Versus Multipurpose Device
As previously discussed, VPN termination can be performed by a variety of devices, such as a dedicated VPN concentrator or a Cisco IOS router. A recurring design decision for VPN networks involves selecting a dedicated device to perform VPN functions versus selecting a device that will perform other functions (for example, firewall and/or IPS functions) in addition to its VPN duties.

When deciding between a single-purpose and a multipurpose device, think about the capacity and features offered by each device you are considering. For example, you might determine that a multipurpose device, such as a high-end Cisco IOS router, has more capacity than a single-purpose device, such as a low-end dedicated VPN device. However, the larger the network, the greater the likelihood that a dedicated VPN device will be an appropriate selection.

Constructing an IPsec Site-to-Site VPN

Now that you have a foundational understanding of IPsec site-to-site VPN concepts, this section introduces the configuration of an IPsec site-to-site VPN. Specifically, the next subsection focuses on CLI-based configuration versus the graphical SDM configuration approach, which is covered after the next subsection.

The Five Steps in the Life of an IPsec Site-to-Site VPN

The process of establishing, maintaining, and tearing down an IPsec VPN has five primary steps. These steps are illustrated in Figure 15-8 and described in Table 15-5.

The Five Steps of Configuring an IPsec Site-to-Site VPN

An IPsec site-to-site VPN can be configured by using IOS commands issued from a router’s CLI or by using the graphical SDM interface. The CLI approach to configuring an IPsec site-to-site VPN involves five primary steps, as described in Table 15-6.

Configuring an IKE Phase 1 Tunnel

To illustrate the CLI configuration of an IPsec site-to-site VPN, consider a scenario using the topology shown in Figure 15-9. The goal of this scenario is to allow all IP traffic to securely flow between network 10.1.1.0/24 (connected to Router1) and network 192.168.0.0/24 (connected to Router2).

To begin the configuration, you specify the ISAKMP parameters. Example 15-1 shows this initial configuration for Router1, and Example 15-2 provides the configuration for Router2.

Example 15-1 Router1’s IKE Phase 1 Configuration

Router1# conf term
 Router1(config)# crypto isakmp policy 1
 Router1(config-isakmp)# authentication pre- share
 Router1(config-isakmp)# hash sha
 Router1(config-isakmp)# encryption aes 1 28
 Router1(config-isakmp)# group 2
 Router1(config-isakmp)# lifetime 86400
 Router1(config-isakmp)# exit
 Router1(config)# crypto isakmp key C1 sc0Press address 1 72. 30. 2. 2
 Router1(config)# end
 Router1#

Example 15-2 Router2’s IKE Phase 1 Configuration

Router2# conf term
 Router2(config)# crypto isakmp policy 1
 Router2(config-isakmp)# authentication pre- share
 Router2(config-isakmp)# hash sha
 Router2(config-isakmp)# encryption aes 1 28
 Router2(config-isakmp)# group 2
 Router2(config-isakmp)# lifetime 86400
 Router2(config-isakmp)# exit
 Router2(config)# crypto isakmp key C1 sc0Press address 1 72. 30. 2. 1
 Router2(config)# exit
 Router2#

In the preceding examples, the crypto isakmp policy 1 command is used to enter ISAKMP configuration mode. From within this mode, the authentication pre-share command specifies that preshared keys are to be used for authentication. The hash sha command specifies that Secure Hash Algorithm (SHA) will be used as the hashing algorithm for the ISAKMP Security Association (SA). The encryption aes 128 command causes 128-bit Advanced Encryption Standard (AES) encryption to be used. The group 2 command specifies that Diffie-Hellman Group 2 be used for the secure exchange of shared keys. Finally in this configuration mode, the lifetime of the SA is set to one day (86,400 seconds) with the lifetime 86400 command. Then, in global configuration mode, the crypto isakmp key C1sc0Press address peer-IP-address command sets the shared key to C1sc0Press when communicating with the other router (that is, the peer IP address).

Configuring an IKE Phase 2 Tunnel

Recall that an IKE Phase 2 tunnel (an IPsec tunnel) is negotiated and set up within the protection of an IKE Phase 1 tunnel (an ISAKMP tunnel). Now that you have seen how to configure an IKE Phase 1 tunnel, examine Examples 15-3 and 15-4. They show the syntax to configure an IKE Phase 2 tunnel, building on the topology shown previously in Figure 15-9.

Example 15-3 Router1’s IKE Phase 2 Configuration

Router1# conf term
 Router1(config)# crypto ipsec transform- set MYSET esp- aes esp- sha
 Router1(cfg-crypto-trans)# exit
 Router1(config)# access- list 1 01 permit ip 1 0. 1 . 1 . 0 0. 0. 0. 255 1 92. 1 68. 0. 0 0. 0. 255
 Router1(config)# crypto map ROUTER1 _TO_ROUTER2 1 0 ipsec- isakmp
 Router1(config-crypto-map)# set peer 1 72. 30. 2. 2
 Router1(config-crypto-map)# match address 1 01
 Router1(config-crypto-map)# set transform- set MYSET
 Router1(config-crypto-map)# exit
 Router1(config)# exit
 Router1#

Example 15-4 Router2’s IKE Phase 2 Configuration

Router2# conf term
 Router2(config)# crypto ipsec transform- set MYSET esp- aes esp- sha- hmac
 Router2(cfg-crypto-trans)# exit
 Router2(config)# access- list 1 01 permit ip 1 92. 1 68. 0. 0 0. 0. 0. 255 1 0. 1 . 1 . 0 0. 0. 255
 Router2(config)# crypto map ROUTER2_TO_ROUTER1 1 0 ipsec- isakmp
 Router2(config-crypto-map)# set peer 1 72. 30. 2. 1
 Router2(config-crypto-map)# match address 1 01
 Router2(config-crypto-map)# set transform- set MYSET
 Router2(config-crypto-map)# end
 Router2# exit
 Router2#

In Examples 15-3 and 15-4, a transform set named MYSET is created with the crypto ipsec transform-set MYSET esp-aes esp-sha-hmac command. The esp-aes parameter specifies the encryption algorithm to be used, and the esp-sha-hmac parameter specifies the hashing algorithm (that is, the integrity algorithm) to be used. Each example then contains an ACL numbered 101, which specifies what traffic the IPsec tunnel will protect. By combining these examples, you can see that this scenario configures Router1 and Router2 to protect all IP traffic traveling between the 10.1.1.0/24 network and the 192.168.0.0/24 network. Next, a crypto map is created with the crypto map crypto-map-name 10 ipsec-isakmp command. In crypto map configuration mode, the set peer peer-IP-address command specifies the IP address of the IPsec peer (that is, the IP address of the other router). The

match address 101 address associates the previously created ACL 101 with the crypto map, and the MYSET transform set is linked with the crypto map using the set transformset MYSET command.

Applying Crypto Maps

A crypto map needs to be applied to an interface for an IPsec tunnel to be set up. Continuing with the current scenario, examine Examples 15-5 and 15-6. They illustrate the application of the ROUTER1_TO_ROUTER2 crypto map to Router1 and the application of the ROUTER2_TO_ROUTER1 crypto map to Router 2.

Example 15-5 Applying a Crypto Map to Router1

Router1# conf term
 Router1(config)# interface serial 1 /0
 Router1(config-if)# crypto map ROUTER1 _TO_ROUTER2
 Router1(config-if)# end
 Router1(config)# ip route 1 92. 1 68. 0. 0 255. 255. 255. 0 1 72. 30. 2. 2
 Router1(config)# end
 Router1#

Example 15-6 Applying a Crypto Map to Router2

Router2# conf term
 Router2(config)# interface serial 1 /0
 Router2(config-if)# crypto map ROUTER2_TO_ROUTER1
 Router2(config-if)# exit
 Router2(config)# ip route 1 0. 1 . 1 . 0 255. 255. 255. 0 1 72. 30. 2. 1
 Router2(config)# end
 Router2#

In the preceding examples, notice that you enter interface configuration mode to apply a crypto map. Then you issue the crypto map crypto-map-name command to apply the previously configured crypto map. Also notice that Examples 5-5 and 5-6 each have an ip route command. This command is used to create a static route, pointing to the remote network available off the far-end router.

To test the IPsec configuration, an extended ping can be performed, as shown in Example 15-7. Specifically, Example 15-7 shows an extended ping being initiated from Router1’s LAN interface (IP address 10.1.1.1), destined for Router2’s LAN interface (IP address 192.168.0.95). Notice that the first ping fails, because the IPsec tunnel is being set up during this time. However, the remaining pings succeed.

Example 15-7 Testing the IPsec Tunnel with an Extended Ping

Router1# ping
 Protocol [ip]:
 Target IP address: 1 92. 1 68. 0. 95
 Repeat count [5]:
 Datagram size [100]:
 Timeout in seconds [2]:
 Extended commands [n]: y
 Source address or interface: 1 0. 1 . 1 . 1
 Type of service [0]:
 Set DF bit in IP header? [no]:
 Validate reply data? [no]:
 Data pattern [0xABCD]:
 Loose, Strict, Record, Timestamp, Verbose[none]:
 Sweep range of sizes [n]:
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 192.168.0.95, timeout is 2 seconds:
 Packet sent with a source address of 10.1.1.1
 .!!!!
 Success rate is 80 percent (4/5), round-trip min/avg/max = 164/209/296 ms

After establishing an IPsec tunnel, you can verify and view the tunnel’s parameters by issuing the show crypto engine connections active and show crypto session commands, as shown in Examples 15-8 and 15-9.

Example 15-8 show crypto engine connections active Command

Router1# show crypto engine connections active
 Crypto Engine Connections
 ID Interface Type Algorithm Encrypt Decrypt IP-Address
 1 Se1/0 IPsec AES+SHA 0 4 172.30.2.1
 2 Se1/0 IPsec AES+SHA 4 0 172.30.2.1
 1001 Se1/0 IKE SHA+AES 0 0 172.30.2.1

Example 15-9 show crypto session Command

Router1# show crypto session
 Crypto session current status
 Interface: Serial1/0
 Session status: UP-ACTIVE
 Peer: 172.30.2.2 port 500
 IKE SA: local 172.30.2.1/500 remote 172.30.2.2/500 Active
 IPSEC FLOW: permit ip 10.1.1.0/255.255.255.0 192.168.0.0/255.255.255.0
 Active SAs: 2, origin: crypto map

Using Cisco SDM to Configure IPsec on a Site-to-Site VPN

CLI-based IPsec configuration can become a daunting task for network administrators who aren’t thoroughly familiar with the myriad of IPsec parameters and options. Fortunately, Cisco SDM offers a Site-to-Site VPN configuration wizard that can help you configure an IPsec site-to-site VPN, as shown in this section.

Introduction to the Cisco SDM VPN Wizard

Cisco SDM makes available both a Quick Setup wizard and a Step-by-Step wizard. These wizards combine administrator input with preconfigured VPN elements to produce VPN configurations. However, a successful VPN configuration requires some VPN elements (such as a PKI) to already be in place.
Figure 15-10 shows how to get started with the Cisco SDM Site-to-Site VPN Configuration Wizard using the following steps:
Step 1 Click the Configure button in the Cisco SDM interface.

Step 2 Click the VPN button in the Tasks pane.
Step 3 Click the Site to Site VPN object.
Step 4 Select the Create a Site to Site VPN. radio button.
Step 5 Click the Launch the selected task button.
Next you are prompted to select either Quick setup or Step by step wizard, as shown in Figure 15-11.

Quick Setup

To demonstrate an IPsec site-to-site VPN configuration using the Quick Setup wizard, consider the topology shown in Figure 15-12.

The following steps illustrate how to configure the topology shown in Figure 15-12 to protect traffic traveling between network 192.168.0.0/24 and network 10.1.1.0/24:
Step 1 The Quick Setup wizard offers two default IKE policies and a default IPsec transform set for your use. However, you still need to enter a few parameters into this wizard, as shown in Figure 15-13.

In Figure 15-13, the following parameters are entered:

• Interface for this VPN connection: Serial 1/0
• IP address of the remote peer: 172.16.1.2
• Preshared key: cisco
• Source interface where encrypted traffic originates: FastEthernet0/0
• Destination IP address (or subnet) where encrypted traffic terminates: 10.1.1.0 255.255.255.0

Step 2 After entering these parameters, click the Next button. You see a configuration summary, as shown in Figure 15-14.

Step 3 After reviewing the summary, click the Finish button. The commands are delivered to the router you are configuring. Click the OK button, as shown in Figure 15-15, to enter the Edit Site to Site VPN screen.

Step 4 In the Edit Site to Site VPN screen, shown in Figure 15-16, notice that the VPN is down. This is because the router at the other side of the tunnel has not yet been configured.

Step 5 Cisco SDM helps you configure the router at the far side of the tunnel, even if the other router is not running Cisco SDM. Specifically, if you click the Generate Mirror button, the window shown in Figure 15-17 appears, showing a generic form of the configuration to be applied to the far-end router. The configuration does need some tweaking before being applied, because you need to specify which interface on the remote router the generated crypto map should be applied to.

Step 6 Manually apply the generated configuration to the far-end router, and manually apply the generated crypto map to the appropriate interface on the far-end router using the crypto map crypto-map-name command. Then you can click the Test Tunnel button, which opens the VPN Troubleshooting window, shown in Figure 15-18.

Step 7 In the VPN Troubleshooting window, click the Start button. The first time you test the connection, you are prompted for a destination IP address available off the far-end router to test. If everything is configured correctly, you receive a message that the VPN tunnel is up, as shown in Figure 15-19.

Step 8 After closing the VPN Troubleshooting window, notice that the VPN tunnel status has changed to up, as shown in Figure 15-20.

As a reference, Examples 15-10 and 15-11 provide the IPsec-relevant commands entered on routers R1 and R2, with assistance from the Cisco SDM Quick Setup wizard.
Example 15-10 IPsec-Relevant Configuration Commands on R1

crypto isakmp policy 1
 encr 3des
 authentication pre- share
 group 2
 crypto isakmp key cisco address 1 72. 1 6. 1 . 2
 !c
 rypto ipsec transform- set ESP- 3DES- SHA esp- 3des esp- sha- hmac
 !c
 rypto map SDM_CMAP_1 1 ipsec- isakmp
 description Tunnel to1 72. 1 6. 1 . 2
 set peer 1 72. 1 6. 1 . 2
 set transform- set ESP- 3DES- SHA
 match address 1 00
 !i
 nterface FastEthernet0/0
 ip address 1 92. 1 68. 0. 29 255. 255. 255. 0
 !i
 nterface Serial1 /0
 ip address 1 72. 1 6. 1 . 1 255. 255. 255. 0
 crypto map SDM_CMAP_1
 !i
 p route 1 0. 1 . 1 . 0 255. 255. 255. 0 1 72. 1 6. 1 . 2
 !a
 ccess- list 1 00 remark SDM_ACL Category=4
 access- list 1 00 remark IPSec Rule
 access- list 1 00 permit ip 1 92. 1 68. 0. 0 0. 0. 0. 255 1 0. 1 . 1 . 0 0. 0. 0. 255

Example 15-11 IPsec-Relevant Configuration Commands on R2

crypto isakmp policy 1
 encr 3des
 authentication pre- share
 group 2
 crypto isakmp key cisco address 1 72. 1 6. 1 . 1
 !c
 rypto ipsec transform- set ESP- 3DES- SHA esp- 3des esp- sha- hmac
 !c
 rypto map SDM_CMAP_1 1 ipsec- isakmp
 set peer 1 72. 1 6. 1 . 1
 set transform- set ESP- 3DES- SHA
 match address SDM_1
 !i
 nterface FastEthernet0/0
 ip address 1 0. 1 . 1 . 1 255. 255. 255. 0
 !i
 nterface Serial1 /0
 ip address 1 72. 1 6. 1 . 2 255. 255. 255. 0
 crypto map SDM_CMAP_1
 !i
 p route 1 92. 1 68. 0. 0 255. 255. 255. 0 1 72. 1 6. 1 . 1
 !i
 p access- list extended SDM_1
 remark SDM_ACL Category=4
 remark IPSec Rule
 permit ip 1 0. 1 . 1 . 0 0. 0. 0. 255 1 92. 1 68. 0. 0 0. 0. 0. 255
 remark SDM_ACL Category=4
 remark IPSec Rule

Step-by-Step Setup

Using the Step-by-Step wizard, as opposed to the Quick Setup wizard, requires additional input from the administrator. Table 15-7 describes parameters required by the Step-by-Step wizard.

The following sections cover the details of setting these up.

Configuring Connection Settings
If you select Step by step wizard from the initial Site-to-Site VPN Wizard screen, as shown earlier in Figure 15-11, you see the connection settings screen, as shown in Figure 15-21.

On this initial screen, you are prompted to enter the following information:

• Interface for this VPN connection
• Peer IP address type (dynamic or static)
• IP address of the remote peer (for a peer with a static IP address)
• Authentication type (preshared keys or digital certificates)
• Preshared key (for preshared key authentication)

NOTE When selecting a preshared key, make the key strong, just as you would create a strong password. For example, select a key that is long and that is not an actual word. Doing so makes the key more resistant to a brute-force attack or a dictionary attack.

After setting the parameters in this initial connection settings screen, click the Next button to proceed to the next screen in the wizard. This screen allows you to configure an IKE proposal.

Selecting an IKE Proposal

You can select the default IKE proposal provided by Cisco SDM, as shown in Figure 15-22, or you can click the Add button to configure parameters for your own custom IKE policy.

Specifically, you can set the following parameters for an IKE policy:

• Priority (set to 1 in the default policy)
• Encryption (set to 3DES in the default policy)
• Hash (set to SHA_1 in the default policy)
• Diffie-Hellman group (set to group2 in the default policy)
• Authentication (either PRE_SHARE or RSA_SIG)
• Lifetime (the Security Association [SA] lifetime in seconds)

After identifying the IKE proposal(s) you want to use, click the Next button to proceed to the next screen in the wizard. This screen allows you to configure a transform set.

Selecting a Transform Set

Whereas an IKE proposal specifies security parameters for an ISAKMP tunnel (an IKE Phase 1 tunnel), a transform set specifies security parameters for an IPsec tunnel (an IKE Phase 2 tunnel). The Transform Set configuration screen, shown in Figure 15-23, allows you to either select Cisco SDM’s default transform set or click the Add button to create a custom transform set.

When creating a custom transform set, you can specify the parameters listed in Table 15-8.

After identifying the transform set(s) you want to use, click the Next button to proceed to the next screen in the wizard. This screen allows you to identify traffic to protect in the IPsec tunnel.

Selecting Traffic to Protect in the IPsec Tunnel

From the Traffic to protect screen, you can select either Protect all traffic between the following subnets or Create/Select an access-list for IPsec traffic. Figure 15-24 shows a scenario in which all traffic between two subnets (192.168.0.0/24 and 10.1.1.0/24) is identified.

However, if you prefer to protect specific traffic to protect (as identified by an ACL), you can select the Create/Select an access-list for IPsec traffic radio button and choose Create a new rule(ACL) and select from the adjacent drop-down menu, as shown in Figure 15-25.

After selecting Create a new rule(ACL) and select, you see the Add a Rule window, shown in Figure 15-26.

From the Add a Rule window, you can specify a number or name for the ACL you will use to identify traffic to be protected by the IPsec tunnel. Also, you can optionally give a description. To add a rule to the ACL, click the Add button.
After you click the Add button, the Add an Extended Rule Entry window appears, as shown in Figure 15-27.

In Figure 15-27, the extended rule matches Telnet traffic sourced from network 192.168.0.0/24 and destined for network 10.1.1.0/24. After creating the rule, click the OK button.

Applying the Generated Configuration

After selecting the traffic to protect from the Traffic to protect screen (either all traffic between two subnets or specific traffic identified by an ACL), click the Next button to view a summary of the configuration, as shown in Figure 15-28.

After reviewing the configuration summary, click the Finish button to send the configuration commands to the router. Click the OK button in the Commands Delivery Status window, as shown in Figure 15-29.

After clicking the Finish button, you are sent to the Edit Site to Site VPN screen, as shown in Figure 15-30.

Notice that this screen reports that the tunnel is down. From this screen, as previously described for the Quick Configuration Wizard, you can generate a mirror configuration template to be applied to the router at the other end of the tunnel and then test the VPN tunnel.

Monitoring the Configuration

After the VPN tunnel becomes operational, you can monitor the tunnel status. Click the Monitor button (in the button bar at the top of the Cisco SDM screen). Then click the VPN Status button (in the Tasks pane, on the left of the Cisco SDM screen). Finally, click the IPSec Tunnels option (in the middle pane of the Cisco SDM screen). This monitoring interface, as shown in Figure 15-31, graphically provides traffic statistics for the IPsec VPN tunnel.

Alternatively, you can issue monitoring and troubleshooting commands from the router’s command line. Table 15-9 lists examples of these commands.

• CCNA Security Study Notes