You want to create an encrypted VPN through the Internet connecting two routers using pre-shared keys.
In this example, we show how to use IPSec to encrypt traffic from one router to another through a GRE tunnel. Here is the configuration of the first router:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#crypto isakmp policy 10 Router1(config-isakmp)#encryption 3des Router1(config-isakmp)#authentication pre-share Router1(config-isakmp)#group 2 Router1(config-isakmp)#exit Router1(config)#crypto isakmp key TUNNELKEY01 address 172.22.1.4 no-xauth Router1(config)#crypto ipsec transform-set TUNNEL-TRANSFORM ah-sha-hmac esp-3des esp- sha-hmac Router1(cfg-crypto-trans)#mode transport Router1(cfg-crypto-trans)#exit Router1(config)#crypto map TUNNELMAP 10 ipsec-isakmp Router1(config-crypto-map)#set peer 172.22.1.4 Router1(config-crypto-map)#set transform-set TUNNEL-TRANSFORM Router1(config-crypto-map)#match address 116 Router1(config-crypto-map)#exit Router1(config)#access-list 116 permit gre host 172.22.1.3 host 172.22.1.4 Router1(config)#interface Tunnel5 Router1(config-if)#ip address 192.168.66.5 255.255.255.252 Router1(config-if)#tunnel source 172.22.1.3 Router1(config-if)#tunnel destination 172.22.1.4 Router1(config-if)#exit Router1(config)#interface FastEthernet0/1 Router1(config-if)#ip address 172.22.1.3 255.255.255.0 Router1(config-if)#crypto map TUNNELMAP Router1(config-if)#end Router1#
Here is the corresponding configuration for the other router:
Router2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router2(config)#crypto isakmp policy 10 Router2(config-isakmp)#encryption 3des Router2(config-isakmp)#authentication pre-share Router2(config-isakmp)#group 2 Router2(config-isakmp)#exit Router2(config)#crypto isakmp key TUNNELKEY01 address 172.22.1.3 no-xauth Router2(config)#crypto ipsec transform-set TUNNEL-TRANSFORM ah-sha-hmac esp-3des esp- sha-hmac Router2(cfg-crypto-trans)#mode transport Router2(cfg-crypto-trans)#exit Router2(config)#crypto map TUNNELMAP 10 ipsec-isakmp Router2(config-crypto-map)#set peer 172.22.1.3 Router2(config-crypto-map)#set transform-set TUNNEL-TRANSFORM Router2(config-crypto-map)#match address 116 Router2(config-crypto-map)#exit Router2(config)#access-list 116 permit gre host 172.22.1.4 host 172.22.1.3 Router2(config)#interface Tunnel5 Router2(config-if)#ip address 192.168.66.6 255.255.255.252 Router2(config-if)#tunnel source 172.22.1.4 Router2(config-if)#tunnel destination 172.22.1.3 Router2(config-if)#exit Router2(config)#interface FastEthernet1/0 Router2(config-if)#ip address 172.22.1.4 255.255.255.0 Router2(config-if)#crypto map TUNNELMAP Router2(config-if)#end Router2#
There are several steps to these configurations, but they are the same on both routers. The first step is to create an appropriate key exchange policy using ISAKMP. The following set of commands defines the policy with priority 10. When ISAKMP negotiates the Security Association (SA) parameters, it starts with the highest priority and goes to the lowest. The highest possible priority value is 10,000:
Router1(config)#crypto isakmp policy 10 Router1(config-isakmp)#encryption 3des Router1(config-isakmp)#authentication pre-share Router1(config-isakmp)#group 2
This policy uses 168-bit Triple DES encryption, pre-shared authentication keys, and group 2 (1024-bit) for DH exchange. If we did not configure this, the routers would have to resort to the default parameters, which are 56-bit DES encryption, Rivest Shamir Adleman (RSA) signatures for authentication and DH group 1 (768-bit). You can see the available policies on a router with the show crypto isakmp policy command:
Router1#show crypto isakmp policy
Protection suite of priority 10
encryption algorithm: Three key triple DES
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #2 (1024 bit)
lifetime: 86400 seconds, no volume limit
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
We could have also adjusted the hash algorithm and the lifetime of a particular SA as follows:
Router1(config)#crypto isakmp policy 20 Router1(config-isakmp)#hash md5 Router1(config-isakmp)#lifetime 600
This policy uses the somewhat less secure but faster MD5 hash algorithm and reduces the SA lifetime to 600 seconds (10 minutes). The default hash algorithm is the standard IPSec SHA, and the default lifetime is 86,400 seconds (24 hours). Reducing the lifetime forces the routers to renegotiate the various SA parameters, including encryption keys, more frequently. This frequent renegotiation improves security, but at the expense of higher router CPU utilization and possible delays during the renegotiation process.
Because we have configured the routers to use pre-shared keys in this policy, we need to define this initial key with the crypto isakmp key command:
Router1(config)#crypto isakmp key TUNNELKEY01 address 172.22.1.4 no-xauth
As you can see, this sets this key only for one IP address, which is the address of the other router. We have included the no-xauth option on the command line to explicitly disable IKE Extended Authentication (XAuth) on the routers, which is not necessary when the peer is another router. ISAKMP can work with either IP addresses or hostnames to identify devices. So we could have specified this command like this instead:
Router1(config)#crypto isakmp key TUNNELKEY01 hostname Router2.oreilly.com no-xauth
However, to do this, we would also have needed to ensure that the remote device used its hostname when declaring its ISAKMP identity:
Router2(config)#crypto isakmp identity hostname
We avoided this extra complication by simply using IP addresses, which is the default behavior.
There are several useful commands for looking at the ISAKMP functions on your router. The first is show crypto isakmp key, which lists all of the pre-shared keys that are available:
Router1#show crypto isakmp key Hostname/Address Preshared Key 172.22.1.4 TUNNELKEY01 Router1#
Note that this doesn't mean that there is an active SA using this key, merely that the key is available if required. If you want to see information on active ISAKMP SAs, you should use the following command:
Router1#show crypto isakmp sa dst src state conn-id slot 172.22.1.4 172.22.1.3 QM_IDLE 1 0 Router1#
In this case, you can see that there is an active connection between the two routers shown in the example. The connection ID for this particular SA is shown in the conn-id column. You can use this ID number to clear the SA and force the routers to renegotiate as follows:
Router1#clear crypto isakmp 1
Router1#show crypto isakmp sa
dst src state conn-id slot
172.22.1.4 172.22.1.3 MM_NO_STATE 1 0 (deleted)
Router1#
This particular SA is now in a deleted state, as the routers begin to renegotiate their ISAKMP parameters. A short time later, they will re-establish a new SA.
The next part of the router configuration defines the IPSec transform set, and gives it the name TUNNEL-TRANSFORM, to distinguish it from other transform sets that we might want to use for other purposes:
Router1(config)#crypto ipsec transform-set TUNNEL-TRANSFORM ah-sha-hmac esp-3des esp-
sha-hmac
Router1(cfg-crypto-trans)#mode transport
A transform is simply the operation that IPSec will perform on any matching data packets. There are several possible transforms, which are listed in Table 12-2.
|
Transform type |
Transform name |
Description |
|---|---|---|
|
Compression |
comp-lzs |
Compress using Lempel Ziv Stac algorithm |
|
Authentication Header (AH) |
ah-md5-hmac |
Authenticate using MD5 algorithm |
|
ah-sha-hmac |
Authenticate using SHA algorithm | |
|
Encapsulating Security Payload (ESP) |
esp-des |
Encrypt using 56-bit DES |
|
esp-3des |
Encrypt using 168-bit DES | |
|
esp-null |
No encryption | |
|
ESP with authentication |
esp-md5-hmac |
Encrypt, and use MD5 for authentication |
|
esp-sha-hmac |
Encrypt, and use SHA for authentication |
In the above example, we chose to combine the more secure 168-bit DES encryption with the more reliable SHA authentication system for maximum security on both the AH and ESP portions of the packet. As we said earlier, many of the combinations are not possible (for example, you cannot combine 56-bit DES with 168-bit DES, as it doesn't make sense). The router will prevent you from entering impossible combinations.
It's also worth mentioning that you can use IPSec to compress the IP packet payload. This is not commonly done, though, because there are problems with combining encryption with compression.
While the authors of the IPSec RFCs argue eloquently for the separate usefulness of authentication and encryption, in practice we believe that if your traffic is important enough for one, you should do both. The extra configuration on the router is minimal, and if your router's CPU can't easily handle the load of both encrypting and authenticating, it is probably not the right router for the job. So, if you are going to either authenticate or encrypt your traffic, we recommend using both together for added security.
In this transform set, we have also instructed the router to use IPSec transport mode:
Router1(cfg-crypto-trans)#mode transport
By default, IPSec connections will use tunnel mode, which means that the two devices will set up their own tunnel for IPSec to use. This actually uses the IP-in-IP tunnel protocol that we mentioned in the introduction to this chapter. However, in this example we want to use a GRE tunnel between the routers instead, and simply authenticate and encrypt the GRE packets, which requires transport mode.
The main reasons for using GRE tunnels instead of IPSec's native tunnel mode are simplicity and flexibility. Using a GRE tunnel between these routers allows us to take advantage of some of the useful GRE features if we want them. For example, we can easily use a GRE tunnel to pass other protocols such as IPX or AppleTalk, and we can use the techniques discussed in Recipe 12.3 to pass routing protocol traffic through the encrypted tunnel. The GRE tunnel also makes debugging much easier, as we can simply disable the encryption and ping through the tunnel or ping the tunnel destination addresses to verify connectivity without the complications of authentication and encryption. If the other end of this tunnel was a workstation instead of a router, however (as in Recipe 12.6), we would have to use tunnel mode.
The next step is to define a crypto map that combines all of these elements. The following set of commands defines a map called TUNNELMAP. The number following this name is a sequence number, similar to the route map sequence numbers that we discussed in Chapter 6, Chapter 7 and Chapter 8. This allows you to associate many peers with a single router interface by creating several different map clauses with different sequence numbers, all associated with the same map.
The keyword ipsec-isakmp on the end of the crypto map command tells the router that this map will apply to IPSec connections that use ISAKMP for key management. You could also specify ipsec-manual if you wanted to do the key management manually. We don't generally recommend manual key management because it is so much trouble to get right, while ISAKMP automates most of the work for you:
Router1(config)#crypto map TUNNELMAP 10 ipsec-isakmp Router1(config-crypto-map)#set peer 172.22.1.4 Router1(config-crypto-map)#set transform-set TUNNEL-TRANSFORM Router1(config-crypto-map)#match address 116 Router1(config-crypto-map)#exit Router1(config)#access-list 116 permit gre host 172.22.1.3 host 172.22.1.4
The crypto map defines an IPSec peer device by its IP address. If you are using hostnames instead of IP addresses (as discussed earlier in this recipe), you should specify the peer's hostname instead of an IP address. The map also selects the appropriate transform set, and matches on a particular set of IP addresses, defined in this case by access-list 116.
The access list tells IPSec what packets it should apply this transform set to. In this case, we specify a source IP address of 172.22.1.3, which is the IP address of the tunnel source, and 172.22.1.4, which is the tunnel's destination address. And because of the gre keyword, this access list will only match GRE tunnel packets with these source and destination addresses.
On the other router, the peer address is 172.22.1.3, and the access list reverses the source and destination addresses:
Router2(config)#access-list 116 permit gre host 172.22.1.4 host 172.22.1.3
Then, with all of the IPSec and ISAKMP configuration in place, we can finally create the tunnel and turn on the encryption. The tunnel configuration is similar to what we used in Recipe 12.1:
Router1(config)#interface Tunnel5 Router1(config-if)#ip address 192.168.66.5 255.255.255.252 Router1(config-if)#tunnel source 172.22.1.3 Router1(config-if)#tunnel destination 172.22.1.4 Router1(config-if)#exit Router1(config)#interface FastEthernet0/1 Router1(config-if)#ip address 172.22.1.3 255.255.255.0 Router1(config-if)#crypto map TUNNELMAP
It's extremely important to notice that we have applied the crypto map to the interface that will be receiving the GRE packets, and not to the tunnel itself. This is because IPSec is encrypting the GRE tunnel packets, rather than the payload of those packets. For one thing, the GRE tunnel's payload is not necessarily an IP packet. However, even when they are IP packets, the source and destination IP addresses of the GRE payload could be devices somewhere behind the router. This breaks the essential requirement for IPSec's transport mode, which is that the source and destination IP addresses must be the devices themselves. So the only way you could successfully apply the crypto map to the tunnel interface would be by using an IPSec tunnel inside of the GRE tunnel, which would not be very efficient.
You can see that the encryption is working properly by looking at the output of the following command on either router:
Router2#show crypto engine connections active ID Interface IP-Address State Algorithm Encrypt Decrypt 1 FastEthernet1/0 172.22.1.4 set HMAC_SHA+3DES_56_C 0 0 2002 FastEthernet1/0 172.22.1.4 set HMAC_SHA+3DES_56_C 0 407 2003 FastEthernet1/0 172.22.1.4 set HMAC_SHA+3DES_56_C 1019 0 Router2#
This shows that the router has received and decrypted 407 encrypted packets from the peer that we defined, and it has sent 1,019. It also shows that we are using the SHA hash algorithm for authentication and Triple DES for encryption in the Algorithm column.
|
|
|
| Top |