Transport and Tunnel Modes

When you invoke ESP or AH after the IP header to protect a datagram, this is referred to as transport mode. For example, if a packet starts off as:

Then in transport mode, ESP protects the data as follows:

AH, in transport mode, protects the data as follows:

AH actually covers the data before it appears in the datagram. Consequently, the protection provided by AH, even in transport mode, does cover some of the IP header.

When an entire datagram is inside the protection of an IPsec header, this is referred to as tunnel mode. Since AH covers most of its preceding IP header, tunnel mode is usually performed only on ESP. The previous example datagram would be protected in tunnel mode as follows:

Often, in tunnel mode, the outer (unprotected) IP header has different source and destination addresses from the inner (protected) IP header. The inner and outer IP headers can match if, for example, an IPsec-aware network program uses self-encapuslation with ESP. This is done in case of an IP header option that needs to be protected with ESP.

The Solaris implementation of IPsec is primarily a transport mode IPsec implementation, which implements the tunnel mode as a special case of the transport mode. This is accomplished by treating IP-in-IP tunnels as a special transport provider. When you use ifconfig(1M) configuration options to set tunnels, they are nearly identical to the options available to socket programmers when enabling per-socket IPsec. Also, tunnel mode can be enabled in per-socket IPsec.