IPsec Virtual Tunnel Interface

1. Introduction

In the previous post we upgraded our hub and spoke network from crypto maps to crypto profiles. We’ll now look at how you can reduce the tunnel’s overhead by using a Virtual Tunnel Interface (VTI) instead of a GRE tunnel.

2. Background On GRE

To make a compelling case for VTI we first need to understand a bit more about the GRE encapsulation. Generic Routing Encapsulation (GRE) was designed to be capable of applying its encapsulation to many different types of payloads. To do this, an additional header is added in addition to the actual delivery header that is used to forward the packet from A to B. The basic format looks like this:

The idea is to indicate in the GRE header what the payload is using a protocol field. The protocol numbers are the same as the EtherType numbers used in an Ethernet frame to indicate what the network layer protocol is. The goal of this is to make demultiplexing easier; a fancy way of saying that the router must know which process should get the packet next once it has processed the current header. Without the protocol fields, the decapsulated packet would have to be inspected in some other way to determine what it actually consists of. If IPv4 is encapsulated with a GRE header using IPv4 as the delivery protocol, the demultiplexing process would look something like this:

In that image a packet has reached the IPv4 process because the frame it was carried in had some kind of protocol field indicating that the network layer protocol was IPv4. In the IPv4 process, the protocol is determined to be 47, which is GRE, and the packet is sent to the GRE process after the IPv4 header has been stripped. GRE’s protocol field says that payload must be IPv4. The packet is sent back to the IPv4 process that is then able to determine that the destination is the router itself and that the transport layer protocol is TCP. The TCP process receives the packet and further processes it.

This is an idealized picture. In reality, following this kind of strict demultiplexing would be slow and not possible in all scenarios. Instead you could for example look at both the outer IPv4 and the GRE header simultaneously and determine that the third header is IPv4. You could then strip both of those headers instead of taking a detour to a GRE process. This type shortcut is often called packet classification. Instead of sequentially looking at each header’s protocol field and sending the packet to the next process, the device looks for certain patterns in a series of headers. If this sounds interesting, there’s an article on it here.

In conclusion, GRE can carry many different payloads and must have an additional header to indicate what that payload is. But what if you knew that the payload was always the same, would you still need the GRE header? It turns out that you don’t, and that is what the VTI feature takes advantage of.

4. Lots of Headers

If you deploy GRE over IPsec your packet will receive a significant number of headers.

(This is GRE over IPsec using tunnel mode)

What all these headers actually mean would probably make a good post, but it’s no the focus of this one. However, the GRE IP header and the GRE header itself could be unnecessary overhead since GRE’s capability to carry a generic payload isn’t necessarily relevant in a pure IP-in-IP IPsec environment.

5. Virtual Tunnel Interface

What VTI accomplishes is putting the original IP packet through the IPsec process without first adding a GRE header. The end result is a packet without the GRE related headers.

The price you pay is that you can no longer carry non-IP traffic.

Configuration of the feature involves just a single command under the tunnel interface, changing its mode from GRE IP to IPsec IPv4|IPv6.

!
interface tunnel0
tunnel mode ipsec ipv4
!

(refer to my previous post on crypto profiles for the full configuration)

When we used GRE over IPsec, a packet with the tunnel as its outgoing interface was given a GRE header and was then matched by the IPsec process based on that header. With VTI configured, packets with the tunnel in question as the outgoing interface are sent directly to the IPsec process without being given additional headers. As a result, we’ve removed 20 (GRE IP header) + 4 (GRE header) bytes of overhead.