Site-to-Site IPsec Configuration Steps

Now that the components of a site-to-site IPsec VPN are understood, it is time to configure the secure connection using the Cisco IOS. There are five steps in the IPsec lifecycle (interesting traffic, IKE phase 1, IKE phase 2, secure data transfer, tunnel termination). However, not all of those steps require configuration. Thus, there cannot be a direct 1:1 map between IPsec steps and configuration steps. The six steps necessary to configure a site-to-site IPsec VPN are as follows: Step 1 Configure the ISAKMP policy (IKE phase 1). Step 2 Configure the IPsec transform sets (IKE phase 2, tunnel termination). Step 3 Configure the crypto ACL (interesting traffic, secure data transfer). Step 4 Configure the crypto map (IKE phase 2). Step 5 Apply the crypto map to the interface (IKE phase 2). Step 6 Configure the interface ACL. Step 1: Configure the ISAKMP Policy Configuration of the ISAKMP policy basically maps to IKE phase 1, described earlier. Remember that IKE phase 1 establishes a secure bidirectional tunnel that is used to exchange IPsec keys for the SAs. The following list is a reminder of the IKE phase 1 parameters: ■ IKE encryption algorithm (DES, 3DES, or AES) ■ IKE authentication algorithm (MD5 or SHA-1) ■ IKE key (preshared, RSA signatures, nonces) ■ Diffie-Hellman version (1, 2, or 5) ■ IKE tunnel lifetime (time and/or byte count) Figure 13-6 shows the configuration of ISAKMP parameters. NOTE A mapping to the generic IPsec steps is given to further understand the process. Each of these steps is explained with IOS CLI configurations in this chapter. Note that the sequence of the generic IPsec steps does not match the configuration sequence. And some configuration steps cover multiple generic IPsec steps.

As shown earlier, IKE exchanges security parameters using IKE transform sets

The generic IKE parameters that were shown in Figure 13-4 are now configured in Figure 13-6. Each router has two ISAKMP policies configured. Because preshared keys are used, ISAKMP keys must be defined. These policies are exchanged during IKE phase 1. Policy 10 on Router A matches policy 25 on Router B and the appropriate key (TOPsecret) between the two peers also matches. Thus, the secure IKE tunnel is created using those attributes. In reality, stronger IKE policies should be configured first (that is, with lower policy numbers). Remember that the IKE policies are examined top down, from the lowest policy number to the largest. If a weaker policy is matched due to a lower policy number, then stronger policies that appear later in the policy list are never used. This could potentially compromise the secure IPsec tunnel. Remote Office Central Office Router A Internet Router B crypto isakmp policy 10 encryption des hash md5 authentication pre-shared group 1 lifetime 3600 ! crypto isakmp policy 20 encryption d3es hash sha authentication pre-shared group 1 lifetime 3600 ! crypto isakmp key 0 TOPsecret address 10.1.3.2 ! crypto isakmp key 0 Secret address 10.10.4.3 crypto isakmp policy 15 encryption des hash md5 authentication pre-shared group 2 lifetime 1800 ! crypto isakmp policy 25 encryption des hash md5 authentication pre-shared group 1 lifetime 3600 ! crypto isakmp key 0 TOPsecret address 172.16.1.2 ! crypto isakmp key 0 SECret address 10.10.4.3 172.16.1.2 10.1.3.2 150x01x.book Page 294 Monday, June 18, 2007 8:52 AM Site-to-Site IPsec Configuration Steps 295 Step 2: Configure the IPsec Transform Sets The configuration of the IPsec transform sets actually covers three of the IPsec configuration steps mentioned earlier. The IPsec transform set, crypto ACL, and crypto map are tightly woven together. It is difficult to talk about one of them without mentioning the other two. Thus, this section covers all three together. The following list is a reminder of the IPsec security parameters that are negotiated between peers: ■ IPsec protocol (ESP or AH) ■ IPsec encryption type (DES, 3DES, or AES) ■ IPsec authentication (MD5 or SHA-1) ■ IPsec mode (tunnel or transport) ■ IPsec SA lifetime (seconds or kilobytes) Figure 13-7 shows how these IPsec parameters are configured. Figure 13-7 IPsec Transform Set Configuration crypto ipsec transform-set set-55 esp-3des esp-sha-hmac mode tunnel ! crypto ipsec transform-set set-65 esp-3des esp-md5-hmac mode tunnel ! crypto ipsec security-association lifetime seconds 1800 ! access-list 155 permit 192.168.101.0 0.0.0.255 192.168.1.0 0.0.0.255 ! crypto map to-remote 55 ipsec-isakmp set peer 172.16.1.2 match address 155 set transform-set set-55 Remote Office Central Office Internet crypto ipsec transform-set set-60 esp-des esp-sha-hmac mode tunnel ! crypto ipsec transform-set set-70 esp-3des esp-sha-hmac mode tunnel ! crypto ipsec security-association lifetime seconds 1800 ! access-list 170 permit 192.168.1.0 0.0.0.255 192.168.101.0 0.0.0.255 ! crypto map to-central 70 ipsec-isakmp set peer 10.1.3.2 match address 170 set transform-set set-70 S3/2: 10.1.3.2 Bidirectional IKE Tunnel 192.168.102.0/24 192.168.1.0/24 192.168.101.0/24 192.168.2.0/24 Router A Router B S2/1: 172.16.1.2 150x01x.book Page 295 Monday, June 18, 2007 8:52 AM 296 Chapter 13: Site-to-Site VPN Operations Earlier, Figure 13-5 showed the generic IPsec transform set attributes. Figure 13-7 now shows how each of those parameters is configured in Cisco IOS. Each IPsec endpoint defines one or more IPsec transform sets. In this case, set-60, set-70, set-55, and set-65 can be compared to the IPsec transform sets shown earlier in Figure 13-5. These names only have local significance to the IPsec peering process. The IPsec transform set defines all of the IPsec security parameters mentioned above. The terms esp-3des and esp-sha-hmac define ESP as the IPsec protocol, versus AH. Table 13-2 displays the relevant IPsec transform sets for this certification.

Step 3: Configure the Crypto ACL

An extended access list is used to determine interesting traffic. The access lists are shown in the dashed circles. At the remote office, the access list is number 170, while at the central office, the list is number 155. Each list defines the source and destination addresses of traffic that will travel through the IPsec tunnels. Usually, it is very important that the two lists be mirror images of each other. The source address in one list must be the destination address in the other and vice versa. A standard access list cannot be used for identifying interesting traffic because it does not have the ability to specify destination addresses. It is also possible to simply have one site (say a remote site) send everything through an IPsec VPN tunnel to the main site, yet the main site only sends traffic destined for that remote site through the VPN. This makes the configuration at the remote site fairly simple, and isolates the more advanced configuration to the main site. In Figure 13-7, one subnet from each site is considered interesting (due to the ACLs) and will be protected through the IPsec VPN tunnel. The remaining subnets cannot take advantage of the IPsec configuration. Step 4: Configure the Crypto Map The final configuration is the crypto map, which ties the transform set and access list together and points them to a remote peer. The numbers 70 and 55 in each of the crypto maps are line numbers. Each map could have multiple lines, and the lines are referenced numerically from the lowest to the highest number. If a router has only a single interface, yet multiple remote VPN clients, a single crypto map must be used with a unique entry for each peer. At the remote office, the crypto map to-central creates an SA to peer 10.1.3.2 and protects any traffic matching extended access list 170 (interesting traffic) using the IPsec security parameters defined in transform set set-70. The crypto map at the central office can be deciphered in a similar fashion. NOTE Crypto access lists are sometimes called mirrored access lists. Each IPsec peer must have an extended access list that indicates interesting traffic. At a minimum, this interesting traffic must specify both source and destination IP addresses and can add protocols and ports for additional detail. From an IP addressing perspective, what is interesting to one site (source/destination) is exactly opposite to the other site (destination/source). If one side indicates source/destination subnets as interesting, then the other site must reverse the source/destination subnets for its interesting traffic configuration. If one end uses subnets in the crypto ACL for source/destination and the other end uses individual IP addresses for source/destination, the interesting traffic is not mirrored and the IPsec tunnel will not work.