IPsec makes VPN connection possible. I enables to simulate a leased line across public Internet and thus enable us to get secure connection across unsecured environment. It enables encryption, authentication and protection of our data when sent across insecurity of the world’s biggest internetwork – Internet.
It’s the cheap way to simulate a leased line, the way to send private data across the public network without compromising privacy. The goal of IPsec is to secure services and lower the cost of data transfer. Try to compare it to pricing of data transfers across dark cables / leased lines.
There are two parts of IPsec security suite
– ESP – Encapsulating Security Payload
– AH – Authentication Header
Based on our situation we can configure two different modes of operation and here we are to make the things clear about the differences and the technology behind those modes.
IPSec Transport Mode and Tunnel Mode
Tunnel mode encapsulates the whole IP packet by either encrypting, authenticating or most likely doing both. Tunnel mode will encapsulate our packets with IPSec headers and trailers.
ESP and AH are used. ESP Encapsulation Security Protocol header and trailer plus AH Authentication Header are inserted together in front and behind our IP packet. Sometimes it is only the ESP part. After the encapsulation a new IP header is prepended to the packet so he has the information about IPSec endpoints as new source and destination. Without this part we cannot forward the packet as he is most probably encrypted and intermediary devices cannot see the IP destination address inside to deduce where to send it next.
Tunnel mode may be used with any kind of IP traffic. On the other hand it must be used if IPSec is protecting traffic from hosts behind the IPSec peers. It means that it must be used if you are making a ‘Site to site’ VPN and protecting traffic for host behind both sides of the tunnel who are talking to each other across that tunnel. For example, tunnel mode is used with VPN where hosts on one protected network send packets to hosts on a second protected network via our pair of IPSec peers. With Site to site VPNs the thing is that hosts on separate (VPN connected) networks are the session endpoints and IPSec peers are just tunneling the protected traffic between the peers on the way from one host to another. We can say that IPsec peers are proxies for the hosts behind them. A picture might help here:
Client VPN connections are also using tunnel mode when establishing IPsec VPNs with the remote Gateway. If some remote worker is connecting his notebook using VPN Client and it is connecting to ASA firewall that is a Gateway at his office traffic from that client will be encapsulated/encrypted with new IP header and trailer and sent to ASA. When received and decrypted by ASA original IP data packet will be sent to local LAN device that was the destination. It works backwards also but basically that user will be NATed to some inside LAN network IP address so it will continue to work like he is cable connected in his office.
In tunnel mode IPSec will basically be set in place by either of ESP or AH header inserted between the real packet IP header and the upper layer protocol. ESP is preferred when it comes to IPSec VPN Tunnel solutions.
Here’s another image that will help a little to understand the encapsulation in IPSec Tunnel mode with ESP header:
We can see that the ESP is in use by identifying Protocol IP 50 inside New IP header prepended to packets of that kind. If you in place of Protocol ID 51 find Protocol ID 50, it means that there is AH in use rather then ESP. AH is applied together with the ESP or alone, when we speak about IPSec is in tunnel mode. AH protects the entire packet. The is not true about the fields in the New IP Header as they need to be read and edited in transit. AH will protect all the things that do not change in transit.
The packet diagram below illustrates IPSec Tunnel mode with AH header:
Transport mode can be used to protect IPsec peers traffic that they exchange and generate by themselves. This means that if we configure transport mode on some tunnel interface it will only be used when the traffic to be protected has the same IP addresses as the IPSec peers. Though it could also be encapsulated in tunnel mode like everything else but here is an interesting concept.
If we are using tunnel mode it is basically a tunneling mechanism that hides everything inside a header trailer capsule. But what if we are using GRE. If we are using GRE and then tunnel mode IPsec we will basically make tunneling and another tunneling inside the tunnel right. Only that one of those tunnels will encrypt and other will not. Enabling GRE to make encryption and avoid double tunneling is done by enabling transport mode on GRE tunnel 🙂
Transport mode setting, if set, is ignored for all other traffic. And all other is encapsulated in tunnel mode. Nice ha? Basically it means that if you configure transport mode you will allow to that router to negotiate with the remote peer whether to use transport or tunnel mode.
Transport mode only protects the payload no headers involved in encrypting and concealing of bits. Data is encrypted, authenticated, and all the that together but header remains exactly as it was. The payload will in that way be hidden by the IPSec headers and trailers. Same old ESP header and trailer, an AH header, or both. Do not confuse yourself when looking those images down there, the header remains the same but it’s still duplicated and prepended to original payload that was protected by encryption and stuff. In that way it can be used to get the packet routed from sending towards receiving peers (you need some kind of header for router to decide where to send the packet next, right?).
One of the examples when transport mode will be used is for protection of router management traffic. It can also be that you use an encrypted RDP session or SSH from your PC to Server. It will also be good there to use transport mode as in that case two host are speaking directly to each other through an IPsec tunnel.
Payload sent in transport mode is encapsulated by IPSec header and trailer. The original IP header remains the same but IP protocol field is changed to 50 for ESP or 51 in case of AH. Original protocol value will always be saved in IPsec trailer so it can be restored when the packet is decrypted.
Here’s a image to show you IPsec transport mode that uses ESP header:
We can use AH or only ESP alone when configuring IPSec is in transport mode. AH usually protects the whole packet, however, in the case of IPSec in transport mode it is not like that so it will not create a new IP header in front of the packet. It will instead copy the original header and paste it in front of encrypted thing although with some small changes to the protocol ID field therefore not providing essential protection to the details contained in the IP header as you know those are source IP, destination IP and some more.
No matter ESP or AH, IPSec in Transport mode exposes the IP header.
Here we see hoe to change the mode to transport mode:
crypto ipsec transform-set newer esp-des esp-sha-hmac mode transport exit
Before sitting in front of the console here’s what you need to know. If neither tunnel nor transport is specified, the default (tunnel mode) is assigned.
When you define the transform set option you enter crypto transform configuration mode where you can configure mode to tunnel or transport. It will be valid only for the transform set just configured. If you later want to change the mode again you must enter the transform set again by entering name and all settings .. and then change the mode.
When you change the mode like that it will not affect currently negotiated security associations. It will affect all future security associations established after the change. To speed thing up you could clear security association database. There is a nice little command:
clear crypto sa
used for that. And then the change will be applied to all security associations as they will be re-established again with new setting.