Encrypted Tunnels

In the previous example, we created a tunnel that could carry traffic between routers, but we didn't do anything to secure that traffic: the traffic went through the tunnel without any sort of encryption, so anyone with a packet sniffer and access to our network could see what was traveling through the tunnel. Since one of the biggest applications for tunneling is increased security, cryptography is essential. In this section, we'll explore two ways to encrypt the traffic flowing through the tunnel. First, we will use DSS and DES on a router running Version 11.3 of IOS. Depending on the feature set of your IOS, this form of encryption might be all that's available. (If other encryption methods, such as RSA, are available on your router, the configuration should be the same.) Next, we will look at encryption using IPSec, which is a security protocol that belongs to the TCP/IP protocol suite. The IPSec examples assume that you are using IOS Version 12.0 (or greater).

13.5.1. Tunnel Encryption with DSS and DES

Regardless of the type of encryption you use, an encrypted tunnel requires the generation of public and private keys, some form of authentication and key exchange (each end of the tunnel has to prove that it is who it says it is), and something to encrypt the actual traffic. In this example, we will use DSS (the Digital Signature Standard) for authentication and key exchange. Each host must generate private and public keys, and the hosts must exchange their public keys before traffic can flow. We use DES (the Digital Encryption Standard) for encryption. DES is now considered a relatively weak form of encryption, but it's still useful if your security needs aren't that great. In the IPSec section, we will use Triple DES (3DES) encryption, which is much more secure.

13.5.1.1. Generating keys

DSS requires us to generate public and private keys on each router. The routers at each end of the tunnel must share their public keys, which are used to encrypt and decrypt the messages sent across the tunnel. The private keys, of course, are never sent anywhere.

To generate a key pair, you must first use the zeroize command to erase any keys that are currently in the router's memory. (zeroize breaks any encryption that has already been configured. If you already have a key pair, skip this process and use the show command to display your public key.) Then use the command crypto key generate to generate the key pair:

You must generate a key for each router that will use this encryption method. Before going any further, save your keys by doing a copy running-config startup-config. If you don't, you will lose your keys the next time you reboot.

13.5.1.2. Configuring encryption on the tunnel

To encrypt our tunnel, we need a crypto map. Defining the map is relatively simple. We give it a name, an encryption method, and an access list. The name allows us to apply the map to the desired interfaces, the encryption method specifies how we want to perform encryption, and the access list ensures that we encrypt only traffic headed to the destination. In this example, we don't want to encrypt all the traffic that goes out the serial interface; we want to encrypt only traffic for the remote office.

The trickiest part of this configuration is to remember that you have to apply the crypto map both to the physical interface the tunnel uses and to the tunnel interface itself.

This configuration requires you to create the keys, and then cut and paste them into your router's configuration. That's clearly an awkward, error-prone process. It's possible to perform the key exchange automatically. Take the following steps:

On one router, start the key exchange in passive mode. After you press Enter to confirm, the router will wait for another router to initiate a key exchange connection:

office1(config)#crypto key exchange dss passive
Enter escape character to abort if connection does not complete.
Wait for connection from peer[confirm]
Waiting....

On the other router, start the key exchange in active mode, supplying the IP address of the first router and the name of the key you want to send to the other router. This is the name given to the key when it was created. After sending the key, the router asks you whether it should wait for a key from the first (passive) router; press Enter to confirm. In the following example, we initiate a key exchange to 192.168.1.1 and send the key named office2:

The first (passive) router receives the key sent by the active router, then asks whether you want to send a key in return. If you have more than one key configured on this router, it will ask you to select which key to send. In this example, we send the key office1 back to the active router:

The ID is useful for the clear crypto connection command, which allows you to remove a connection from the map. Clearing a connection is sometimes useful when you suspect that things aren't working when you are first configuring encryption. After you issue a clear, the connection is re-established, which causes the key exchange to occur again.

IPSec has significant advantages over the other available tunneling methods. Some of these advantages are:

multivendor support

automatic key management, which makes it much more scalable

compression before encryption

IPSec consists of four components. You really don't need to understand all of these pieces, but it is good to know what they mean when you see them in the configuration. The components are:

AH (Authentication Headers)

Provides strong cryptographic checksums for packets .

ESP (Encapsulating Security Payload)

Guarantees that your packet wasn't intercepted in transit.

IPcomp (IP Compression)

Compresses packets prior to encryption.

IKE (Internet Key Exchange)

Manages the keys.

In this section, we configure IPSec tunneling for the network in Figure 13-3. Although it looks more complex, this configuration is really quite similar to the configuration of the previous section. Some new items are configuring the IKE policy, setting the key, and setting the transform set.

To configure the IKE policy, we use the command crypto isakmp policy. The argument to this command is a priority value; the lower the number, the higher the policy's priority. In this example, the priority isn't important, but it is conceivable that a router will have several policies to choose from (possibly because it creates tunnels to different destinations). In this case, the router will use the highest-priority policy that both ends of the tunnel can agree on. The policy itself does two things: it sets the authentication hash algorithm to MD5, and it sets the authentication method to pre-share. The default hashing algorithm is SHA (Secure Hash Algorithm) , but it doesn't matter which hash algorithm you use as long as both ends of the tunnel agree. Pre-share tells the router that it should use pre-shared keys.

To configure pre-shared keys, we use the command crypto isakmp key. This command is simple; we provide a name for the key (officekey, in this case) followed by the peer's IP address (the address of office2). Remember that this key must be the same on both routers.

To configure the transform set, we use the command crypto ipsec transform-set. This command defines the protocols used in the set. In this example, we use the transform set esp-des esp-md5-hmac, which specifies DES for ESP and MD5 for the authentication algorithm. Other protocol combinations that can be used are ah-md5-hmac, esp-des, esp-3des, esp-md5-hmac, ah-sha-hmac, aesp-des, and comp-lzs. Again, the crucial thing isn't the actual protocols you use, but that the protocols on either end of the tunnel agree. The transform set is assigned a name, which in this case is office1-to-office2. In our example, we used the same name for the transform set on each routerthis will help you to preserve your sanity.

Finally, we create a crypto map, which specifies the ipsec-isakmp protocol, the peer address, the transform set, and the access list. Then we create a tunnel interface, to which we apply the crypto map.

Here's the configuration for Office 1:

hostname office1
!
! First we define the IKE policy. We are going to use MD5 and a pre-shared
! key that will be defined on both routers.
crypto isakmp policy 25
hash md5
encr 3des
authentication pre-share
!
! This command defines the pre-shared key we mentioned.
! This key must be the same on both routers. The IP address is
! that of the peer (office2, in this case).
crypto isakmp key officekey address 192.168.2.1
!
! This command sets the transform set we are going to use. The name can be
! different on each router, but the protocol list must be the same.
crypto ipsec transform-set office1-to-office2 esp-3des esp-md5-hmac
!
! Define the crypto map. Since we are using IKE, this map is fairly simple
crypto map tunnelmap 10 ipsec-isakmp
set peer 192.168.2.1
! Point to the transform set we configured earlier
set transform-set office1-to-office2
match address 101
!
interface Tunnel1
ip unnumbered Serial0
tunnel source Serial0
tunnel destination 192.168.2.1
tunnel checksum
crypto map tunnelmap
!
interface Ethernet0
ip address 10.10.1.1 255.255.255.0
!
interface Serial0
ip address 192.168.1.1 255.255.255.0
clockrate 64000
crypto map tunnelmap
!
ip route 0.0.0.0 0.0.0.0 192.168.1.2
ip route 10.10.2.0 255.255.255.0 Tunnel1
!
access-list 101 permit gre host 192.168.1.1 host 192.168.2.1

In this output, we can see the encrypted connection and the algorithm used to do the encryption.

13.5.4. Dynamic Multipoint VPN

In the previous section, we showed how to create an IPSec tunnel between two sites, which was not terribly complicated. However, if you have multiple routersand most of us doyou might need to configure IPSec tunnels between all of them. If you do a hub and spoke configuration, your hub's configuration will quickly grow. As each new spoke is added to the system, the hub router needs additional configuration to accommodate the new spoke. On top of all that, if we decide to configure tunnels between our spokes (spoke-to-spoke), we add another layer of complexity to the configurations of all the routers.

To solve this problem, Cisco has introduced the DMVPN feature, which stands for Dynamic Multipoint VPN. Basically, this feature combines GRE Tunnels, IPSec encryption, and Next Hop Resolution Protocol (NHRP) to provide a better way to implement large-scale IPSec VPNs. The main features are:

Reduced configuration on the hub router. The hub needs to be configured only once. As more spokes are added, the hub router configuration remains the same as NHRP learns about new spokes.

Automatic IPSec encryption

Support for dynamically addressed spoke routers such as cable and DSL spokes.

Dynamic tunnel creation for spoke-to-spoke communication.

Figure 13-4 shows our DMVPN network. We have one hub router and two spoke routers.

Figure 13-4. DMVPN network diagram

In this configuration, each spoke has a permanent IPSec tunnel to the hub router. The spoke-to-spoke tunnels are dynamicallyand temporarilycreated.

When a spoke router wants to communicate with another spoke router, the router asks the NHRP server (the hub) for the real address of the destination spoke. After it has this address, dynamic IPSec tunnels are created. These dynamic spoke-to-spoke tunnels allow traffic to flow directly between the spokes instead of being relayed through the hub routers. After a certain amount of inactivity, these tunnels are shut down to conserve resources.

13.5.4.1. Configuring DMVPN

To configure this feature, we need to accomplish three main tasks: configure an IPSec profile, enable the hub for DMVPN, and enable each spoke for DMVPN.

13.5.4.1.1. Configuring an IPSec profile

The commands for creating the IPSec profile are identical to the crypto map commands we used in the previous section. However, since this is a profile, only a few of the commands are used. Basically, we set up the crypto transformation set along with various options. In this example, we just create the profile like this:

! Use Triple-DES
crypto ipsec transform-set set1 esp-3des esp-md5-hmac
!
! This is the profile, the name we are using is dmvpn-exmample, which
! we will use in the next configuration step
crypto ipsec profile dmvpn-example
set transform-set set1
set security association lifetime seconds 60

This part of the configuration is done on the hub and every spoke router.

13.5.4.1.2. Configuring the hub for DMVPN

To configure the hub, we want to set up our tunnel for Multipoint GRE tunnels and NHRP. In previous examples, we used the ip unnumbered command for the IP address of the tunnel in order to reduce the number of subnets we used. However, for DMVPN, this can make debugging more difficult. So for our DMVPN configurations, we apply an IP address to our tunnels.

The main commands we will use are ip nhrp, tunnel mode greSmultipoint, and tunnel protection ipsec profile . Each of these commands is documented in the following configuration example.

We lowered the MTU to 1416 so that packets are fragmented before encryption. Otherwise, the receiving router would have to reassemble the packet.

13.5.4.1.3. Configuring a spoke router for DMVPN

On our spoke routers, the configuration is pretty much the same as the hub. We will add some simple NHRP mappings back to the hub router with the ip nhrp map command. The ip nhrp map multicast command is needed because there is more than one destination for multicast packets in our multipoint tunnel.

On Spoke 2's router, the configuration is identical with the exception of the IP addresses. No new configuration is required on the hub router as we add new spoke routers, which makes DMVPN such a nice feature.

13.5.4.1.4. Verifying DMVPN configuration

We can verify our configuration with the commands show ip route and show ip nhrp.