Transport Mode vs Tunnel Mode: Which Should I Use?

When using VPN as a client, there are two distinct modes that can be available. These are usually transparent to the end user, but are important to understand. Making an assumption of which option is in use can lead to delayed issue resolution as well as frustration by the engineer and client.

For the purpose of this post, we're primarily focusing on transport mode and tunnel mode in terms of the IPSEC protocol. It’s important to note that Request For Comments (RFCs) were published in the mid 1990s and superseded by new ones a few years later. This is a suite of protocols that has held up over time for IPv4 and refreshed for IPv6.

What is a VPN?

VPN stands for Virtual Private Network. Traditionally, they used to secure network traffic from one site or endpoint to another. By secure, we mean encrypt such that the contents cannot be viewed except for by the intended parties/sites. Most of the time this is used to encrypt those connections over the Internet. This is not the only use case though. Some organizations require encryption over private circuits such as MPLS, VPLS or Point to Point. While they are private connections, they are not secured nor encrypted and a VPN helps with that.

What Is Transport Mode?

Transport mode is an available option for creating a tunnel. This is primarily reserved for Point-to-Point tunnels. Those are where endpoints only need to communicate directly with each other. In today's world of SD-WAN where full mesh VPN tunnels are at the push of a few buttons this may seem crazy but you do have to remember when these types of tunnels started out. In the mid 1990's, encryption was not everywhere as it is today.

A key differentiator in transport mode is that the IP headers are not encrypted. It is only the payload of the data. Because the data is not really encapsulated like tunnel mode, the headers need to be unencrypted so routers can look at the source and destination and determine how to route them. For this reason, the original source and destination are viewable to everyone. This may not be an issue but it is the main distinction point aside from tunneling sites versus specific endpoints.

Transport Mode: Use Case 1

Prior to IPSEC, tunneling protocols existed. They served the purpose of connecting sites together over the internet. These protocols did not use much if any encryption. Security was fairly relaxed in the early days of the internet. At the time protocols like L2TP (Layer Two Tunneling Protocol) or Cisco's GRE (Generic Routing Encapsulation) existed. While they provided great tunneling capabilities, their encryption was limited to nonexistent.

It was easy to just configure a transport mode tunnel between sites. It served the purpose of encrypting these already existing tunnels. It allowed organizations to ease into IPSEC without having to rebuild their tunnels in transport mode. If they used something like GRE, the tunnel worked, they just wanted to layer on encryption to make it more secure. Their knowledge of GRE configuration and troubleshooting wouldn't go to waste.

Transport Mode: Use Case 2

In some cases, entire sites do not need to be encrypted, just two endpoints on the internet. In that case, transport mode could be used, particularly if you are not concerned about encrypting the IP headers and obscuring the original sources and destinations. This can work well for two endpoints that communicate directly over the internet, particularly in cases where the protocol is more or less plain text/raw. This is compared to modern applications and protocols that may use modern encryption techniques like TLS.

Transport Mode: Use Case 3

In some cases, point- to-site (P2S) connections may use a transport tunnel to encrypt connectivity between a client and a VPN concentrator. They may do this because they then use a proprietary tunneling protocol as mentioned in Use Case 1. This is fairly rare today though as they typically use IPSEC Tunnel Mode or a form of TLS/SSL/HTTPS tunnels.

Expounding on it a bit though, a Transport Mode tunnel is very similar to a TLS or HTTPS connection in that the IP header information is viewable but the payload is encrypted and protected. It is a modern day example of a Transport Mode tunnel.

What Is Tunnel Mode?

Tunnel mode is the most popular today between the two IPSEC modes. It takes roughly the same amount of configuration to setup but allows access to an entire site. It’s usually used For site-to-site (S2S) tunnels or P2S tunnels. While entire sites are usually in scope though, Firewall ACLs can further restrict access to actual endpoints.

Unlike transport mode though, the entire original packet is encapsulated, encrypted and then appended to a new packet. The outer packet appears to communicate between the public endpoints. Someone sniffing the packets cannot view the internal packets which show the original source, destination or payloads. This not only provides great protection (encryption) but also provides some obscurity too.

Tunnel Mode: Use Case 1

In the case of S2S tunnels, an entire site is tunneled to another site privately. This works very much like GRE as we discussed earlier except that tunnel mode provides the GRE functionality and the encryption all in the same technology. It is a singular configuration, instead of configuring two separate protocols and tunnels. As engineers become more familiar with this, it just made sense as IPSEC is a standardized protocol so it interoperated with many different vendors. In its early days while the RFCs were being revised it was a little rough but it has gone through quite a bit to become universally accepted and used between nearly all vendors.

Tunnel Mode: Use Case 2

For a P2S tunnel, this is typically your end-user VPN client connection where you have the end client (Point) tunneling to an entire site. Many times this acts just like a normal S2S tunnel except one side (client side) is a /32 or singular IP address in the tunnel endpoint.

This is the use case that most people are familiar with for corporate workers. Particularly those with older and legacy thick clients that require direct access to back end servers to communicate.

Tunnel Mode Hesitancy

In some cases, there may be IP overlaps that prevent tunnel mode. There are tricks to work around this such as smaller subnets or doing network address translation (NAT) to remap the overlap. Sometimes these can be tricky and therefore Transport Mode may be more acceptable in some of those edge cases.

In IPSEC's early days, there was a little hesitancy and skepticism so the tried and true tunneling protocols were used. Those environments typically required homogeneous environments as many of the tunnel protocols were vendor specific. In today's world though, it is very convenient to have a protocol mode that both tunnels and encrypts, unifying the technology and that works across most if not all vendors on the market.

Which Mode To Use?

Generally, tunnel mode is what you're going to run across most often as an IT pro. The topic of transport mode versus tunnel mode does not come up and it’s just assumed to be tunnel mode. Unless you have a very legacy environment using older protocols, tunnel mode is your choice. In other cases you may have an extreme edge case and in those scenarios you usually know you need transport mode. Learn more with CBT Nuggets.