skip to content

Transport vs Tunnel Mode

3 roadmaps5 questions

Transport mode protects the payload between two hosts; tunnel mode wraps the whole original packet in a fresh IP header. Interviewers ask because the overhead lands on your MTU either way.

on this pageshow

explore

questions

5

In IPsec, what is the difference between transport mode and tunnel mode, and where does the ESP header sit in each?

level: juniorimportance: must knowfreq 50%

answer

  1. keep the header, or add one
  2. what sits in front of ESP
  3. whose addresses the path routers see
  4. a gateway at either end

basics

~20 s

IPsec transport mode keeps the original IP header and inserts ESP between it and the payload, protecting only that payload; tunnel mode puts the whole original packet, header included, behind ESP and a new outer IP header.

solid answer

~50 s

Both modes use the same ESP (or AH) header; what changes is what surrounds it. In **transport mode** ESP goes straight after the original IP header and before TCP, UDP or whatever comes next, so the packet still travels between the two real endpoints and only the next-layer data is encrypted. In **tunnel mode** the entire original packet, its IP header included, becomes the protected payload, and a new outer IP header carries it between the IPsec peers, typically two security gateways. RFC 4301 makes an SA with a security gateway at either end tunnel mode, with two exceptions: traffic addressed to the gateway itself, and traffic the gateway sources as an intermediate system (for example its own GRE). Transport mode is the host-to-host choice and costs fewer bytes; tunnel mode hides the inner addresses but carries a second IP header.

go deeper

for a junior

Be able to say in one breath which mode keeps the original IP header and which adds a new one, and draw where the ESP header sits in each.

for a middle

Explain what the receiver does in each mode, what the ESP Next Header byte holds, and why RFC 4301 makes gateway-to-gateway SAs tunnel mode.

for a senior

Tie mode choice to consequences you have operated: the extra header against the MTU, which addresses a capture shows, and when transport mode on a router is legitimate.

for a principal

Frame the mode as a design input: address privacy and network reach against per-packet overhead and the loss of end-to-end access control when transport mode is used between routers.

## The same ESP, two places to put it IPsec has two protocols that protect packets, **ESP** (Encapsulating Security Payload, IP protocol 50, RFC 4303) and **AH** (Authentication Header, RFC 4302), and each can be used in two **modes**. The mode does not change the ESP header itself — it is still an SPI and a sequence number in front, a trailer with padding, `Pad Length` and `Next Header` behind, and an integrity check value (ICV) at the end. The mode decides **what ESP wraps**. | | Transport mode | Tunnel mode | |---|---|---| | IP header on the wire | the original one | a new outer one | | What ESP protects | the next-layer protocol and its data | the whole original packet, header included | | Addresses a router sees | the two real endpoints | the two IPsec peers | | `Next Header` in the ESP trailer | the next-layer protocol, e.g. 6 for TCP | 4 for an IPv4 inner packet, 41 for IPv6 | | Extra IP header | none | one (20 bytes for IPv4, 40 for IPv6) | ## Transport mode: the original packet, payload protected RFC 4303 §3.1.1 places transport-mode ESP **after the IP header (and any options) and before the next layer protocol**. For IPv6 it sits after the hop-by-hop, routing and fragment extension headers; destination options can go before or after it. The original IP header stays in clear, with its protocol field now saying 50, so the packet is routed exactly as before. ESP encrypts and authenticates what follows it; it does **not** protect the IP header in front of it. The name misleads people: transport mode is not limited to TCP and UDP. RFC 4303 says so explicitly — it protects whatever next-layer protocol follows the IP header, including ICMP or GRE. ## Tunnel mode: a packet inside a packet In tunnel mode the **inner** IP header carries the ultimate source and destination, and an **outer** IP header carries the addresses of the IPsec peers. ESP sits between the two, so the encrypted part covers the entire inner packet. RFC 4301 §5.1.2 describes how the outer header is built: addresses are the tunnel endpoints, the TTL and length are constructed, the DS field is copied from the inner header by default, and options are never copied. The inner and outer IP versions may differ — IPv6 inside IPv4, or the reverse. A receiver strips the outer header, checks and decrypts ESP, applies its policy to the **inner** header and forwards the inner packet onward. ## Who may use which mode RFC 4301 §4.1 sets the rules: 1. A **host** implementation MUST support both transport and tunnel mode. 2. A **security gateway** MUST support tunnel mode and MAY support transport mode. 3. Whenever either end of an SA is a security gateway, the SA MUST be tunnel mode — except when the traffic is addressed to the gateway itself (it is acting as a host, for instance for management traffic), or when the gateway sources the traffic itself as an intermediate system, such as GRE it builds. 4. IKE creates SAs in pairs, and both SAs of a pair use the **same** mode. In IKEv2 (RFC 7296) tunnel mode is the default. An initiator that wants transport mode includes a `USE_TRANSPORT_MODE` notification; if the responder declines, the Child SA is created in tunnel mode, and an initiator that cannot accept that MUST delete it. ## What each mode costs and buys - **Bytes.** Tunnel mode carries a whole extra IP header, so for the same cipher it is roughly 20 bytes (IPv4) or 40 bytes (IPv6) bigger, give or take the padding. - **Privacy of addresses.** Transport mode shows the real endpoints to every router on the path; tunnel mode shows only the two peers. - **Fragments.** RFC 4301 lets only tunnel mode carry IP fragments; transport mode is applied to whole datagrams. - **Reach.** Tunnel mode lets a gateway protect traffic for whole networks behind it; transport mode protects traffic that starts or ends at the IPsec node itself. ## Common confusions - Tunnel mode is not a different protocol: it is ESP (or AH) with a different layout. - Neither mode makes IPsec invisible: the IP protocol field still says 50 for ESP. - ESP in tunnel mode protects the inner header but **not** the outer one; only AH extends coverage to selected outer-header fields.

  • How does IKEv2 decide which IPsec mode a new Child SA uses?
    Tunnel mode is the default. An initiator that wants transport mode includes a `USE_TRANSPORT_MODE` notification in the request that carries the SA payload; a responder that accepts MUST include the same notification in its response. If the responder declines, the Child SA is established in tunnel mode, and an initiator that cannot live with that MUST delete the SA (RFC 7296).
  • Does IPsec transport mode only protect TCP and UDP traffic?
    No. RFC 4303 warns that the word "transport" should not be read as restricting it to TCP and UDP. Transport-mode ESP protects whatever next-layer protocol follows the IP header — ICMP, GRE or anything else — and the encrypted `Next Header` byte in the ESP trailer records which protocol it was.
  • Can an IPsec tunnel carry IPv6 packets between two IPv4 gateways?
    Yes. RFC 4301 and RFC 4303 allow the outer and inner IP versions to differ, so IPv6 inside IPv4 and IPv4 inside IPv6 are both legal. The ESP trailer's `Next Header` then says 41 for an IPv6 inner packet or 4 for IPv4, and the outer header's size (20 or 40 bytes) sets the extra overhead.

Transport mode seals the contents of a parcel but keeps the original shipping label on the outside, so every depot sees sender and recipient. Tunnel mode puts the whole labelled parcel inside a new sealed box addressed between two depots: the original label is hidden, and you pay for a second label.

saying these in an interview costs you the question

  • Transport mode also encrypts the original IP header, it just adds no new one
  • Tunnel mode is a separate protocol from ESP with its own header
  • Transport mode only works for TCP and UDP traffic
  • Two security gateways forwarding host traffic should use transport mode to save bytes
  • Tunnel mode hides from the path that IPsec is in use at all
open as a page

An IPsec ESP tunnel between two gateways on 1,500-byte links receives full-size 1,500-byte IPv4 packets with DF set; what happens, and what inner MTU fits?

level: seniorimportance: must knowfreq 35%

basics

~20 s

With AES-GCM the IPsec tunnel-mode packet would be 1,556 bytes, too big, so the gateway SHOULD drop it and send an ICMP PMTU message to the source; the largest inner packet that fits is 1,446 bytes.

open as a page

What can an on-path observer learn from an IPsec ESP packet in transport mode that tunnel mode would hide?

level: middleimportance: should knowfreq 22%

basics

~20 s

In IPsec transport mode an observer reads the real source and destination hosts from the original IP header; tunnel mode shows only the two gateways. Both encrypt ports and the next-layer protocol; sizes, timing and, by default, DS marks still leak.

open as a page

A 1,400-byte IPv4 packet is protected by IPsec ESP with AES-GCM and a 16-byte ICV; how large is it in transport and tunnel mode?

level: middleimportance: should knowfreq 28%

basics

~20 s

With IPsec ESP and AES-GCM (8-byte IV, 16-byte ICV), the 1,400-byte IPv4 packet becomes 1,436 bytes in transport mode (36 bytes added) and 1,456 bytes in tunnel mode (56 added), the difference being the outer IPv4 header.

open as a page

Two routers protect their GRE traffic with IPsec ESP; why is transport mode allowed there, and how many bytes does it save over tunnel mode?

level: seniorimportance: should knowfreq 18%

basics

~20 s

RFC 4301 lets a router use IPsec transport mode for packets it sources itself, and GRE packets carry the router's own address; tunnel mode would add a second IPv4 header with the same two addresses, 20 redundant bytes.

open as a page