Router Configuration as VPN Peer

We wanted to include one of the ways to configure a router with the capability to be part of a site-to-site VPN. This particular configuration is important because Cisco routers make up 80 percent of the routers in operation today. Therefore, it seemed that many networks could have their security greatly increased by using the router to terminate VPNs.

Configuring ISAKMP

IKE exists only to establish SAs for IPsec, but before it can do this, it must negotiate an SA (an ISAKMP SA) relationship with the peer. Because IKE negotiates its own policy, you can configure multiple policy statements with different configuration statements, and then let the two hosts come to an agreement. ISAKMP negotiates the following:

• Encryption algorithm: Used to protect user data transmitted between two IPsec peers (DES or 3DES).

• Hashing algorithm: MD5 or SHA: This selection specifies the hash algorithm used to ensure data integrity. The default is SHA-1. MD5 has a smaller digest and is considered slightly faster than SHA-1.

• Authentication: RSA signatures, RSA encrypted nonces (random numbers), or preshared keys. This selection specifies the method of authentication that establishes the identity of each IPsec peer. Preshared keys do not scale well with a growing network, but they are easier to set up in a small network.

• Lifetime of the SA (in seconds): The default is 86,400 seconds or 24 hours. As a general rule, a shorter lifetime (up to a point) provides more secure IKE negotiations. However, with longer lifetimes, future IPsec security associations can quickly be set up. However, as with many of the characteristics used in the VPN creation, the VPN tunnel activates and functions if the values do not match.

There is an implicit trade-off between security and performance when you choose a specific value for each parameter. The level of security provided by the default values is adequate for most organizations’ security requirements. If you interoperate with a peer that supports only one of the values for a parameter, your choice is limited to the other peer’s supported value.

When the IKE negotiation begins, the peer that initiates the negotiation sends all its policies to the remote peer, which tries to find a match. The remote peer checks its policies in order of priority (highest priority first) until a match is found.

A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer’s policy specifies a lifetime less than or equal to the lifetime in the policy being compared. If the lifetimes are not identical, the shorter lifetime (from the remote peer’s policy) is used.

If no acceptable match is found, IKE refuses negotiation and IPsec is not established. If a match is found, IKE completes negotiation and IPsec security associations are created. Currently, there are two methods of configuring ISAKMP:

• Use preshared keys, which have the advantage of being simple to configure.

• Use a centralized Certificate Authority (CA), which is a third-party entity responsible for issuing and revoking certificates. Each device that has its own certificate and public key of the CA can authenticate every other device within a given CA’s domain. This solution has the advantage of being scalable throughout a large enterprise network.

The following section discusses the use of preshared keys, which is by far the most common method of configuring ISAKMP.

Preshared Keys

If you use the IKE authentication method of preshared keys, you are setting the keys, or in other words, sharing them with the other peer with whom you plan to create a VPN by manually configuring these keys on the device and its peers. You can specify the same key to share with multiple peers, but it is more secure to specify different keys to share between different pairs of peers. To configure a preshared key on the ASA firewall, perform the following steps. Although configuring IKE is simple and you do not use a CA, it does not scale well. To configure IKE, you must do the following:

Step 1. Configure ISAKMP policy options.

Step 2. Configure ISAKMP key.

Configuring the ISAKMP Protection Suite

The following command creates the ISAKMP policy object. You can have multiple policies, but only one is in this example:

CYBERWRAITH(config)# crypto isakmp policy 1
CYBERWRAITH(config-isakmp)#

With the following group command, you can declare what size modulus to use for Diffie-Hellman calculation:

CYBERWRAITH(config-isakmp)# group 2

Group 1 is 768 bits, and group 2 is 1024 bits. Why would you use one over the other? First, not all vendors support group 2. Second, group 2 is also significantly more CPU-intensive than group 1; therefore, you would not want to use group 2 on low-end routers such as the Cisco 2500 series or less. On the other hand, group 2 is more secure than group 1.

Because security is of primary concern, group 2 is used here. (Make sure the peer is also configured to use group 2.) The default is group 1. If you select the default properties, the group 1 lines do not show up when you show the configuration command.

MD5 is the hashing algorithm as configured in the following command. Although implementing SHA and MD5 are both mandatory, not all peers can be configured to negotiate one or the other:

CYBERWRAITH(config-isakmp)# hash md5

The following command shows the security association’s lifetime—in this case, 500 seconds. If you do not set a lifetime, it defaults to 86,400 seconds or 1 day. When the lifetime timer fires, the SA is renegotiated as a security measure.

CYBERWRAITH(config-isakmp)# lifetime 500

The authentication pre-share command tells IKE what key to use:

CYBERWRAITH(config-isakmp)# authentication pre-share

Two options for the authentication command besides the pre-share are

• rsa-encr: Configures RSA-encrypted nonces

• rsa-sig: Configures RSA signature

The rsa-encr and the rsa-sig options are addressed in the section “Using a CA.” For now, remember that rsa-sig is the default.

Configuring the ISAKMP Key

The following commands tell IKE what key to use. Remember that the peer, 192.168.10.38 in this case, must have the same key Slurpee-Machine in its configuration. I use this particular key because I am configuring a VPN to my good friend Cary’s office and he is addicted to these cold delights.

CYBERWRAITH(config-isakmp)# exit

CYBERWRAITH(config)# crypto isakmp key Slurpee-Machine address 192.168.10.38

At this point, you are finished with IKE configuration. For the record, the following lines are the peer’s IKE configuration:

crypto isakmp policy 1
 hash md5
 group 2
 authentication pre-share
crypto isakmp key Slurpee-Machine address 192.168.10.66

Configuring IPsec

Whether you use preshared keys or configure a CA, you still have to set up IPsec after you set up IKE. Regardless of which IKE method you use, the IPsec configuration steps are the same. To configure IPsec, you need to

Step 1. Create the extended ACL.

Step 2. Create the IPsec transforms.

Step 3. Create the crypto map.

Step 4. Apply the crypto map to an interface.

Step 1: Create the Extended ACL

The following command is a simple ACL that enables the routers to talk to one another (a Telnet from one router to the next, for example):

CYBERWRAITH(config)# access-list 101 permit ip host 192.168.10.38 host
  192.168.10.66

A more realistic ACL looks like the following command:

CYBERWRAITH(config)# access-list 101 permit ip 192.168.3.0 0.0.0.255 10.3.2.0
  0.0.0.255

This command is an ordinary extended ACL, where 192.168.3.0 is a subnet behind the router in question and 10.3.2.0 is a subnet somewhere behind the peer router. Remember that permit means encrypt, and deny means do not encrypt.

Step 2: Create the IPsec Transforms

A transform describes a security protocol (AH or ESP) with its corresponding algorithms; for example, ESP with the DES cipher algorithm and HMAC-SHA for authentication. 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. You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry is used in the IPsec security association negotiation to protect the data flows specified by that crypto map entry’s access list. During IPsec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and applied to the protected traffic as part of both peers’ IPsec security associations. With manually established security associations, there is no negotiation with the peer, so both sides must specify the same transform set.

Create three transform sets, as done in the following command lines:

CYBERWRAITH(config)# crypto ipsec transform-set PapaBear esp-rfc1829
CYBERWRAITH(cfg-crypto-trans)# exit
CYBERWRAITH(config)# crypto ipsec transform-set MamaBear ah-md5-hmac esp-des
CYBERWRAITH(cfg-crypto-trans)# exit
NRGI(config)# crypto ipsec transform-set BabyBear ah-rfc1828
CYBERWRAITH(cfg-crypto-trans)# exit
CYBERWRAITH(config)#

The first set uses only ESP; the second set uses AH combined with ESP; and the last set uses only AH. During IPsec SA negotiation, all three are offered to the peer, which chooses one. Also, use the default tunnel mode for all three transform sets. Transport mode can be used only when the crypto endpoints are also the communication’s endpoints. The mode transport command under the transform-set configuration can specify the transport mode. Tunnel mode is used primarily for the VPN scenario.

Also note that esp-rfc1829 and ah-rfc1828 are based on the original RFCs for this technology and are obsolete transforms included for backward compatibility. Not all vendors support these transforms, but other vendors support only these transforms. Finally, the transform sets in the commands are not necessarily the most practical. For example, both PapaBear and BabyBear have substandard transform-sets. You should use esp-rfc1829 and ah-rfc1828 together in the same transform-set.

Step 3: Create the Crypto Map

Crypto maps specify IPsec policy. Crypto map entries created for IPsec pull together the various security settings that set up IPsec security associations, including the following:

• Which traffic should be protected by IPsec (per a crypto access list)

• Where IPsec-protected traffic should be sent (who the peer is)

• The local address to be used for the IPsec traffic

• What IPsec security should be applied to this traffic (selecting from a list of one or more transform sets)

• Whether security associations are manually established or established via IKE

• Other parameters that might be necessary to define an IPsec SA

For IPsec to succeed between two peers, both peers’ crypto map entries must contain compatible configuration statements. When two peers try to establish a security association, they should each have at least one crypto map entry compatible with one of the other peer’s crypto map entries.

Using the ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Although only one peer is declared in this crypto map, a given crypto map can have multiple peers. The session key lifetime can be expressed in either kilobytes (after x amount of traffic, change the key) or seconds, as shown in the following commands. The goal is to make a potential attacker’s efforts more difficult:

CYBERWRAITH(config)# crypto map armadillo 10 ipsec-isakmp
CYBERWRAITH(config-crypto-map)# set peer 192.168.10.38
CYBERWRAITH(config-crypto-map)# set session-key lifetime seconds 4000
CYBERWRAITH(config-crypto-map)# set transform-set MamaBear PapaBear BabyBear
CYBERWRAITH(config-crypto-map)# match address 101

The set transform-set command is where you associate the transforms with the crypto map. In addition, the order in which you declare the transforms is significant. You most prefer MamaBear in this configuration, and then the rest in descending order of preference to BabyBear.

The crypto map access list bound to the outgoing interface selects the IPsec packets destined to an IPsec tunnel. IPsec packets that arrive from an IPsec tunnel are authenticated or deciphered by IPsec and are subject to the proxy identity match of the tunnel.

The match address 101 command simply means to use access list 101 to determine what traffic is interesting so that it will be placed into the VPN tunnel. You can have multiple crypto maps with the same name (armadillo, in the following example) and different sequence numbers (10, in the following example). The combination of multiple crypto maps and different sequence numbers enables you to mix and match classic crypto and IPsec. You can also modify your PFS configuration here. PFS group1 is the default in the example given here. You could change the PFS to group2 or turn it off altogether, which you should not do.

Step 4: Apply the Crypto Map to an Interface

The following commands apply the crypto map to the interface. Remember to apply the crypto map to the egress interface, not the ingress one. If you have multiple crypto maps that you want to apply to this interface, you must tack the name onto the list in the crypto map command:

CYBERWRAITH(config)# int e0
CYBERWRAITH(config-if)# crypto map armadillo

Remember that crypto maps and their access lists are direction-based (either inbound or outbound) and that traffic not matching the access list is still transmitted without being encrypted.