IPsec tunnels are widely used, and becoming even more so in modern networks. There are many reasons for this. In this article, we will attempt to correct some common misconceptions about IPsec tunnels, look at the types of IPsec tunnels, review their building blocks, and discuss some of the security issues surrounding them.
It is important to fully understand what an IPsec tunnel is at a high level before attempting to configure it and/or develop a detailed understanding. A lot of the issues people have in comprehending IPsec tunneling come from visual preconceptions about what a tunnel is, and thus what tunneled traffic should look like. When most people hear the word tunnel, they think of an enclosure that totally surrounds what is passing through it. While this image generally works for a high-level knowledge of IPsec, it leads to confusion when learning about the finer points of IPsec. So, please make sure you have discarded this image from your mind before we proceed.
Perhaps a better, more accurate image of an IPsec tunnel is a two-way coding machine that intercepts communications between two people. With the IPsec “code machine,” you intercept a plain-text message and encode certain parts of the message. The fact that only certain parts of a message are encoded is a very important distinction. Taking our code machine example, let’s say we intercept a plaintext (i.e., unencoded) letter between two people. Encrypting the entire message means you have also just encrypted the destination address on the envelope. And unless the postman delivering the message can decipher that address, they are not going to be able to deliver it for you. That said, you can encode the entire packet. But if you do that, you need to take the encoded letter and put it in a new “envelope” (aka an IP header) that has a readable source and destination address. IPsec tunneling is still the industry standard term—and most likely the one you will be using on a day to day basis—but you have to understand how it differs from a your visual image of a tunnel.
Benefits of IPsec
One of the reasons IPsec is so popular is its ability to work across different platforms of different vendors and, with a few exceptions, provide universal interoperability. For example, after exchanging settings with another network administrator, you are able to bring up an IPsec tunnel between two completely dissimilar devices, such a Cisco router and a Checkpoint firewall, or a Cisco router and somebody’s Dell laptop. The possibilities are almost endless. There are not many other protocols that provide such flexibility.
So now that we’ve thrown away the confusing preconceptions about tunnels, what exactly do IPsec tunnels provide? Generally, it can be said they provide VPN (virtual private network) functionality between two endpoints. To understand what this means, we can go back to our code machine example. Let’s say you have one spy in Washington DC and another in Berlin. The purpose of the code machine is to make sure that a message transmitted from one spy to the other cannot be understood by anyone in between them who might be listening. This allows the two hosts to talk as if (i.e., virtually) they were both in the same secure building (i.e., private network). For this reason, you’ve often hear the term VPN used in place of IPsec tunnel. For example, someone might say, “We have a VPN between our offices in Beijing and Tokyo.” In reality, they have an IPsec tunnel that provides VPN functionality between the two offices, but it’s helpful to understand some of the terminology you might hear on a day-to-day basis.
IPsec Tunnel Modes
So what are the two common types of VPNs that IPsec tunnels provide? Although one could spend quite some time touching on all the possible variations, for the purposes of this document, only the two main classifications (tunnel and transport) will be addressed. We have already described the differences between the two. Do you remember how we talked about whether or not the encoder of the message uses a new envelope or keeps the existing one? That is, in essence, the difference between tunnel and transport mode. Tunnel mode means you encrypt everything, and put the entire message in a new envelope. This new envelope in networking terms is an IP header. Transport mode means the encoder opens up the letter, takes out the message, encrypts it, put the message back in, and sends it over the untrusted network with the existing envelope (IP header).
Which mode is used usually depends on what you are using it for. Tunnel mode is most commonly used when the tunnel is being formed between two networking devices, such as two Cisco routers, or perhaps between a firewall and a router. Transport mode, however, is generally used when only one side of the tunnel is a networking device. When you access work resources from, say, your home laptop, chances are that you are using an IPsec tunnel in transport mode to accomplish this. You can see the mode in use by using the “show crypto ipsec sa” command.
Is it possible to interchange the two? Well, yes, in certain circumstances it is. But the purposes one might have for doing so are questionable, and rare enough that they do not justify further exploration, at least in this article.
With a basic understanding of IPsec tunneling, we can now define the building blocks of any working IPsec tunnel. Remember, this article focuses on Cisco routers so, although the components are going to be the same, the names and CLI syntax discussed here will be specific to Cisco routers, and will change when you are working on some other platform. IPsec uses two phases when building an IPsec tunnel, referred to as phase 1 and phase 2. Speaking very generally, in phase 1 you will be using the Diffie-Hellman protocol (outside the scope of this document) to ensure that your keys match, and setting up a secure connection for phase 2 to run over. During phase 2, you agree upon the remainder of the parameters required to fully bring up the IPsec tunnel. When you build an IPsec tunnel, you have to define the parameters that you will accept for both phase 1 and phase 2. When the tunnel is brought up, the two endpoints ensure they can agree on the settings used, and the tunnel comes up. Parameters for phase 1 are defined in something called an “isakmp profile.” Phase 2 parameters are defined in something called a transform set. An example of a configuration you might see is as follows:
crypto isakmp policy 10 encryption aes 256 authentication pre-share lifetime 64800 group 5 crypto ipsec transform-set TUNNEL esp-3des esp-sha-hmac
In the example above, your ISAKMP (Phase 1) policy specifies that you will be using 256-bit AES encryption, a pre-shared key, and Diffie-Hellman group 5. For Phase 2, you are specifying that either ESP (encapsulating security payload) 3DES or SHA-HMAC algorithm can be used. Although the details of each of these protocols is beyond this document’s scope, the key thing is to make sure that whatever is configured on one side is the same as what is configured on the other side. If you have a mismatch in tunnel parameters, the tunnel might not come up.
In the ISAKMP profile example above, we specified that authentication is going to be based on a pre-shared key. You have to define what that key is, and also what hosts having that key you will establish a tunnel with. How you define the key is going to depend on how many hosts you will accept that key from. If you wanted to accept it from, say, one or two hosts, you would define it for each specific host, as follows:
crypto isakmp key 0 CISCO address 18.104.22.168 crypto isakmp key 0 CISCO address 22.214.171.124
However, if the host you are forming the tunnel with has its IP change frequently, or if you did not want to define a new key manually for every new host, you could use a keyring definition instead.
crypto keyring spokes pre-shared-key address 0.0.0.0 0.0.0.0 key CISCO
The next thing to define is what is known as “interesting traffic.” Interesting traffic is just a fancy term for what stuff needs to be encrypted. Going back to our code machine example, there are likely only certain messages deemed to be sensitive enough to justify encoding. For example, perhaps a letter to the spy’s mother would not require encryption. What traffic is considered “interesting enough” to be encrypted is defined with an access list. This access list is like the mail inspector. It looks at every packet passing through the router and if it matches the access list, it is encrypted. Using an interesting traffic ACL gives you a great level of flexibility in determining what is encrypted and what is not. If you wanted to encrypt only HTTP traffic, for example, your interesting traffic ACL would look like this:
access-list 100 permit tcp any any eq 80 access-list 100 permit tcp any eq 80 any
Once all these parameters have been compiled, you need something that ties them all together. That function is performed with a crypto map. In the crypto map, you generally define the peer IP, the lifetime of the association, what transform set is used, and also the interesting traffic. A very key thing to note is the “10” in the crypto map command. This 10 is really just a sequence number. You can have multiple sequences in a single crypto map. This would allow you to have multiple IPsec tunnels going out the same interface – which is much more common than you might suppose.
Note: If you did not know the IP address of the other side, your configuration would change slightly, since you would be using a dynamic crypto map.
crypto map mymap 10 ipsec-isakmp set peer 126.96.36.199 set transform-set TUNNEL match address 100 set security-association lifetime seconds 3600
The final step with IPsec is you applying the crypto map to the appropriate router interface.
interface Gi0/0 crypto map mymap
So in the case of the configuration above, any HTTP traffic exiting Gi0/0 would be encrypted, have a new header added to it (source of the IP of Gi0/0, Destination Of the IP of 188.8.131.52), and be forwarded.
The status of IPsec Phase 1 and Phase 2 can both be checked via the Cisco CLI. The command to check phase 1 status is “show crypto isakmp sa”. The command to check phase 2 is “show crypto ipsec sa”. SA stands for security association. Really, a SA is just a group of parameters that have been negotiated between the peers on either side of the IPsec tunnel. These commands are immensely helpful in troubleshooting anything that might be wrong with a tunnel that has already come up. For example, you can see how many packets have been encrypted or decrypted.
Unfortunately, if a tunnel isn’t coming up, those commands are not going to show you much. In this case, you will need to rely more on debugging commands. “Debug crypto isakmp” and “debug crypto ipsec” are the two main ones. While the intricacies of debugging are outside the scope of this article, you need to understand what you are doing before you enable either of those debugs. Also, another key thing to remember is that a tunnel won’t come up until it has a reason to, so make sure you are generating some interesting traffic to force the tunnel to come up.
For example, if you forget to set your transform set in the crypto map, you’d see something like this in the debug
As we have seen, IPsec is an extremely secure way to transfer data between two endpoints over an untrusted network. That said, having IPsec doesn’t mean you are immune to any security attacks. But in practical reality, any flaws IPsec does have usually center around administrator configuration and especially how you are exchanging your key! If you are having an instant messaging conversation with the remote network administrator you are attempting to set up the IPsec connection with via some clear-text IM application, and send them the key, it’s entirely possible this could be intercepted. Or if you send it via email and that person’s account is compromised, etc.
But perhaps the most harmful and potentially disastrous security hole related to IPsec combines the careless password behavior described above in conjunction with the dynamic VPN tunnel. This could allow an attacker to set up a tunnel with you from ANY source IP address, and have 100% unrestricted access to your internal network. And once they have this, they could launch any number of reconnaissance or active attacks.
In summary, IPsec is a industry-standard, universally used protocol providing the ability to extend your LAN over untrusted networks. Having a solid understanding of what it is, its building blocks, and being able to correctly secure, configure, and troubleshoot it are basic requirements for any network administrator.