Skip to content

📦 08-03: Tunnel vs. Transport Mode


📌 Two Ways to Wrap a Packet

IPsec (and VPN tunneling in general) can protect traffic in one of two structurally different ways: tunnel mode and transport mode. Both use the same underlying protocols (AH/ESP — see 08-02: IPsec Fundamentals), but they differ in how much of the original packet gets wrapped and protected, and which IP addresses end up visible on the outside of the protected packet.

The core idea behind any tunneling technology, IPsec included: the payload of the outer packet carries another entire IP packet inside it — the packet that actually needs to be protected, such as traffic destined for a private network. The tunnel itself runs across a public network (like the Internet), connecting Tunnel End A to Tunnel End B; everything inside the tunnel is protected, while the outer packet is what's actually visible to devices along the public path.

💡 Think of tunnel mode as putting a sealed envelope inside another envelope, addressed to a totally different location (the tunnel endpoint) than the letter inside. Transport mode is more like putting a letter in a tamper-evident sleeve, still addressed to its real destination, with only the letter's contents protected.


🔒 Tunnel Mode

In tunnel mode, the entire original IP packet — header and payload both — is treated as data, encrypted/protected, and then wrapped inside a brand-new IP packet with its own new header.

Before (original packet, e.g., a private network host talking to another private network host)

[ Original IP Header (src: 192.168.60.5, dst: 192.168.60.10) | TCP/UDP | Payload ]

After (tunnel mode — this is what actually travels the public Internet)

[ New IP Header (src: VPN-Gateway-A, dst: VPN-Gateway-B) | ESP/AH Header | Original IP Header (src: 192.168.60.5, dst: 192.168.60.10) | TCP/UDP | Payload | ESP Trailer/Auth ]
              \_______________________ this whole part is encrypted by ESP _______________________/

The new outer header uses the VPN gateways' addresses as source and destination. The original packet — including its own original source/destination addresses, which might be private/internal addresses never meant to be routed on the public Internet — is completely hidden inside the encrypted payload.

Why Tunnel Mode Is Used for Site-to-Site VPNs

Site-to-site VPNs need to carry traffic between two private networks (e.g., 192.168.60.0/24 at Site A and 192.168.70.0/24 at Site B) across the public Internet. Those private addresses are not routable on the public Internet, and even if they were, you wouldn't want to expose them. Tunnel mode solves both problems at once:

  • The original (private, internal) packet is fully hidden — an eavesdropper on the public Internet only sees traffic between the two gateway IP addresses, nothing about the internal hosts.
  • The outer packet uses publicly routable gateway addresses, so ordinary Internet routers can forward it with no special knowledge of the private networks inside.

💡 This is exactly the "IP tunneling" concept: the actual packet that traverses the public network carries another IP packet as its payload — the one that needs protecting.


🔓 Transport Mode

In transport mode, only the payload of the original packet (the TCP/UDP segment and its data) is protected. The original IP header is kept as-is and is not encrypted — it's still used to route the packet to its real destination.

Before

[ Original IP Header (src: HostA, dst: HostB) | TCP/UDP | Payload ]

After (transport mode)

[ Original IP Header (src: HostA, dst: HostB) | ESP/AH Header | TCP/UDP | Payload | ESP Trailer/Auth ]
                                                \___ this part is encrypted by ESP ___/

Notice there's no new outer IP header — the original header is still front and center, still showing the real source and destination addresses, and it's still what routers use to forward the packet. Only the segment (and its data) riding inside gets wrapped in encryption/integrity protection.

Why Transport Mode Is Used for Host-to-Host

Transport mode is the natural choice when the two communicating parties are the two IPsec endpoints — i.e., a direct host-to-host conversation, rather than one network's traffic being carried on behalf of many internal hosts through a gateway.

  • No need to hide the original addresses — the two hosts are already the legitimate, intended source and destination.
  • Less overhead — there's no second IP header being added, so transport mode packets are slightly smaller than the equivalent tunnel-mode packets.
  • Common use case: securing a single, specific connection between two servers that both understand IPsec directly (e.g., two servers within an organization that want authenticated, encrypted communication without setting up a full gateway-to-gateway tunnel).

⚖️ Side-by-Side Comparison

Feature Tunnel Mode Transport Mode
What's protected Entire original IP packet (header + payload) Only the payload (TCP/UDP segment)
New IP header added? ✅ Yes — new outer header with gateway addresses ❌ No — original header stays
Original source/destination hidden? ✅ Yes, fully hidden inside encryption ❌ No, still visible
Typical endpoints Gateway ↔ Gateway Host ↔ Host
Typical use case Site-to-site VPN Direct secured connection between two hosts
Packet size overhead Higher (extra IP header) Lower
Can carry private/internal addressing across a public network? ✅ Yes — that's its whole purpose ❌ No — original header must already be valid for the path

💡 A quick way to decide which mode applies: ask "are the two IPsec endpoints the same as the two communication endpoints?" If yes (Host A talking directly to Host B, and both run IPsec), that's transport mode. If no (Host A talking to Host V, but the actual IPsec protection is applied by gateways sitting in front of each of them), that's tunnel mode.


🧭 Where This Fits in a Full VPN

Remote-access and site-to-site VPN products almost always use tunnel mode, because the whole point is to let entire private networks (with their own internal, often non-routable addressing) reach each other across the public Internet, without the internal addressing or topology ever being visible outside. Transport mode is more of a "point protection" tool for specific host-to-host conversations rather than a full VPN architecture.

For a practical walkthrough of setting up an actual tunnel (including authentication and configuration), see 08-04: Building a VPN Tunnel.


📌 Key Takeaways

  • Tunnel mode wraps the entire original IP packet (header included) inside a new packet with a new outer header — the original addressing is completely hidden.
  • Transport mode protects only the payload of the original packet; the original IP header stays visible and is still used for routing.
  • Tunnel mode is used for gateway-to-gateway (site-to-site) VPNs because it can carry private, non-routable internal addressing safely across a public network.
  • Transport mode is used for host-to-host connections where the two IPsec endpoints are the actual communicating parties, with less overhead.
  • The decision rule: if the IPsec endpoints differ from the true communication endpoints (gateways protecting traffic on behalf of internal hosts), use tunnel mode; if they're the same, transport mode suffices.
  • Tunnel mode adds more overhead (an extra IP header) than transport mode, but that overhead buys full topology hiding.
  • Both modes can use either AH or ESP underneath — mode and protocol are independent choices, though ESP + tunnel mode is by far the most common real-world combination.