Chapter 12. Tunnels and VPNs
12.0. Introduction
A tunnel is essentially just a method for encapsulating one protocol in another. There are many reasons for doing this. In Chapter 15 we will discuss DLSw, which is commonly used to transmit SNA traffic through an IP network. The SNA protocol is not routable, so the tunnel allows you to send this traffic through a scalable routed network.
You can also use tunnels to transmit protocols that are routable, but not fully supported by the network. For example, some organizations find that they need to be able to send IPX through their networks to support legacy applications. But few network engineers are willing to invest the extra time or money required to build native IPX support into their routing core. So this is an ideal situation for using tunnels.
And we often see tunnels for carrying IP traffic through an IP network. The classic example of this is a Virtual Private Network (VPN) that connects two private networks through a public network such as the Internet. But there are other places where it can be useful to tunnel IP in IP.
One of the most common reasons for tunneling IP in IP is to get around architectural problems with dynamic routing protocols. For example, in Chapter 8 we discussed OSPF virtual links. These are effectively just tunnels that let you put routers in different OSPF areas than their physical connections allow.
Another example appears when you need to extend a routing protocol through regions of the network that don’t support this protocol. Some WAN carriers provide IP connectivity between customer locations, similar to a public Internet. But the carrier network can’t always support the customer’s routing protocol and it is often not desirable to mix the carrier and customer routing tables.
Tunnels are extremely useful in lab or test environments where they allow you to emulate more complex network topologies. Further, in lab environments it is sometimes necessary to tunnel test data through a production network to ensure that the testing cannot interfere with the functioning of the production network. We expect to see a lot of tunneling during the migration phases of any future large scale conversions to IPv6.
Most of the examples in this chapter will look at Generic Routing Encapsulation (GRE) tunnels, sometimes with encryption support using IPSec. GRE is an open standard documented in RFCs 1701 and 1702, and updated in RFC 2784. These documents actually describes GRE Version 0, which is the standard version of GRE. There is also a GRE Version 1, which is more commonly called PPTP (Point-to-Point Tunneling Protocol), and is described in RFC 2637. The key different between GRE and PPTP is that PPTP includes a PPP intermediate layer, while GRE directly supports Layer 3 protocols such as IP and IPX. This chapter does not have the space to cover PPTP or its cousins L2TP (Layer 2 Tunneling Protocol) and L2F (Layer 2 Forwarding). These protocols are commonly used in situations where mobile users need to make VPN connections through the public Internet to an enterprise IP network. There are simply too many different variations to adequately cover even the most common configurations.
GRE doesn’t use TCP or UDP. Instead, this protocol works directly with the IP layer, using IP Protocol number 47. It includes its own features for verifying delivery and integrity. The GRE packet’s payload includes a complete Layer 3 packet with its payload and headers intact. The routers that terminate the tunnel take packets and wrap them in a new IP packet with a GRE header. They forward this GRE packet through the IP network to the router that supports the other end of the tunnel. The receiving router then simply unwraps the encapsulated packet and sends it on its way. To the encapsulated packet, this entire process has taken a single routing hop, even though the GRE packet may have traversed many routers to reach its destination.
There are other common tunnel protocols, such as IP-in-IP, which uses IP protocol number 4. This protocol is an open standard that is documented in RFC 2003. In general we prefer GRE to IP-in-IP because it offers considerably greater flexibility, particularly on Cisco routers.
Tunnels can have packet fragmentation issues. The problem is simply that when you put a second IP header on an existing packet, you get a bigger packet. If the original packet is already at or close to the Maximum Transmission Unit (MTU) packet size that the network can support, putting this packet in a tunnel forces the router to fragment it. Most of the time this is not a problem, but some applications do not cope well with packet fragmentation.
Normally, applications that can’t accept packet fragmentation will set the Don’t Fragment (DF) bit in the IP header. The router must drop oversized packets that it cannot fragment, but it sends an ICMP message back to the end device to tell it to use a smaller packet size.
The net result is that when you use tunnels, you reduce the effective MTU of your network. This doesn’t necessarily cause problems, but it is important to be aware of the consequences.
Internet Protocol Security (IPSEC) is a suite of security related protocols and algorithms documented in RFCs 2401 through 2412 and RFC 2451. This is far more information than we can even summarize in a book like this, so we mention only some of the most immediately relevant points. The RFCs or books such as IPSec: Securing VPNs (RSA Press) are good resources for more information.
The IPSec framework provides features for authenticating and encrypting traffic as well as for securely exchanging encryption and authentication keys. It is designed to work with both IPv4 and IPv6, and can accommodate a variety of different basic encryption, authentication, and key exchange algorithms. This algorithmic independence is one of the essential design criteria of IPSec. It allows you to transparently substitute a new encryption algorithm, for example, if somebody discovers a critical flaw in the old one, or if a new algorithm is more efficient.
IPSec provides security only at the IP layer. This allows it to protect applications and data operating at higher layers of the protocol stack. This is important because it means that you can use IPSec in conjunction with other insecure protocols or applications and, if done properly, achieve a good level of overall security. Also, because IPSec works at the IP layer, you can readily use it with any of the higher layer IP-based protocols such as TCP, UDP, ICMP, multicast, and so forth.
Unfortunately, one of the most confusing things about IPSec is the proliferation of different protocols and algorithms that handle different parts of the key management, authentication, and encryption processes. Therefore, we will briefly explain some of the more common terms and concepts.
Internet Security Association Key Management Protocol (ISAKMP) is essentially a framework for key exchange, a generic set of procedures and packet formats that allow devices to reliably and securely pass encryption and authentication keys to one another. It includes such concepts as the key security association, which defines not only the keys themselves but important parameters such as the specific algorithms to be used and the length of time that this key is valid for. This information is all negotiated by the IPSec end devices when they first establish a session, and periodically updated if the session remains active for a longer period of time.
Internet Key Exchange (IKE) is a specific protocol for securely exchanging keys using the ISAKMP framework. It uses the OAKLEY key determination protocol, which is defined in RFC 2412. OAKLEY distributes keys of arbitrary types for arbitrary algorithms to use. One of the methods that it can use is the Diffie-Hellman (DH) key exchange model.
DH is a mathematical algorithm that uses properties of large prime numbers to allow users to exchange key information in encrypted form. Both devices authenticating a session can calculate a common key based on the encrypted information that they exchange. There are two issues with this algorithm.
The first is that it can be broken by a “man in the middle” attack. This essentially involves somebody intercepting the exchanged key information and rewriting it to create a new valid key with each of the end devices. The various key management protocols get around this problem by using a separate authentication system to validate the exchanged information.
The second problem is that even with authentication, if the prime numbers aren’t large enough, it is possible to mathematically deduce the key. To resolve this problem, Cisco routers offer several different DH Groups. Group 1 uses 768-bit values to define the prime numbers, Group 2 uses 1024-bit primes. And, in IOS level 12.1T, Cisco introduced support for Group 5 DH, which uses a 1536-bit value for its prime numbers. With current computing power, if somebody really wants your data, 768-bit values are not very secure. So we recommend using Group 2 or higher.
OAKLEY also supports the Perfect Forward Secrecy (PFS) system. PFS is a system that ensures that even if somebody is able to break one of the keys, this will tell them nothing about any other keys. This is because the keys are not derived from one another. Many of the Cisco commands related to key exchange include a pfs keyword that you can enable, although you need to ensure that the same options are enabled on both peers.
One of the most effective ways of managing large numbers of keys is to implement a Public Key Infrastructure (PKI), which is a paradigm that uses digital certificates to verify the validity of public encryption and authentication keys. They generally use a Certification Authority (CA), which is a trusted server that knows the public encryption keys for a large number of devices.
IPSec uses two important security protocols, the Authenticating Header (AH), and the Encapsulating Security Payload (ESP). These do pretty much what their names suggest. AH includes a cryptographic authentication scheme in the header of the IP packet, which allows you to ensure that the data has not been tampered with in any way, and that it really does come from the right source device. ESP, on the other hand, encrypts the packet’s payload for privacy. We recommend that if you are using IPSec, you should use both AH and ESP together. Authentication and encryption clearly serve entirely different but complementary functions, but we believe it is rare to have data that is important enough to warrant implementing either authentication or encryption but not both.
One of the main authentication methods for IPSec makes use of a cryptographic hash function. Hash functions are actually more common than you might think. The simple Cyclic Redundancy Checksum (CRC) field in a packet is essentially just a hash function. The general definition of a hash function is an algorithm that takes a message of arbitrary length and produces an output of fixed length. This output is often called a message digest.
To be useful for authentication, this hash function must make it extremely difficult to generate a two distinct messages that have the same message digest. There are several of these hash functions in existence. The most popular for use with IPSec are Message Digest Version 5 (MD5) and Secure Hash Algorithm (SHA). We have already discussed MD5 in another setting, when we talked about how Cisco routers store passwords internally in Chapter 3. Cryptographic hash functions make excellent password crypts, because the result is always the same length and almost impossible to reverse. If the algorithm is strong, the only way to decrypt the original password is to encrypt a series of systematic guesses and see if any of them match the unknown encrypted string.
The National Institute of Standards and Technology (NIST) developed the SHA as an improvement over MD5. It is generally believed that SHA is somewhat more secure than MD5, although it is a little bit more CPU intensive.
IPSec uses these hash functions to create Hashed Message Authentication Codes (HMAC). The HMAC is effectively an irreversible cryptographic hash function of an original message that has been combined in a nontrivial way with a password. So you need to not only break the hash algorithm, but also the password to reconstruct the original message.
For the actual data encryption, IPSec again offers several different options. Cisco routers only implement 56-bit and 168-bit Data Encryption Standard (DES) encryption. The 56-bit version of DES is the default, while the 168-bit version is often called Triple DES, and has export restrictions outside of North America.
People have developed several other encryption algorithms for use with IPSec. One of the most popular is called Blowfish. This is an unpatented and freely distributable encryption algorithm that is faster than standard DES, and believed to be more secure as well. Other encryption algorithms include International Data Encryption Algorithm (IDEA), CAST-256, and Skipjack. However, Cisco implements only DES and Triple DES.
IPSec has two main modes of operation: tunnel mode and transport mode. In this chapter we will discuss examples of both. Tunnel mode essentially means that IPSec is responsible for operating its own tunnel. IPSec tunnels are modeled on the IP-in-IP tunnel protocol, which we mentioned earlier. As a result, any IPSec exchanges that use transport mode must be purely between the two end devices, while tunnel mode can support routing from devices that are further downstream. In Recipe 12.3, we will show an example where transport mode is used to encrypt traffic in a GRE tunnel. In this case, the GRE traffic always begins and ends on the routers themselves, although the payload of the GRE packets may contain IP packets routed from other downstream devices. Recipe 12.6, on the other hand, shows an example of tunnel mode. In this case, a remote workstation initiates the IPSec connection to the router. But the packets that this workstation sends are destined for end devices on the other side of the router. So tunnel mode is appropriate here.
By default, Cisco routers will use IPSec in tunnel mode. This is because IPSec needs a well-defined starting and ending point for the encryption. So, with transport mode, the source and destination IP addresses must be fixed somehow. This effectively means that transport mode needs to operate inside of another tunnel protocol such as GRE if it is to carry user traffic between routers.
12.1. Creating a Tunnel
Solution
The basic GRE tunnel configuration is simply a matter of defining the source and destination addresses or interfaces on both devices. On the first router you need to create the tunnel interface, and define its source and destination:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface TunnelRouter1(config-if)#1ip addressRouter1(config-if)#192.168.35.6 255.255.255.252tunnel sourceRouter1(config-if)#172.25.1.5tunnel destinationRouter1(config-if)#172.25.1.7endRouter1#
Then, on the other router, you must create a tunnel interface with a matching source and destination:
Router5#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router5(config)#interface TunnelRouter5(config-if)#3ip addressRouter5(config-if)#192.168.35.5 255.255.255.252tunnel sourceRouter5(config-if)#172.25.1.7tunnel destinationRouter5(config-if)#172.25.1.5endRouter5#
Discussion
Creating a basic tunnel is very simple, you just need to define a source and destination on each of two routers. As with any other virtual interface such as subinterfaces or loopback interfaces, a tunnel has an additional memory requirement on the router. However, the CPU overhead is not as bad as you might initially think. This is because GRE tunnels do work well with Cisco Express Forwarding (CEF). So the main scaling issue in creating tunnels on routers is the memory required to support them.
The only tricky part of configuring a tunnel is making sure that the source of the tunnel on one router matches the destination on the other. In this case Router1 uses a source IP address of 172.25.1.5, which happens to be its Ethernet port. If you look at the tunnel destination command on the other router, you will see that it matches. Similarly, the destination on the first router is 172.25.1.7, and the source is 172.25.1.5.
You could also use an alternative syntax, specifying the interface name rather than the IP address:
Router5(config)#interface TunnelRouter5(config-if)#3tunnel sourceEthernet0
This points the tunnel source to the primary IP address on a particular interface on this router. It is crucial that this IP address must match the destination address configured on the other router.
If you then look at the new tunnel interface, you will see that it is up:
Router1#show interfaces tunnel1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.35.6/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 172.25.1.5 (FastEthernet0), destination 172.25.1.7
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input 00:11:08, output 00:00:08, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
5 packets input, 740 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
73 packets output, 6604 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Router1#This is deceptive, though. Even if we remove the tunnel configuration from the other router, this interface will still appear to be up. Indeed, this tunnel interface will appear to be up even if you turn off the power on the far end router. In IOS Version 12.2(8)T, Cisco introduced a new keepalive option for GRE tunnels that overcomes this limitation. When you configure a tunnel with this new feature, the interface will go down if there are any connection problems:
Router1(config)#interface TunnelRouter1(config-if)#1keepalive
By default, this keepalive command sends a packet through the tunnel to check its status once every 10 seconds. If there is no response to three successive polls, the router declares the tunnel interface to be down. So, this will change the tunnel’s status about 30 seconds after a failure.
You can adjust both the time interval and the number of retries. For example, to send a keepalive packet every five seconds, but to keep the default three retry limit, you could use the following command:
Router1(config)#interface TunnelRouter1(config-if)#1keepalive 5
If you want to change the number of retries, you can specify the new value after the time interval. The following example will send a keepalive packet every three seconds, and will declare the tunnel down if it doesn’t hear a response back to two successive keepalive tests:
Router1(config)#interface TunnelRouter1(config-if)#1keepalive 3 2
If you are concerned about the integrity of tunneled data, you can enable checksums on a GRE tunnel:
Router1(config)#interface TunnelRouter1(config-if)#1tunnel checksum
When you turn on checksums, the router will verify the checksum of every GRE packet it receives and drop any packets that don’t match. A similar feature checks to see if packets are received in the correct order:
Router1(config)#interface TunnelRouter1(config-if)#1tunnel sequence-datagrams
When you enable the sequence-datagrams option, the router will drop any packets that it receives out of their correct order. These two options can be useful in networks that have a tendency to damage packets, or where there are multiple paths between the tunnel routers. Remember that GRE doesn’t use TCP, so these features can help to improve the reliability of a tunnel connection. However, even when you enable these features, the routers will not resend dropped packets (as TCP does).
We do suggest using some caution when you enable either checksums or sequencing on a GRE tunnel, because these features do not work with CEF. So, as soon as you enable either of them, the router will have to resort to process switching, which could drive up your CPU utilization.
The tunnel in the recipe didn’t specify a particular tunnel protocol, so the routers will use the default GRE protocol. If you prefer to use a different tunnel protocol, you can change it using the tunnel mode command as follows:
Router1(config)#interface TunnelRouter1(config-if)#1tunnel mode ipip
Here we have opted to use the IP-in-IP tunnel protocol that we discussed in the introduction to this chapter. There are several other options for tunnel protocols, which we list in Table 12-1.
In the recipe example, the two routers shared an Ethernet segment, so the routing was trivial. But, in practice, routing between the tunnel end points is often the most difficult thing to get right. The problem, which we will discuss more in Recipe 12.3, is that the tunnel itself is only one routing hop for packets that travel through it, although it might be several physical hops. As a result, the routing protocol will often decide that the best way to get to the tunnel’s destination IP address is through the tunnel itself. This is called recursive routing, and it makes the tunnel useless. So, when a router notices that it is routing GRE packets for a tunnel destination address through the same tunnel, it will automatically disable the tunnel with the following error message:
Jan 16 12:05:04 EST: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing Jan 16 12:05:05 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
Cisco has attempted to reduce this problem by making the default bandwidth for all tunnel interfaces 9Kbps. For most routing protocols, this means that you have to traverse several hops before the tunnel looks like a better path. But some protocols, most notably RIP, don’t look at interface bandwidths. It is important to bear in mind that, no matter what protocol you use, at some point a single hop of 9Kbps is going to look better than a large number of higher bandwidth hops.
The only way to avoid this problem is to ensure that there is always a good route to the tunnel destination that doesn’t use the tunnel itself. This is most easily accomplished using static routes, although we will discuss other techniques in Recipe 12.3.
See Also
12.2. Tunneling Foreign Protocols in IP
Solution
One of the most important applications of tunnels is for passing foreign protocols through a network that only supports IP. A typical example of this would be IPX, although the configuration is similar for other protocols such as AppleTalk:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#ipx routingRouter1(config)#AAAA.BBBB.0001interface TunnelRouter1(config-if)#1ipx networkRouter1(config-if)#AAAtunnel sourceRouter1(config-if)#172.25.1.5tunnel destinationRouter1(config-if)#172.25.1.7endRouter1#
Then, on the other router, you must create a tunnel interface with a matching source and destination as well as matching IPX network number:
Router5#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router2(config)#ipx routingRouter5(config)#AAAA.BBBB.0002interface TunnelRouter5(config-if)#3ipx networkRouter5(config-if)#AAAtunnel sourceRouter5(config-if)#172.25.1.7tunnel destinationRouter5(config-if)#172.25.1.5endRouter5#
Discussion
This recipe is nearly identical to Recipe 12.1, but instead of tunneling IP traffic through an IP network, we use the same kind of tunnel to pass IPX traffic through the same network. Note that of all the supported tunnel modes mentioned in Table 12-1, only the default GRE will transport IPX (although there are several AppleTalk tunnel modes).
This book does not cover IPX, so we won’t go into any detail on the IPX-specific commands here. This is merely intended as an example of how to use GRE tunnels for foreign protocols. For more information on IPX, please refer to Designing Large-Scale LANs (O’Reilly).
To enable IPX on both of these routers, you have to first make sure that you are running an IOS release that supports IPX. The various “Desktop” IOS versions support this protocol, as do the “Enterprise” versions. Please consult the Cisco IOS feature matrixes for more details. Assuming, then, that your router supports IPX, you can enable it with the ipx routing command, as shown. Naturally, you need to enable IPX routing on both routers. Then, the only other important detail is to configure both ends of the GRE tunnel with matching IPX network numbers as we have done in the example.
It’s important to note that you can configure a GRE tunnel to support more than one protocol by simply specifying appropriate network numbers for each protocol using the tunnel. We could, for example, add IP to this IPX tunnel by simply configuring an IP address on both ends, as we did in Recipe 12.1. The tunnel will then support both protocols simultaneously:
Router1(config)#interface TunnelRouter1(config-if)#1ip addressRouter1(config-if)#192.168.35.6 255.255.255.252ipx networkRouter1(config-if)#AAAtunnel sourceRouter1(config-if)#172.25.1.5tunnel destinationRouter1(config-if)#172.25.1.7endRouter1#
See Also
Recipe 12.1; Designing Large-Scale LANs, by Kevin Dooley (O’Reilly)
12.3. Tunneling with Dynamic Routing Protocols
Solution
Dynamic routing and tunnels can be a dangerous combination. It is critical to ensure that the routers never get confused and think that the best path to the tunnel destination is through the tunnel itself. We offer three different ways of resolving this problem.
The first is to use static routes for the tunnel destination address:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface TunnelRouter1(config-if)#1ip addressRouter1(config-if)#192.168.35.6 255.255.255.252tunnel sourceRouter1(config-if)#172.25.1.5tunnel destinationRouter1(config-if)#172.22.1.2exitRouter1(config)#ip routeRouter1(config)#172.22.1.2 255.255.255.255 172.25.1.1router eigrpRouter1(config-router)#55networkRouter1(config-router)#192.168.35.0endRouter1#
The second method simply excludes the tunnel’s IP address range from the routing protocol. You can then run a different routing protocol for the addresses that you want to pass through the tunnel:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface TunnelRouter1(config-if)#1ip addressRouter1(config-if)#192.168.35.6 255.255.255.252tunnel sourceRouter1(config-if)#172.25.1.5tunnel destinationRouter1(config-if)#172.22.1.2exitRouter1(config)#router eigrpRouter1(config-router)#55networkRouter1(config-router)#172.22.0.0networkRouter1(config-router)#172.25.0.0endRouter1(config)#router ripRouter1(config-router)#networkRouter1(config-router)#192.168.35.0endRouter1#
The third solution is to filter the routes of the supporting network to prevent them from passing through the tunnel:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface TunnelRouter1(config-if)#1ip addressRouter1(config-if)#192.168.35.6 255.255.255.252tunnel sourceRouter1(config-if)#172.25.1.5tunnel destinationRouter1(config-if)#172.22.1.2exitRouter11(config)#ip prefix-listRouter1(config)#TUNNELROUTESseq 10 permit192.168.0.0/16 ge 17router eigrpRouter1(config-router)#55networkRouter1(config-router)#172.22.0.0networkRouter1(config-router)#172.25.0.0networkRouter1(config-router)#192.168.35.0distribute-list prefixRouter1(config-router)#TUNNELROUTESoutTunnel1endRouter1#
Discussion
As we mentioned in Recipe 12.1, you have to be careful when using a dynamic routing protocol anywhere near a GRE tunnel to avoid the dreaded recursive routing error message, which brings down the tunnel. This happens because the routers need to have a good path through the network to carry the tunnel to its destination. In addition, this path cannot go through the tunnel itself. But the problem is that, because the tunnel forms a virtual connection that directly connects two routers, the path through the tunnel is almost always shorter than any path that goes through the real physical network.
The other way to look at the problem of recursive routing is to think about what the router has to do to a packet that it wants to send through the tunnel. It wraps this packet in the payload of a GRE packet and it puts the tunnel’s destination address in the header of this GRE packet. Then it looks in its routing table to find out where to send this packet. If it finds that the best path is through the tunnel, then it must take this GRE packet and wrap it in the payload of a GRE packet whose destination address is the tunnel destination, and so on. This makes it difficult to deliver the original packet, so the router shuts down the tunnel interface to avoid having to stuff an infinite number of GRE headers onto the front of the packet.
There are two extremely simple solutions to this problem, but they aren’t always applicable. You can use static routes to connect to the tunnel destination, which allows you to force the tunnel traffic to go the right way. Or you can prevent the routing protocol from passing through the tunnel either by using a separate IP address range or access lists. These two options are the first two examples in the solutions section of this recipe.
Note that we have used a specific host route for the destination IP address to ensure that it always uses the right path:
Router1(config)#ip route 172.22.1.2 255.255.255.255 172.25.1.1The problem with this solution is that it might eliminate some of your network redundancy. For example, if there are several paths to the router that hold the tunnel’s destination, using a static route like this might mean that your tunnel will fail if there is a topology change in the network that affects the manually selected path. In many cases, you can get around this problem by pointing the static route at a carefully selected downstream destination address. But then you run the risk that the router will learn about this downstream destination address through the tunnel, in which case we’re back at square one.
The second simple solution is to simply exclude the tunnel from your routing protocol. In the example, we gave the tunnel an IP address that doesn’t belong to the same address range as the source or destination addresses. This makes excluding the tunnel from the routing protocol relatively easy. By simply not including the 192.168.35.0/24 network in any of the EIGRP network commands, we prevent the tunnel from taking part in the routing protocol. We could also exclude the interface from the routing protocol using a distribute list. Please see Chapter 7 for more information about these EIGRP features.
However, sometimes these simple solutions are not appropriate. Some network topologies require that you use a routing protocol both inside and outside of the tunnel. For example, if you use VPNs to construct your WAN, through either a private or a public IP network, you will probably have to have both.
The best way to approach this type of situation is to start by ensuring that the ranges of IP addresses are distinct. For example, if the network that supports the tunnel uses public addressing, you could use private addressing for routes that need to be learned through the tunnel. Then you can apply a filter to prevent the routes for the supporting network from passing through the tunnel.
There are two ways to accomplish this. One is simply to use distinct routing protocols inside and outside of the tunnel, and not redistribute between the protocols. For example, the routing protocol outside of the tunnel could be BGP, while the tunneled network uses OSPF or EIGRP through the tunnel, or EIGRP and RIP as in the example above.
But another method is necessary if the two sets of routes use the same routing protocol, or if you need to redistribute. With distance vector–type interior routing protocols such as EIGRP and RIP, you can apply a route distribution filter to the tunnel interface to block the supporting network’s routes. Note that EIGRP is much more sophisticated than a simple distance vector protocol like RIP. But this kind of route filtering is not possible with link state protocols such as OSPF, so this is one place where EIGRP’s distance vector roots come in handy.
In the example, we have shown how to do route filtering using a prefix list with EIGRP. This will permit only the 192.168.0.0/16 range of IP addresses to pass through the tunnel, while information about the 172.22.0.0/16 and 172.25.0.0/16 networks that form the support network is never learned through the tunnel. You should apply this type of filter to both ends of the tunnel:
Router11(config)#ip prefix-listRouter1(config)#TUNNELROUTESseq 10 permit192.168.0.0/16 ge 17router eigrpRouter1(config-router)#55networkRouter1(config-router)#172.22.0.0networkRouter1(config-router)#172.25.0.0distribute-list prefixTUNNELROUTESoutTunnel1
For more information on EIGRP route distribution filters, please see Chapter 7. For more information on prefix lists, you can refer to either Chapter 7 or Chapter 9.
See Also
Recipe 12.1; Chapters Chapter 7 and Chapter 9
12.4. Viewing Tunnel Status
Solution
You can look at the attributes for a tunnel with the show interface command:
Router1#show interface Tunnel5The easiest way to determine if a tunnel is operational is simply to use a ping test to either the send ICMP packets through the tunnel or to its destination address:
Router1#pingRouter1#192.168.66.6ping172.22.1.4
Discussion
You can use the standard show interface command on a tunnel interface to see a considerable amount of useful information about it:
Router1#show interface Tunnel5
Tunnel5 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.66.5/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 172.25.1.3, destination 172.25.1.4
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input 1d19h, output 00:00:06, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 79
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2536 packets input, 1386605 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
23235 packets output, 2036436 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Router1#As you can see from this output, the show interface command tells you what the tunnel’s source and destination IP addresses are. You can see the input and output rate, as well as the total number of packets and bytes both sent and received on this tunnel interface. The output also shows that we are using the default GRE tunnel protocol and not enabled checksums or keepalives on this tunnel.
There is only one serious problem with this output. Because we have not enabled keepalives, we discussed in Recipe 12.1, the show interface command will almost always show the tunnel interface as being in an up state. As we mentioned in Recipe 12.1, the router will temporarily bring the tunnel interface down in response to recursive routing situations, and you can also use the shutdown command to disable a tunnel as you would with any other interface. However, usually the tunnel interface will appear to be in an up state, even if the router can’t reach the tunnel destination router.
If you are running an IOS level that supports keepalives on tunnels, you can enable that feature. Then the show interface command will give a more realistic view of the tunnel’s status. But, without that feature, the easiest way to see if a tunnel is working is to simply ping through it:
Router1#ping 192.168.66.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.66.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/20 ms
Router1#Alternatively, you can ping the destination IP address of the tunnel:
Router1#ping 172.22.1.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.66.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/20 ms
Router1#See Also
12.5. Creating an Encrypted Router-to-Router VPN
Problem
You want to create an encrypted VPN through the Internet connecting two routers using pre-shared keys.
Solution
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 terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#crypto isakmp policyRouter1(config-isakmp)#10encryption 3desRouter1(config-isakmp)#authentication pre-shareRouter1(config-isakmp)#groupRouter1(config-isakmp)#2exitRouter1(config)#crypto isakmp keyRouter1(config)#TUNNELKEY01address172.22.1.4no-xauthcrypto ipsec transform-setTUNNEL-TRANSFORMah-sha-hmac esp-3des esp-sha-hmacRouter1(cfg-crypto-trans)#mode transportRouter1(cfg-crypto-trans)#exitRouter1(config)#crypto mapRouter1(config-crypto-map)#TUNNELMAP 10ipsec-isakmpset peerRouter1(config-crypto-map)#172.22.1.4set transform-setRouter1(config-crypto-map)#TUNNEL-TRANSFORMmatch addressRouter1(config-crypto-map)#116exitRouter1(config)#access-listRouter1(config)#116permit gre host172.22.1.3host172.22.1.4interfaceRouter1(config-if)#Tunnel5ip addressRouter1(config-if)#192.168.66.5 255.255.255.252tunnel sourceRouter1(config-if)#172.22.1.3tunnel destinationRouter1(config-if)#172.22.1.4exitRouter1(config)#interfaceRouter1(config-if)#FastEthernet0/1ip addressRouter1(config-if)#172.22.1.3 255.255.255.0crypto mapRouter1(config-if)#TUNNELMAPendRouter1#
Here is the corresponding configuration for the other router:
Router2#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router2(config)#crypto isakmp policyRouter2(config-isakmp)#10encryption 3desRouter2(config-isakmp)#authentication pre-shareRouter2(config-isakmp)#groupRouter2(config-isakmp)#2exitRouter2(config)#crypto isakmp keyRouter2(config)#TUNNELKEY01address172.22.1.3no-xauthcrypto ipsec transform-setTUNNEL-TRANSFORMah-sha-hmac esp-3des esp-sha-hmacRouter2(cfg-crypto-trans)#mode transportRouter2(cfg-crypto-trans)#exitRouter2(config)#crypto mapRouter2(config-crypto-map)#TUNNELMAP 10ipsec-isakmpset peerRouter2(config-crypto-map)#172.22.1.3set transform-setRouter2(config-crypto-map)#TUNNEL-TRANSFORMmatch addressRouter2(config-crypto-map)#116exitRouter2(config)#access-listRouter2(config)#116permit gre host172.22.1.4host172.22.1.3interfaceRouter2(config-if)#Tunnel5ip addressRouter2(config-if)#192.168.66.6 255.255.255.252tunnel sourceRouter2(config-if)#172.22.1.4tunnel destinationRouter2(config-if)#172.22.1.3exitRouter2(config)#interfaceRouter2(config-if)#FastEthernet1/0ip addressRouter2(config-if)#172.22.1.4 255.255.255.0crypto mapRouter2(config-if)#TUNNELMAPendRouter2#
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 highest priority and goes to the lowest. The highest possible priority value is 10,000:
Router1(config)#crypto isakmp policyRouter1(config-isakmp)#10encryption 3desRouter1(config-isakmp)#authentication pre-shareRouter1(config-isakmp)#group2
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 limitWe could have also adjusted the hash algorithm and the lifetime of a particular SA as follows:
Router1(config)#crypto isakmp policyRouter1(config-isakmp)#20hash md5Router1(config-isakmp)#lifetime600
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-xauthAs 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-xauthHowever, 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 hostnameWe 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.25.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.25.1.4 172.25.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 isakmpRouter1#1show crypto isakmp sadst src state conn-id slot 172.25.1.4 172.25.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-setTUNNEL-TRANSFORMah-sha-hmac esp-3des esp-sha-hmacRouter1(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 transportBy 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 Chapters 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 mapRouter1(config-crypto-map)#TUNNELMAP 10ipsec-isakmpset peerRouter1(config-crypto-map)#172.22.1.4set transform-setRouter1(config-crypto-map)#TUNNEL-TRANSFORMmatch addressRouter1(config-crypto-map)#116exitRouter1(config)#access-list116permit gre host172.22.1.3host172.22.1.4
The crypto map defines an IPSec peer device by its IP address. If you are using host-names 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.3Then, 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)#interfaceRouter1(config-if)#Tunnel5ip addressRouter1(config-if)#192.168.66.5 255.255.255.252tunnel sourceRouter1(config-if)#172.22.1.3tunnel destinationRouter1(config-if)#172.22.1.4exitRouter1(config)#interfaceRouter1(config-if)#FastEthernet0/1ip addressRouter1(config-if)#172.22.1.3 255.255.255.0crypto mapTUNNELMAP
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.25.1.4 set HMAC_SHA+3DES_56_C 0 0
2002 FastEthernet1/0 172.25.1.4 set HMAC_SHA+3DES_56_C 0 407
2003 FastEthernet1/0 172.25.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.
See Also
12.6. Generating RSA Keys
Solution
First, you must create the keys on both devices. We recommend using at least 1024-bit keys in production networks:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#crypto key generate rsaThe name for the keys will be: Router1.oreilly.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]:Generating RSA keys ... [OK] Router1(config)#1024endRouter1#show crypto key mypubkey rsa% Key pair was generated at: 01:19:45 EST Mar 1 2003 Key name: Router1.oreilly.com Usage: General Purpose Key Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00E68338 D561B2D1 7B8B75D6 7B34F6AF 1710B00B 5B6E9E8D D7183BE6 F08A6342 054EADFC B764DF9C 4592B891 522727F2 14233B47 8F757134 24F03DB3 833C5988 312B11E9 FB6E0E20 4579C0A4 F2062353 4F1C8CE4 410EE57B 9FCEE784 DA7E3852 408E9742 2584DF56 67293F3F F76B6A96 C4D518FB 1A0114BF E2449838 BE5794E2 37020301 0001 % Key pair was generated at: 01:19:52 EST Mar 1 2003 Key name: Router1.oreilly.com.server Usage: Encryption Key Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00BD928A BD5637E6 2265621C 3AC57138 911CA27D 11F40AA1 E657EA26 6EBF654C 952A3319 D421A33C E2ECA87E CD7E050C 8A8FE64D B73954EA BF2ED639 BC6A8F74 5B9550EA 4119E796 A97430E2 4B1BF7D3 ED1469FF AEA83690 A0FEA871 BBFBE8AD 19020301 0001 Router1#
Then you can use cut and paste to copy this manually generated key into the other device:
Router2#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router2(config)#crypto key pubkey-chain rsaRouter2(config-pubkey-chain)#addressed-keyRouter2(config-pubkey-key)#192.168.99.1addressRouter2(config-pubkey-key)#192.168.99.1key-stringEnter a public key as a hexidecimal number .... Router2(config-pubkey)#30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181Router2(config-pubkey)#00E68338D561B2D1 7B8B75D6 7B34F6AF 1710B00B 5B6E9E8D D7183BE6 F08A6342Router2(config-pubkey)#054EADFCB764DF9C 4592B891 522727F2 14233B47 8F757134 24F03DB3 833C5988Router2(config-pubkey)#312B11E9FB6E0E20 4579C0A4 F2062353 4F1C8CE4 410EE57B 9FCEE784 DA7E3852Router2(config-pubkey)#408E97422584DF56 67293F3F F76B6A96 C4D518FB 1A0114BF E2449838 BE5794E2Router2(config-pubkey)#37020301 0001quitRouter2(config-pubkey-key)#exitRouter2(config-pubkey-chain)#exitRouter2(config)#endRouter2#show crypto key pubkey-chain rsa addressKey address: 192.168.99.1 Usage: General Purpose Key Source: Manually entered Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00E68338 D561B2D1 7B8B75D6 7B34F6AF 1710B00B 5B6E9E8D D7183BE6 F08A6342 054EADFC B764DF9C 4592B891 522727F2 14233B47 8F757134 24F03DB3 833C5988 312B11E9 FB6E0E20 4579C0A4 F2062353 4F1C8CE4 410EE57B 9FCEE784 DA7E3852 408E9742 2584DF56 67293F3F F76B6A96 C4D518FB 1A0114BF E2449838 BE5794E2 37020301 0001 Router2#192.168.99.1
Discussion
When you use the crypto key generate command to create new keys, the router must delete any existing keys:
Router1(config)#crypto key generate rsaThe name for the keys will be: Router1.oreilly.com % You already have RSA keys defined for Router1.oreilly.com. % Do you really want to replace them? [yes/no]:yesChoose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]:Generating RSA keys ... [OK] Router1(config)#1024
During key generation, any services on the router that is currently using these keys will be temporarily disabled. Key generation can take a considerable length of time, depending on the model of router and the size of the key modulus. We have seen a low-end access router take as long as an hour to generate a key with a very large modulus for greater security. During this time, the router’s CPU load was extremely high. So we urge caution when using this command.
You can remove existing keys with the crypto key zeroize command:
Router1(config)#crypto key zeroize rsa% Keys to be removed are named Router1.oreilly.com. Do you really want to remove these keys? [yes/no]:yesRouter1(config)#
If the router has any services that are using the deleted keys, it will automatically disable them until you generate new keys.
You can also generate special usage keys as follows:
Router1(config)#crypto key generate rsa usage-keysThe name for the keys will be: Router1.oreilly.com % You already have RSA keys defined for Router1.oreilly.com. % Do you really want to replace them? [yes/no]:yesChoose the size of the key modulus in the range of 360 to 2048 for your Signature Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]:Generating RSA keys ... [OK] Choose the size of the key modulus in the range of 360 to 2048 for your Encryption Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]:1024Generating RSA keys ... [OK] Router1(config)#1024
This command creates separate authentication signature and encryption keys. You can look at the public keys with the show crypto key command:
Router1#show crypto key mypubkey rsa
% Key pair was generated at: 01:29:04 EST Mar 1 2003
Key name: Router1.oreilly.com
Usage: Signature Key
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00AAED98
0E454C8F ED9DB93E 312B00BD FF561C49 5480344A 094F0EA8 0D994051 AC627CF2
5FA7F802 DB0A1206 4EB8F8E5 122C9B2D 0F3A20D8 C0E90280 D4F6518A 9C6C2E48
A570D05A AE2881CA B9366990 931C4A7E EDC6B352 13815B91 3A02B44E 4655DE6D
1CB5AB35 058B60AA 4639B696 A8EE735E DA15B300 B8A0CE51 7C42B73A 53020301 0001
% Key pair was generated at: 01:29:11 EST Mar 1 2003
Key name: Router1.oreilly.com
Usage: Encryption Key
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00D18F99
EC2A5754 C1FEF911 E16BFD80 6C3E9517 42716B78 99692618 B57B529B A9C19B23
6D4BF3CE 39728DEF 2B3D10F9 3DABBDFD 8CAB09F7 0A56768C 053BB4AF 7F224E44
FA341851 10152A86 28C2084F C13E0738 4C478BED 9960E229 CB112077 097F3DC9
DD40D109 0A513D31 FF0FD51D B3515CEA F81738B6 5BB02FF6 812A01AC F7020301 0001
% Key pair was generated at: 01:29:14 EST Mar 1 2003
Key name: Router1.oreilly.com.server
Usage: Encryption Key
Key Data:
307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B43311 D047EFBC
314C57DB 93F3E755 5CEBF4B5 D0258169 6DAC695B A0F5DA35 C6C7B106 C2BB7863
0201B68A 7C2F3313 47223065 BDF84692 BF974F2E E4037D5D C976DB3A 231D2603
6DE8CDCE 8EAD613E 5C984091 55A6B0F5 920E285B 6E4ED34E 31020301 0001
Router1#As you can see, the router now has a signature key and an encryption key where it previously had only a general purpose key. However, it is important to remember that this is only the public key. There is also a corresponding private key that you cannot view on the router. The router keeps this key in its NVRAM storage and sets file permissions so nobody can read it. The private key is what the router uses to encrypt things that it sends. The public key can decrypt anything encrypted with the private key. Every device that this router shares encrypted information with will need a copy of the public key, but the private key is secret.
As a side effect of this, the public key provides an excellent authentication system. If the device’s public key successfully decrypts a message, then you know that this message must have been encrypted with that device’s private key. And, consequently, if the private key really is private, the message must actually have been sent by that device.
When you use these keys on routers, we highly recommend using the cut-and-paste feature on your terminal, rather than trying to type all of this in manually. A single typographical error in this sequence will make the key useless. Note, however, that there is an inherent security risk in copying and pasting a key like this over a network. If you are using an insecure protocol like Telnet, the packet can be intercepted, and the key information is easily extracted. So you should avoid doing this over untrusted networks.
In Recipe 12.7 we will show an example of how to use RSA keys.
See Also
12.7. Creating a Router-to-Router VPN with RSA Keys
Solution
As in Recipe 12.3, we will use IPSec transport mode and a GRE tunnel for this encrypted router-to-router connection:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#crypto key pubkey-chain rsaRouter1(config-pubkey-chain)#addressed-keyRouter1(config-pubkey-key)#172.22.1.4addressRouter1(config-pubkey-key)#172.22.1.4key-stringEnter a public key as a hexidecimal number .... Router1(config-pubkey)#305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00B8120CRouter1(config-pubkey)#AC2C5AACADAD378D A5A1F140 2EB9A66A DD6FF2A9 7DD47692 5CDE4732 E2C9EDDARouter1(config-pubkey)#52809BE0D60A5A34 CDD7DC31 DA7F9590 849F142E 26C6F130 0A2E4491 65020301Router1(config-pubkey)#0001quitRouter1(config-pubkey-key)#exitRouter1(config-pubkey-chain)#exitRouter1(config)#crypto isakmp policyRouter1(config-isakmp)#100encryption 3desRouter1(config-isakmp)#authentication rsa-encrRouter1(config-isakmp)#groupRouter1(config-isakmp)#2exitRouter1(config)#crypto ipsec transform-setTUNNEL-TRANSFORMah-sha-hmac esp-3des esp-sha-hmacRouter1(cfg-crypto-trans)#mode transportRouter1(cfg-crypto-trans)#exitRouter1(config)#crypto mapRouter1(config-crypto-map)#TUNNEL-RSA 10ipsec-isakmpset peerRouter1(config-crypto-map)#172.22.1.4set transform-setRouter1(config-crypto-map)#TUNNEL-TRANSFORMmatch addressRouter1(config-crypto-map)#116exitRouter1(config)#access-listRouter1(config)#116permit gre host172.22.1.3host172.22.1.4interfaceRouter1(config-if)#Tunnel5ip addressRouter1(config-if)#192.168.66.5 255.255.255.252tunnel sourceRouter1(config-if)#172.22.1.3tunnel destinationRouter1(config-if)#172.22.1.4exitRouter1(config)#interfaceRouter1(config-if)#FastEthernet0/1ip addressRouter1(config-if)#172.22.1.3 255.255.255.0crypto mapRouter1(config-if)#TUNNEL-RSAendRouter1#
Here is the corresponding configuration for the other router:
Router2#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router2(config)#crypto key pubkey-chain rsaRouter2(config-pubkey-chain)#addressed-keyRouter2(config-pubkey-key)#172.22.1.3addressRouter2(config-pubkey-key)#172.22.1.3key-stringEnter a public key as a hexidecimal number .... Router2(config-pubkey)#305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00DA2810Router2(config-pubkey)#6627212B7234CC4A 91BCB4CC 7985AD4B 884E4653 9E533422 A34A4011 E7402B56Router2(config-pubkey)#7DCE7A337407C6DE 995D2EBD E9F2C29D B4EEB962 61B9CF3B 05D903FC 57020301Router2(config-pubkey)#0001quitRouter2(config-pubkey-key)#exitRouter2(config-pubkey-chain)#exitRouter2(config)#crypto isakmp policyRouter2(config-isakmp)#100encryption 3desRouter2(config-isakmp)#authentication rsa-encrRouter2(config-isakmp)#groupRouter2(config-isakmp)#2exitRouter2(config)#crypto ipsec transform-setTUNNEL-TRANSFORMah-sha-hmac esp-3des esp-Router2(cfg-crypto-trans)#sha-hmacmode transportRouter2(cfg-crypto-trans)#exitRouter2(config)#crypto mapRouter2(config-crypto-map)#TUNNEL-RSA 10ipsec-isakmpset peerRouter2(config-crypto-map)#172.22.1.3set transform-setRouter2(config-crypto-map)#TUNNEL-TRANSFORMmatch addressRouter2(config-crypto-map)#116exitRouter2(config)#access-listRouter2(config)#116permit gre host172.22.1.4host172.22.1.3interfaceRouter2(config-if)#Tunnel5ip addressRouter2(config-if)#192.168.66.6 255.255.255.252tunnel sourceRouter2(config-if)#172.22.1.4tunnel destinationRouter2(config-if)#172.22.1.3exitRouter2(config)#interfaceRouter2(config-if)#FastEthernet1/0ip addressRouter2(config-if)#172.22.1.4 255.255.255.0crypto mapRouter2(config-if)#TUNNEL-RSAendRouter2#
Discussion
This recipe is similar to 12.3, except that here we use RSA keys for authentication and encryption instead of pre-shared keys. This technique is more secure but more time consuming to configure.
The first step is to create a set of RSA encryption keys using the methods discussed in Recipe 12.6. We took the keys that we generated in this way and entered them into the router configurations. So, for example, we created the key on Router1 as follows:
Router1(config)#crypto key generate rsaThe name for the keys will be: Router1.oreilly.com % You already have RSA keys defined for Router1.oreilly.com. % Do you really want to replace them? [yes/no]:yesChoose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: Generating RSA keys ... [OK] Router1(config)#exitRouter1#show crypto key mypubkey rsa% Key pair was generated at: 11:25:55 EST Jan 26 2003 Key name: Router1.oreilly.com Usage: General Purpose Key Key Data: 305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00DA2810 6627212B 7234CC4A 91BCB4CC 7985AD4B 884E4653 9E533422 A34A4011 E7402B56 7DCE7A33 7407C6DE 995D2EBD E9F2C29D B4EEB962 61B9CF3B 05D903FC 57020301 0001 % Key pair was generated at: 11:26:01 EST Jan 26 2003 Key name: Router1.oreilly.com.server Usage: Encryption Key Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A3603A 58941769 EF93B43D C89AC7CF 2A6DA0D5 F72BCFF8 D9EEDDD2 B0CE9A8E B4BAFD2D 805A4D8F 969A5AE3 5F4F8252 744A0834 B4BA24B9 BC7E4522 2345F081 587BD1A8 309B03F4 A70F2373 2AB6CEE5 736F6D61 F64A94A6 30CE253F BEB8330B FF020301 0001 Router1#
Note that in this example we used the default 512-bit key. However, in production networks, we recommend using 1024-bit keys or higher.
Then we took the general purpose key from this output and entered it into the other router as follows:
Router2(config)#crypto key pubkey-chain rsaRouter2(config-pubkey-chain)#addressed-keyRouter2(config-pubkey-key)#172.22.1.3addressRouter2(config-pubkey-key)#172.22.1.3key-stringEnter a public key as a hexidecimal number .... Router2(config-pubkey)#305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00DA2810Router2(config-pubkey)#6627212B7234CC4A 91BCB4CC 7985AD4B 884E4653 9E533422 A34A4011 E7402B56Router2(config-pubkey)#7DCE7A337407C6DE 995D2EBD E9F2C29D B4EEB962 61B9CF3B 05D903FC 57020301Router2(config-pubkey)#0001quitRouter2(config-pubkey-key)#exitRouter2(config-pubkey-chain)#exit
We then repeated the procedure on the other router.
With the keys in place, we proceeded to tell the routers how to use these keys to create an IPSec connection. Even though we are using a manually entered key, the two routers still need to use ISAKMP. The important difference between this example and the one in Recipe 12.3 is that here we are using RSA authentication keys. So we need to tell the routers to use this key method in the ISAKMP policy:
Router1(config)#crypto isakmp policyRouter1(config-isakmp)#100encryption 3desRouter1(config-isakmp)#authentication rsa-encrRouter1(config-isakmp)#group2
After that, the remainder of the configuration is essentially identical to what we showed in Recipe 12.3.
See Also
12.8. Creating a VPN Between a Workstation and a Router
Solution
There are several steps to configuring a router to accept IPSec VPN connections from remote PCs. The following discussion doesn’t include requirements for the PC’s software configuration, just the router’s configuration. You should refer to the software vendor’s documentation for information about configuring the workstation software:
Router1#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router1(config)#aaa new-modelRouter1(config)#aaa authentication login default group tacacs+Router1(config)#aaa authentication enable default group tacacs+Router1(config)#tacacs-server hostRouter1(config)#172.25.1.1tacacs-server keyRouter1(config)#COOKBOOKcrypto isakmp policyRouter1(config-isakmp)#10encryption 3desRouter1(config-isakmp)#authentication pre-shareRouter1(config-isakmp)#groupRouter1(config-isakmp)#2exitRouter1(config)#crypto ipsec transform-setVPN-TRANSFORMSah-sha-hmac esp-sha-hmacesp-3desRouter1(cfg-crypto-trans)#mode tunnelRouter1(cfg-crypto-trans)#exitRouter1(config)#crypto dynamic-mapRouter1(config-crypto-map)#VPN-USER-MAP 50descriptionRouter1(config-crypto-map)#A dynamic crypto map for VPN usersmatch addressRouter1(config-crypto-map)#115set transform-setRouter1(config-crypto-map)#VPN-TRANSFORMSexitRouter1(config)#access-listRouter1(config)#115deny any224.0.0.0 35.255.255.255access-listRouter1(config)#115deny any172.25.1.255 0.0.0.0access-listRouter1(config)#115permit any anycrypto mapRouter1(config)#CRYPTOMAP 10ipsec-isakmp dynamicVPN-USER-MAPinterfaceRouter1(config-if)#FastEthernet0/1ip addressRouter1(config-if)#172.25.1.5 255.255.255.0crypto mapRouter1(config-if)#CRYPTOMAPexitRouter1#
Discussion
The first few lines in this example are the aaa and tacacs-server commands, which are described in more detail in Chapter 4. This simply sets up username authentication for all incoming VPN connections, and allows you to get these authentication credentials from a central server running the TACACS+ protocol.
We are using AAA and TACACS+ in this configuration to supply the pre-shared keys that ISAKMP will use to set up its SA for this VPN. This is similar to the use of pre-shared keys in Recipe 12.3, but here we expect to have a large number of remote VPN users, so it is administratively easier if we manage them from the TACACS+ server instead of on the router.
Then we set up the ISAKMP policy as follows:
Router1(config)#crypto isakmp policyRouter1(config-isakmp)#10encryption 3desRouter1(config-isakmp)#authentication pre-shareRouter1(config-isakmp)#group2
This defines the policy for authentication and encryption keys, and is identical to the ISAKMP policy we used in Recipe 12.3. We selected these particular policy parameters because they are required for the Cisco Easy VPN Remote software. If you are using different client software, you may need to use different settings. This policy is also identical to the one we used in Recipe 12.3.
After doing this, we need to define the IPSec VPN properties. We begin by defining the transform set that we want to use for these VPN connections. We will call this transform set VPN-TRANSFORMS.
Router1(config)#crypto ipsec transform-setVPN-TRANSFORMSah-sha-hmac esp-sha-hmacesp-3desRouter1(cfg-crypto-trans)#mode tunnel
The VPN will use the esp-sha-hmac and esp-3des transforms. This transform set is almost the same as the one in Recipe 12.3, but this time we have specified that this VPN should use tunnel mode with the mode command. In Recipe 12.3, IPSec was used to encrypt traffic in a GRE tunnel. However, here we are dealing with VPNs that terminate on a user workstation, so it is not possible to create a GRE tunnel before establishing the connection. This example uses tunnel mode, which is actually the default.
Because the workstation could, in principle, be anywhere on the Internet, we can’t even define an IP address for it. But, to use IPSec on a Cisco router, we need to create a crypto map, which is a template for the SA that IPSec will use for this session. Fortunately, Cisco provides the ability to create dynamic crypto maps for precisely these types of situations:
Router1(config)#crypto dynamic-mapRouter1(config-crypto-map)#VPN-USER-MAP 50descriptionRouter1(config-crypto-map)#A dynamic crypto map for VPN usersmatch addressRouter1(config-crypto-map)#115set transform-setVPN-TRANSFORMS
This creates a dynamic map called VPN-USER-MAP. The number (50) on the end of the line is a sequence number, similar to the sequence numbers used in route map statements. The router will look at all map entries in sequence until it finds a match. In this case, the match is decided by the match address command, which compares the IP addresses of packets to access-list 115. If the access list matches the addresses in the packet header, it will then apply the transform set that we created earlier.
The access list here blocks any packets whose destination addresses are either multicasts or local broadcasts. Obviously this type of traffic cannot possible be associated with a VPN:
Router1(config)#access-listRouter1(config)#115deny any224.0.0.0 35.255.255.255access-listRouter1(config)#115deny any172.25.1.255 0.0.0.0access-list115permit any any
In practice, you may want to use a more restrictive access list.
We can then build the actual crypto map that references this dynamic map. In the following command, we create a crypto map called, appropriately enough, CRYPTOMAP. This command is sequence number 10 in the definition of the map. In fact, it’s the only command in the map’s definition, but there could easily be others, including static crypto maps similar to the ones we discussed in Recipe 12.3 and Recipe 12.5. Usually you actually want to put any dynamic maps at the end of your crypto map. This is because dynamic maps work best as catchall conditions for unknown IP addresses. So, if there are any known IP addresses that require special attention, you need to configure them first, before the dynamic map statements.
You apply the crypto map to the interface that will be receiving the VPN requests:
Router1(config)#crypto mapRouter1(config)#CRYPTOMAP 10ipsec-isakmp dynamicVPN-USER-MAPinterfaceRouter1(config-if)#FastEthernet0/1crypto mapCRYPTOMAP
See Also
12.9. Check IPSec Protocol Status
Solution
There are several useful commands for displaying IPSec parameters.
The command show crypto isakmp sa shows all of the ISAKMP security associations:
Router1#show crypto isakmp saYou can look at the IPSec security associations with this command:
Router1#show crypto ipsec saEven if you aren’t using a key management protocol such as ISAKMP, you can see information on all of the active IPSec connections with the following command:
Router1#show crypto engine connections activeThis closely related command will tell you about packet drops within the encryption engine:
Router1#show crypto engine connections dropped-packetThe show crypto map command gives information about all of the IPSec crypto maps that you have configured on your router, in use or not:
Router1#show crypto mapYou can specify a particular crypto map with the tag keyword:
Router1#show crypto map tag TUNNELMAPFor information about dynamic crypto maps, you can use the following command:
Router1#show crypto dynamic-mapDiscussion
The show crypto isakmp sa command lets you see information about the current state of any ISAKMP key exchanges that the router is involved in:
Router1#show crypto isakmp sa
dst src state conn-id slot
172.25.1.4 172.25.1.3 QM_IDLE 1 0
Router1#Table 12-3 shows all of the possible ISAKMP SA states.
Mode | State name | Description |
Main Mode | MM_NO_STATE | There is an ISAKMP SA, but none of the parameters have been negotiated yet. |
MM_SA_SETUP | The devices have negotiated a set of parameters for the SA, but have not yet exchanged any key information. | |
MM_KEY_EXCH | The devices have used the DH algorithm to create a common key, but they have not yet authenticated the session. | |
MM_KEY_AUTH | The devices have authenticated the SA. They can now proceed to Quick Mode. | |
Aggressive Mode | AG_NO_STATE | There is an ISAKMP SA, but none of the parameters have been negotiated yet. |
AG_INIT_EXCH | The devices have initiated an Aggressive Mode exchange. | |
AG_AUTH | The devices have completed an Aggressive Mode exchange and authenticated the SA. They can now proceed to Quick Mode. | |
Quick Mode | QM_IDLE | The SA is authenticated and ready for use. |
We used Main Mode in all of the examples in this chapter. Aggressive Mode allows faster SA setup by combining SA parameter negotiation, key exchange, and authentication information into the same packet. This has the disadvantage of not hiding the identity information on the peer devices, however. In Main Mode exchanges, this identity information is exchanged separately in encrypted form. Main Mode is the default. Because the extra overhead is minimal, you generally don’t need to resort to Aggressive Mode for ISAKMP.
Quick Mode is possible only after the initial ISAKMP exchange has happened at least once. The routers then use this mode when periodically renegotiating the SA information of an SA that has been active for a while. Quick Mode can take advantage of the existing SA to encrypt its exchange.
You can use the following rather verbose command to look at IPSec SAs:
Router1#show crypto ipsec sa
interface: FastEthernet0/1
Crypto map tag: TUNNELMAP, local addr. 172.25.1.3
local ident (addr/mask/prot/port): (172.22.1.3/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (172.22.1.4/255.255.255.255/47/0)
current_peer: 172.25.1.4
PERMIT, flags={transport_parent,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.25.1.3, remote crypto endpt.: 172.25.1.4
path mtu 1500, media mtu 1500
current outbound spi: 0
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
local ident (addr/mask/prot/port): (172.22.1.3/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.22.1.4/255.255.255.255/47/0)
current_peer: 172.25.1.4
PERMIT, flags={origin_is_acl,transport_parent,parent_is_transport,}
#pkts encaps: 466, #pkts encrypt: 466, #pkts digest 466
#pkts decaps: 1156, #pkts decrypt: 1156, #pkts verify 1156
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 172.25.1.3, remote crypto endpt.: 172.25.1.4
path mtu 1500, media mtu 1500
current outbound spi: EB99FB6C
inbound esp sas:
spi: 0x5A48ACC4(1514712260)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: TUNNELMAP
sa timing: remaining key lifetime (k/sec): (4606612/3392)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xEB99FB6C(3952737132)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: TUNNELMAP
sa timing: remaining key lifetime (k/sec): (4607955/3392)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
Router1#There is clearly a lot of information in this output. It breaks out the inbound and outbound information, and shows what crypto maps have been applied to which interfaces. It also includes information about the number of packets that the router has both been sent and received, as well as how much time remains before the SA must be renegotiated.
The show crypto engine commands allow you to see some of this same information in a more compact form. With the connections active keywords, this command tells you what interfaces are involved in IPSec SAs, the peer IP addresses, the algorithms used, and the number of packets sent and received through the encryption engine:
Router1#show crypto engine connections active
ID Interface IP-Address State Algorithm Encrypt Decrypt
1 <none> <none> set HMAC_SHA+3DES_56_C 0 0
2088 FastEthernet0/1 172.25.1.3 set HMAC_SHA+3DES_56_C 0 5
2089 FastEthernet0/1 172.25.1.3 set HMAC_SHA+3DES_56_C 202 0
Router1#With the connections dropped-packet keywords, you get some simple statistics on dropped packets. In the following example, the encryption engine was forced to drop five packets because the router tried to send them before it had a valid connection:
Router1#show crypto engine connections dropped-packet
Packets dropped because of connection not established:
Interface IP-Address Drop Count
FastEthernet0/1 172.25.1.3 5
Router1#The command show crypto map displays information about all of the configured crypto maps on the router, including which interfaces are currently using them. Note that just because a particular interface is using a particular crypto map, it does not follow that there are any active IPSec SAs. It only means that you have applied this map to this interface using the crypto map interface configuration command:
Router1#show crypto map
Interfaces using crypto map VPN-MAP:
Crypto Map "CRYPTOMAP" 10 ipsec-isakmp
Dynamic map template tag: VPN-USER-MAP
Interfaces using crypto map CRYPTOMAP:
Crypto Map "TUNNELMAP" 10 ipsec-isakmp
Peer = 172.25.1.4
Extended IP access list 116
access-list 116 permit gre host 172.25.1.3 host 172.25.1.4
Current peer: 172.25.1.4
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ TUNNEL-TRANSFORM, }
Interfaces using crypto map TUNNELMAP:
FastEthernet0/1
Router1#If you have several crypto maps configured on your router, you can look at a particular one with the tag keyword:
Router1#show crypto map tag TUNNELMAP
Crypto Map "TUNNELMAP" 10 ipsec-isakmp
Peer = 172.25.1.4
Extended IP access list 116
access-list 116 permit gre host 172.25.1.3 host 172.25.1.4
Current peer: 172.25.1.4
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ TUNNEL-TRANSFORM, }
Interfaces using crypto map TUNNELMAP:
FastEthernet0/1
Router1#If there are any dynamic maps, you can see more information about them with the following command:
Router1#show crypto dynamic-map
Crypto Map Template"VPN-USER-MAP" 50
Extended IP access list 115
access-list 115 permit tcp any port = 80 any
access-list 115 permit tcp any any port = 80
access-list 115 deny ip any 224.0.0.0 31.255.255.255
Current peer: 0.0.0.0
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ VPN-TRANSFORMS, }
Router1#