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:

 office1(config)#crypto key zeroize dss
 Warning! Zeroize will remove your DSS signature keys.
 Do you want to continue? [yes/no]: yes
 % Keys to be removed are named office1.
 Do you really want to remove these keys? [yes/no]: yes
 % Zeroize done.
 office1(config)#crypto key generate dss office1
 Generating DSS keys ....
 [OK]

Now use the command show crypto key mypubkey dss to display the key:

 office1#show crypto key mypubkey dss
 Key name: office1
 Serial number: 10609455
 Usage: Signature Key
 Key Data:
 E3F9ECB2 73841C55 42DBFFF4 10245836 0291EC42 8F97FF5E FA2B0314 AF29E520
 407004D5 70AA888C 88B25313 FACD03B6 6608D9EB F0F7C4D0 A679F408 F7E90C5F

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.

Here is the configuration for Office 1, with encryption enabled:

 hostname office1
 !
 ! Define office2's public key using the pubkey-chain command. Older versions
 ! of the IOS use only the crypto public-key command.
 crypto key pubkey-chain dss
 named-key office2 signature
 serial-number 06897848
 key-string
 91A48507 2AC44FB3 C0EDBA3C B87C8F14 E2729110 6734DE5F 509C4476 1117E427
 B157882D B240CD84 2105C0FA 7F00C6B8 2493C4A7 A5C036A8 9E408D91 D5B73870
 quit
 !
 ! Define our crypto map. We named it tunnelmap. The 5 is just
 ! a sequence number.
 crypto map tunnelmap 5
 set peer office2
 ! Encrypt with 40-bit DES, our only choice on this router's IOS version
 set algorithm 40-bit-des
 ! Only encrypt traffic for the tunnel with access list 101
 match address 101
 !
 interface Tunnel1
 ip unnumbered Serial0
 tunnel source Serial0
 tunnel destination 192.168.2.1
 tunnel checksum
 ! Apply the crypto map to the tunnel
 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
 ! Don't forget to apply the crypto map here
 crypto map tunnelmap
 !
 ! Static route to our provider
 ip route 0.0.0.0 0.0.0.0 192.168.1.2
 ! Route all tunnel traffic through the tunnel
 ip route 10.10.2.0 255.255.255.0 Tunnel1
 !
 ! Our access list is only one line long. Optionally, we could have used the
 ! keyword "ip" instead of "gre". This access list says encrypt tunnel traffic
 ! from our host to the destination
 access-list 101 permit gre host 192.168.1.1 host 192.168.2.1

And here is the configuration for Office 2:

 hostname office2
 !
 ! Define office1's public key using the pubkey-chain command. Older versions
 ! of the IOS use only the crypto public-key command.
 crypto key pubkey-chain dss
 named-key office1 signature
 serial-number 10609455
 key-string
 9FFA2039 F4642B77 21A6FBA7 5179E1D8 211DD211 DA96699C 2045730D AB033253
 8A101977 B6580054 FEDBA12E 97F6B1BE 0D40EFB1 6F62ABBC 952F6DAF BB87BE60
 quit
 !
 ! Define our crypto map. We named it tunnelmap. The 5 is just
 ! a sequence number.
 crypto map tunnelmap 5
 set peer office1
 ! Encrypt with 40-bit DES, our only choice on this router's IOS version.
 set algorithm 40-bit-des
 ! Only encrypt traffic for the tunnel with access list 101
 match address 101
 !
 interface Tunnel1
 ip unnumbered Serial1
 tunnel source Serial1
 tunnel destination 192.168.1.1
 ! Apply the crypto map to the tunnel
 crypto map tunnelmap
 !
 interface Ethernet0
 ip address 10.10.2.1 255.255.255.0
 !
 interface Serial1
 ip address 192.168.2.1 255.255.255.0
 clockrate 64000
 ! Don't forget to apply the crypto map to this interface
 crypto map tunnelmap
 !
 ! Static route to our provider
 ip route 0.0.0.0 0.0.0.0 192.168.2.2
 !
 ! Route all tunnel traffic through the tunnel
 ip route 10.10.1.0 255.255.255.0 Tunnel1
 !
 ! Our access list is only one line long. Optionally, we could have used the
 ! keyword "ip" instead of "gre". This access list says encrypt tunnel traffic
 ! from our host to the destination
 access-list 101 permit gre host 192.168.2.1 host 192.168.1.1

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:

1. 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....
   

    
2. 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:

    office2(config)#crypto key exchange dss 192.168.1.1 office2
    Public key for office2:
    Serial Number 06897848
    Fingerprint 91A4 8507 2AC4 4FB3
   
    Wait for peer to send a key[confirm]
    Waiting ....
   

    
3. 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:

    Send peer a key in return[confirm]
    Which one?
    some-other-key? [yes]: n
    office1? [yes]:
    Public key for office1:
    Serial Number 06897848
    Fingerprint 91A4 8507 2AC4 4FB3
   

    
4. The second (active) router confirms that it has received the key from the first router.

    Public key for office1:
    Serial Number 10609455
    Fingerprint E3F9 ECB2 7384 1C55
    Add this public key to the configuration? [yes/no]: y
   

    

Now you have configured the keys on each of your routers without having to cut and paste the long key values.

13.5.2. DES Tunnel show Commands

When you're working with DES tunnels, a few show commands are particularly useful.

13.5.2.1. show crypto engine connections active

This command shows all active encrypted connections:

 office2#show crypto engine connections active
 ID Interface IP-Address State Algorithm Encrypt Decrypt
 13 Serial1 192.168.2.1 set DES_40_CFB64 10 0

Or if you are using Triple DES (3DES), which is more secure that regular DES, the output reflects that choice:

 office2#show crypto engine connections active
 ID Interface IP-Address State Algorithm Encrypt Decrypt
 13 Serial1 192.168.2.1 set HMAC_MD5+3DES_56_C 10 0

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.

13.5.2.2. show crypto engine configuration

This command summarizes the currently running encryption:

 office2#show crypto engine configuration
 crypto engine name: office2
 crypto engine type: software
 serial number: 06897848
 crypto engine state: dss key generated
 crypto lib version: 10.0.0

 platform: rp crypto engine

 Encryption Process Info:
 input queue top: 103
 input queue bot: 103
 input queue count: 0

 

13.5.3. IPSec Tunneling

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

Here's the configuration for Office 2:

 hostname Office2
 !
 ! 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 above.
 ! This key must be the same on both routers. The IP address is
 ! that of the peer (office1, in this case).
 crypto isakmp key officekey address 192.168.1.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.1.1
 set transform-set office1-to-office2
 match address 101
 !
 interface Tunnel1
 ip unnumbered Serial1
 tunnel source Serial1
 tunnel destination 192.168.1.1
 tunnel checksum
 crypto map tunnelmap
 !
 interface Ethernet0
 ip address 10.10.2.1 255.255.255.0
 !
 interface Serial1
 ip address 192.168.2.1 255.255.255.0
 crypto map tunnelmap
 !
 ip route 0.0.0.0 0.0.0.0 192.168.2.2
 !
 ip route 10.10.1.0 255.255.255.0 Tunnel1
 !
 access-list 101 permit gre host 192.168.2.1 host 192.168.1.1

To show that our IPSec configuration is working, we use the show crypto engine command:

 office2#show crypto engine connections active

 ID Interface IP-Address State Algorithm Encrypt Decrypt
 22 Serial1 192.168.2.1 set HMAC_MD5+3DES_56_C 10 0

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.

Here's the configuration for our HUB router:

 !
 hostname hubrouter
 !
 ! Configure our tunnel interface.
 interface tunnel 100
 ip address 10.1.1.1 255.255.255.0
 ip mtu 1416
 ! Set up NHRP authentication string. This string must match on all
 ! routers that are participating in NHRP
 ip nhrp authentication ournhrpstring

 ! Configure NHRP to add our spoke routers to the NHRP mappings
 ip nhrp map multicast dynamic
 ! Enable NHRP on the interface with a network-id. This id must
 ! match on all routers
 ip nhrp network-id 1000
 ! Configure our tunnel source, which is ethernet0
 tunnel source ethernet0
 ! Set a key for our tunnel
 ! This must be identical on all routers within our DMVPN network
 tunnel key 10000
 ! Enable Multipoint GRE (mGRE)
 tunnel mode gre multipoint
 ! Enable IPSec by associating an IPSec profile. This profile name is
 ! the same one we created earlier
 tunnel protection ipsec profile dmvpn-example
 ! We need to disable split-horizon for the tunnel. In this case, we are
 ! using EIGRP.
 no ip split-horizon eigrp 100
 delay 1000
 bandwidth 1000
 !
 interface Ethernet0
 ip address 172.16.1.1 255.255.255.0
 no shutdown
 !
 interface Ethernet1
 ip address 192.168.1.1 255.255.255.0
 no shutdown
 !
 interface Ethernet2
 ip address 172.16.2.1 255.255.255.0
 no shutdown
 !
 router eigrp 100
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0 0.0.0.255
 no auto-summary
 !
 ! Don't forget our IPSec Profile from earlier
 crypto ipsec transform-set set1 esp-3des esp-md5-hmac
 crypto ipsec profile dmvpn-example
 set transform-set set1
 set security association lifetime seconds 60

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.

Here's the configuration for the Spoke 1 router:

 !
 hostname spoke1
 !
 ! Configure our tunnel interface.
 interface tunnel 100
 ip address 10.1.1.2 255.255.255.0
 ip mtu 1416
 ! Setup NHRP authentication string. This string must match on all
 ! routers that are participating in NHRP
 ip nhrp authentication ournhrpstring
 ! Map the tunnel ip to the HUB's physical address
 ip nhrp map 10.1.1.1 172.16.1.1
 ! Map multicast packets to the HUB's physical address
 ip nhrp map multicast 172.16.1.1
 ! Configure the hub router as the NHRP server
 ip nhrp nhs 10.0.0.1
 ! Enable nhrp on the interface
 ip nhrp network-id 1000
 ! Configure our tunnel source, which is ethernet0
 tunnel source ethernet0
 ! Set a key for our tunnel
 tunnel key 10000
 ! Enable Multipoint GRE (mGRE)
 tunnel mode gre multipoint
 ! enable IPSec by associating an IPSec profile. This profile name is
 ! the same one we created earlier
 tunnel protection ipsec profile dmvpn-example
 ! We need to disable split-horizon for the tunnel. In this case, we are
 ! using EIGRP.
 no ip split-horizon eigrp 100
 delay 1000
 bandwidth 1000
 !
 interface Ethernet0
 ip address 172.16.1.2 255.255.255.0
 no shutdown
 !
 interface Ethernet1
 ip address 192.168.2.1 255.255.255.0
 no shutdown
 !
 router eigrp 100
 network 10.1.1.0 0.0.0.255
 network 192.168.2.0 0.0.0.255
 no auto-summary
 !
 ! Don't forget our IPSec Profile from earlier
 crypto ipsec transform-set set1 esp-3des esp-md5-hmac
 crypto ipsec profile dmvpn-example
 set transform-set set1
 set security association lifetime seconds 60

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.

 Hub#show ip nhrp
 10.1.1.2/32 via 10.1.1.2, Tunnel00 created 00:00:17, expire 00:05:43
 Type: dynamic, Flags: authoritative unique registered
 NBMA address: 172.16.2.1