Cisco GRE and IPSec - GRE over IPSec - Selecting and Configuring GRE IPSec Tunnel or Transport Mode

 

Cisco GRE and IPSec - GRE over IPSec - Selecting and Configuring GRE IPSec Tunnel or Transport Mode

 

 

 

GRE Tunnels are very common amongst VPN implementations thanks to their simplicity and ease of configuration. With broadcasting and multicasting support, as opposed to pure IPSec VPNs, they tend to be the number one engineers' choice, especially when routing protocols are used amongst sites.

 

The problem with GRE is that it is an encapsulation protocol, which means that while it does a terrific job providing connectivity between sites, it does a terrible job encrypting the data being transferred between them. GRE is stateless, offering no flow control mechanisms (think of UDP). This is where the IPSec protocol comes into the picture.

 

IPSec’s objective is to provide security services for IP packets such as encrypting sensitive data, authentication, protection against replay and data confidentiality. IPSec is extensively covered in our IPSec protocol article.

 

IPSec can be used in conjunction with GRE to provide top-notch security encryption for our data, thereby providing a complete secure and flexible VPN solution. IPSec can operate in two different modes, Tunnel mode and Transport mode. Both of these modes are covered extensively in our Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode article. Additionally, Cisco GRE Tunnel configuration is covered in our Configuring Cisco Point-to-Point GRE Tunnels. We highly recommend reading these articles before proceeding as it is a prerequisite for understanding the information covered here.

 

As with IPSec, when configuring GRE with IPSec there are two modes in which GRE IPSec can be configured, GRE IPSec Tunnel mode and GRE IPSec Transport mode.

 

This article examines the difference between GRE IPSec Tunnel and GRE IPSec Transport mode, and explains the packet structure differences along with the advantages and disadvantages of each mode.

 

GRE IPSec Tunnel Mode

 

With GRE IPSec tunnel mode, the whole GRE packet (which includes the original IP header packet), is encapsulated, encrypted and protected inside an IPSec packet. GRE over IPSec Tunnel mode provides additional security because no part of the GRE tunnel is exposed, however, there is a significant overhead added to the packet. This additional overhead decreases the usable free space for our payload (Original IP packet), that means possibly more fragmentation will occur when transmitting data over a GRE IPSec Tunnel VPN.

 

IPSec Tunnel mode is the default configuration option for both GRE and non-GRE IPSec VPNs. When configuring the IPSec transform set, no other configuration commands are required to enable tunnel mode:

 

• R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

 

Calculating GRE IPSec Tunnel Mode Overhead

 

Calculating the overhead will help us understand how much additional space GRE over IPSec in Tunnel mode requires and our effective usable space.

 

The packet structure below shows an example of a GRE over IPSec in Tunnel mode:

 

Two important points to keep in mind when calculating the overhead:

 

Depending on the encryption algorithm used in the crypto transform set, the Initialization Vector (IV) shown could be 8 or 16 bytes long. For example DES or 3DES introduces an 8-byte IV field, where as AES introduces a 16-byte IV field. In our example, we are using 3DES encryption, therefore producing a 8-byte IV field.

 

The ESP Trailer will usually vary in size. Its job is to ensure that the Pad Length, Next Header fields (both 1-byte long and contained within the ESP Trailer) & ESP Auth.Trailer are aligned on a 4-byte boundary. This means the total number of bytes, when adding the three fields together, must be a multiple of 4.

 

Following is the calculated overhead:

 

ESP Overhead: 20 (IP Hdr) + 8 (ESP Hdr) + 8 (IV) + 4 (ESP Trailer) + 12 (ESP Auth) = 52 Bytes

 

Note: ESP Trailer has been calculated as 4 bytes as per above note.

 

GRE Overhead: 20 (GRE IP Hdr) + 4 (GRE) = 24 Bytes

 

Total Overhead: 52 + 24 = 76 Bytes

 

GRE IPSec Transport Mode

 

With GRE IPSec transport mode, the GRE packet is encapsulated and encrypted inside the IPSec packet, however, the GRE IP Header is placed at the front. This effectively exposes the GRE IP Header as it is not encrypted the same way it is in Tunnel mode.

 

IPSec Transport mode is not used by default configuration and must be configured using the following command under the IPSec transform set:

 

R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

R1(cfg-crypto-trans)# mode transport

 

 

 

 

 

GRE IPSec transport mode does have a few implementation restrictions. It is not possible to use GRE IPSec transport mode if the crypto tunnel transits a device using Network Address Translation (NAT) or Port Address Translation (PAT). In such cases, Tunnel mode must be used.

 

Finally, if the GRE tunnel endpoints and Crypto tunnel endpoints are different, GRE IPSec transport mode cannot be used.

 

These limitations seriously restrict the use and implementation of the transport mode in a WAN network environment.

 

Calculating GRE IPSec Transport Mode Overhead

 

Calculating the overhead will help us understand how much space GRE over IPSec in Transport mode uses and our effective usable space.

 

 

The packet structure below shows an example of GRE over IPSec in transport mode:

 

 

 

 

 

Again, two important points that must kept in mind when calculating the overhead:

 

Depending on the encryption algorithm used in the crypto transform set, the Initialization Vector (IV) shown could be 8 or 16 bytes long. For example DES or 3DES introduces an 8-byte IV field, where as AES introduces a 16-byte IV field. In our example, we are using 3DES encryption, therefore producing a 8-byte IV field.

 

The ESP Trailer will usually vary in size. Its job is to ensure that the Pad Length, Next Header fields (both 1-byte long and contained within the ESP Trailer) & ESP Auth.Trailer are aligned on a 4-byte boundary. This means the total number of bytes, when adding the three fields together, must be a multiple of 4.

 

Following is the calculated overhead:

 

ESP Overhead: 20 (IP Hrd) + 8 (ESP Hdr) + 8 (IV) + 4 (ESP Trailer) + 12 (ESP Auth) = 52 Bytes

 

Note: ESP Trailer has been calculated as 4 bytes as per above note.

 

GRE Overhead: 4 (GRE) = 4 Bytes

 

Total Overhead: 52 + 4 = 56 Bytes

 

It is evident that GRE IPSec Transport mode saves approximately 20 bytes per packet overhead. This might save a moderate amount of bandwidth on a WAN link, however, there is no significant increase in CPU performance by using this mode.

 

Conclusion

 

When comparing GRE over IPSec tunnel and GRE over IPSec transport mode, there are significant differences that cannot be ignored.

 

If the GRE tunnels and crypto endpoints are not the same (IP address wise), transport mode in definitely not an option.

 

If packets traverse a device (router) where NAT or PAT is used then again, transport mode cannot be used.

 

On the other hand, tunnel mode seems to pay-off its 20-byte additional overhead by being flexible enough to be used in any type of WAN environment and offering increased protection by encrypting the GRE IP Header inside the ESP packet.

 

Taking in consideration the small additional CPU load the tunnel mode produces and advantages it offers, we don’t believe it’s a coincidence Cisco has selected this mode in IPSec’s default configuration.