Creating an Encrypted Router-to-Router VPN in a GRE Tunnel
Problem
You want to create an encrypted VPN through the Internet by connecting two routers using preshared keys.
Solution
In this example, we show how to use IPSec to encrypt traffic from 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)#encr aes 256
Router1(config-isakmp)#authentication pre-share
Router1(config-isakmp)#group 2
Router1(config-isakmp)#exit
Router1(config)#crypto isakmp key TUNNELKEY01 address 172.16.2.1 no-xauth
Router1(config)#crypto ipsec transform-set TUNNEL-TRANSFORM ah-sha-hmac esp-aes 256
Router1(cfg-crypto-trans)#mode transport
Router1(cfg-crypto-trans)#exit
Router1(config)#crypto map TUNNELMAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Router1(config-crypto-map)#set peer 172.16.2.1
Router1(config-crypto-map)#set transform-set TUNNEL-TRANSFORM
Router1(config-crypto-map)#match address 102
Router1(config-crypto-map)#exit
Router1(config)#access-list 102 permit gre host 172.16.1.1 host 172.16.2.1
Router1(config)#interface Tunnel1
Router1(config-if)#ip address 192.168.1.1 255.255.255.252
Router1(config-if)#tunnel source 172.16.1.1
Router1(config-if)#tunnel destination 172.16.2.1
Router1(config-if)#exit
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip address 172.16.1.1 255.255.255.0
Router1(config-if)#ip access-group 101 in
Router1(config-if)#crypto map TUNNELMAP
Router1(config-if)#exit
Router1(config)#access-list 101 permit gre host 172.16.2.1 host 172.16.1.1
Router1(config)#access-list 101 permit esp host 172.16.2.1 host 172.16.1.1
Router1(config)#access-list 101 permit udp host 172.16.2.1 host 172.16.1.1 eq isakmp
Router1(config)#access-list 101 permit ahp host 172.16.2.1 host 172.16.1.1
Router1(config)#access-list 101 deny ip any any log
Router1(config)#interface Loopback0
Router1(config-if)#ip address 192.168.16.1 255.255.255.0
Router1(config-if)#exit
Router1(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.2
Router1(config)#ip route 192.168.15.0 255.255.255.0 192.168.1.2
Router1(config)#end
Router1#
And 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)#encr aes 256
Router2(config-isakmp)#authentication pre-share
Router2(config-isakmp)#group 2
Router2(config-isakmp)#exit
Router2(config)#crypto isakmp key TUNNELKEY01 address 172.16.1.1
Router2(config)#crypto ipsec transform-set TUNNEL-TRANSFORM ah-sha-hmac esp-aes 256
Router2(cfg-crypto-trans)#mode transport
Router2(cfg-crypto-trans)#exit
Router2(config)#crypto map TUNNELMAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Router2(config-crypto-map)#set peer 172.16.1.1
Router2(config-crypto-map)#set transform-set TUNNEL-TRANSFORM
Router2(config-crypto-map)#match address 102
Router2(config-crypto-map)#exit
Router2(config)#access-list 102 permit gre host 172.16.2.1 host 172.16.1.1
Router2(config)#interface Tunnel1
Router2(config-if)#ip address 192.168.1.2 255.255.255.252
Router2(config-if)#tunnel source 172.16.2.1
Router2(config-if)#tunnel destination 172.16.1.1
Router2(config-if)#exit
Router2(config)#interface FastEthernet0/0
Router2(config-if)#ip address 172.16.2.1 255.255.255.0
Router2(config-if)#ip access-group 101 in
Router2(config-if)#crypto map TUNNELMAP
Router2(config-if)#exit
Router2(config)#access-list 101 permit gre host 172.16.1.1 host 172.16.2.1
Router2(config)#access-list 101 permit esp host 172.16.1.1 host 172.16.2.1
Router2(config)#access-list 101 permit udp host 172.16.1.1 host 172.16.2.1 eq isakmp
Router2(config)#access-list 101 permit ahp host 172.16.1.1 host 172.16.2.1
Router2(config)#access-list 101 deny ip any any log
Router2(config)#interface Loopback0
Router2(config-if)#ip address 192.168.15.1 255.255.255.0
Router2(config-if)#exit
Router2(config)#ip route 0.0.0.0 0.0.0.0 172.16.2.2
Router2(config)#ip route 192.168.16.0 255.255.255.0 192.168.1.1
Router2(config)#end
Router2#
Discussion
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 lowest priority and goes to the highest. The highest possible priority value is 10,000:
Router1(config)#crypto isakmp policy 10
Router1(config-isakmp)#encr aes 256
Router1(config-isakmp)#authentication pre-share
Router1(config-isakmp)#group 2
This policy uses 256-bit AES encryption, preshared authentication keys, and group 2 (1024 bit) for Diffie-Hellman (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
Global IKE policy
Protection suite of priority 10
encryption algorithm: AES - Advanced Encryption Standard (256 bit keys
).
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
Router1#
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 Secure Hash Algorithm (SHA), and the default lifetime is 86400 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.
Then, 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.16.2.1 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 host names 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. But you might want to consider using hostnames instead of IP addresses if the network topology means that there could be some ambiguity in which IP address will be used.
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 available preshared keys:
Router1#show crypto isakmp key
Keyring Hostname/Address Preshared Key
default 172.16.2.1 TUNNELKEY01
outer1#
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 status
172.16.2.1 172.16.1.1 QM_IDLE 1 0 ACTIVE
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 status
172.16.2.1 172.16.1.1 MM_NO_STATE 1 0 ACTIVE (deleted)
Router1#
This particular ISAKMP 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. Note, however, that this is just the ISAKMP SA, which is only needed at call setup time. So the actual IPSec security association is actually still active:
Router1#show crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: TUNNELMAP, local addr 172.16.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.2.1/255.255.255.255/47/0)
current_peer 172.16.2.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 14, #pkts encrypt: 14, #pkts digest: 14
#pkts decaps: 14, #pkts decrypt: 14, #pkts verify: 14
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 172.16.1.1, remote crypto endpt.: 172.16.2.1
path mtu 1500, ip mtu 1500
current outbound spi: 0xDBE0A93(230558355)
inbound esp sas:
spi: 0x33CEA934(869181748)
transform: esp-256-aes ,
Router1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
Router1#
We can knock down the IPSec session with this command:
Router1#clear crypto session
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-aes 256
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 discussed 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-aes {128|192|256} | Encrypt using the 128-bit, 192-bit, or 256-bit AES algorithm | |
| 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 256-bit AES 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 prevents you from entering impossible combinations.
It's also worth mentioning that, as Table 12-2 mentions, you can use IPSec to do compression of the IP packet payload. This is not commonly done, though, because there are problems with combining encryption with compression.
We note in passing that while the authors of the IPSec RFCs argue eloquently for the separate usefulness of authentication and encryption, in practice we believe that most of the time if your traffic is sensitive enough for one, you should do both. There are rare exceptions. It may be worthwhile authenticating NTP traffic, for example, to ensure that your time sources are valid, while the actual time of day information in the packet payload is not a sensitive piece of information. However, the extra configuration required to do both at the same time 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. This 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. And the GRE tunnel 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.7, 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 Chapters 6, 7, and 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. But in general, we don't 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
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Router1(config-crypto-map)#set peer 172.16.2.1
Router1(config-crypto-map)#set transform-set TUNNEL-TRANSFORM
Router1(config-crypto-map)#match address 102
Router1(config-crypto-map)#exit
Router1(config)#access-list 102 permit gre host 172.16.1.1 host 172.16.2.1
The crypto map defines an IPSec peer device by its IP address. If you are using hostnames instead of IP addresses, as we discussed earlier in this recipe, you should specify the peer's hostname instead of an IP address here. The map also selects the appropriate transform set, and matches on a particular set of IP addresses, defined in this case by access-list 102.
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.16.1.1, which is the IP address of the tunnel source, and 172.16.2.1, which is the tunnel's destination address. And because of the gre keyword, this access list will only match on GRE tunnel packets with these source and destination addresses.
Note that on the other router, the peer address is 172.16.1.1, and the access-list reverses the source and destination addresses:
Router2(config)#access-list 102 permit gre host 172.16.2.1 host 172.16.1.1
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 Tunnel1
Router1(config-if)#ip address 192.168.1.1 255.255.255.252
Router1(config-if)#tunnel source 172.16.1.1
Router1(config-if)#tunnel destination 172.16.2.1
Router1(config-if)#exit
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip address 172.16.1.1 255.255.255.0
Router1(config-if)#ip access-group 101 in
Router1(config-if)#crypto map TUNNELMAP
Router1(config-if)#exit
Router1(config)#access-list 101 permit gre host 172.16.2.1 host 172.16.1.1
Router1(config)#access-list 101 permit esp host 172.16.2.1 host 172.16.1.1
Router1(config)#access-list 101 permit udp host 172.16.2.1 host 172.16.1.1 eq isakmp
Router1(config)#access-list 101 permit ahp host 172.16.2.1 host 172.16.1.1
Router1(config)#access-list 101 deny ip any any log
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.
Also notice the access-list that we have applied to the external interface in this example.
We have done this to more accurately simulate the configuration for running encrypted site-to-site VPNs through the public Internet. In such situations you will need to have some sort of inbound traffic restrictions on your router to block unwanted traffic. This access-list shows the types of packets that you should allow your router to accept from the Internet to support the VPN. You will probably have other rules in practice as well.
The first line of access-list 101 permits the GRE packets themselves. Recall that we will be encrypting the GRE packets, so you are unlikely to see GRE packets in the steady state. However, we like to include a rule like this because it makes troubleshooting easier. As we mentioned above, you can simply remove the crypto map command from the external interfaces and verify connectivity between the tunnel interfaces:
Router1(config)#access-list 101 permit gre host 172.16.2.1 host 172.16.1.1
The second line permits the Encapsulation Security Protocol (ESP), which contains the encrypted packet payloads:
Router1(config)#access-list 101 permit esp host 172.16.2.1 host 172.16.1.1
The next line allows UDP Port 500, which is used by the ISAKMP protocol for establishing the IPSec connection:
Router1(config)#access-list 101 permit udp host 172.16.2.1 host 172.16.1.1 eq isakmp
We also allow Authentication Header Protocol (AHP):
Router1(config)#access-list 101 permit ahp host 172.16.2.1 host 172.16.1.1
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
3 FastEthernet0/0 172.16.2.1 set HMAC_SHA+AES_256_C 0 0
2000 FastEthernet0/0 172.16.2.1 set HMAC_SHA 0 522
2001 FastEthernet0/0 172.16.2.1 set HMAC_SHA 859 0
2002 FastEthernet0/0 172.16.2.1 set AES_256_CBC 0 522
2003 FastEthernet0/0 172.16.2.1 set AES_256_CBC 859 0
Router2#
This shows that the router has received and decrypted 522 encrypted packets from the peer we defined, and it has sent 859. It also shows we are using the SHA hash algorithm for authentication and 256-byte AES for encryption in the Algorithm column.