IPsec and IKE Administration Guide

Transport and Tunnel Modes

When you invoke ESP or AH after the IP header to protect a datagram, you are using transport mode. An example follows. A packet starts off with the following header:

Diagram shows the IP header followed by the TCP header. The TCP header is not protected.

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

Diagram shows the ESP header between the IP header and the TCP header. The TCP header is encrypted by the ESP header.

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

Diagram shows the AH header between the IP header and the TCP header.

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

When an entire datagram is inside the protection of an IPsec header, IPsec is protecting the datagram in tunnel mode. Because 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:

Diagram shows the ESP header after the IP header and before an IP header and a TCP header. The last 2 headers are protected by encryption.

In tunnel mode, the inner header is protected, while the outer IP header is unprotected. Often, the outer IP header has different source and different destination addresses from the inner IP header. The inner and outer IP headers can match if, for example, an IPsec-aware network program uses self-encapsulation with ESP. Self-encapsulation with ESP protects an IP header option.

The Solaris implementation of IPsec is primarily an implementation of IPsec in transport mode. Tunnel mode is implemented as a special instance of the transport mode. The implementation treats IP-in-IP tunnels as a special transport provider. The ifconfig configuration options to set tunnels are nearly identical to the options that are available to socket programmers when enabling per-socket IPsec. Also, tunnel mode can be enabled in per-socket IPsec. In per-socket tunnel mode, the inner packet IP header has the same addresses as the outer IP header. For details on per-socket policy, see the ipsec(7P) man page. For configuring tunnels, see the ifconfig(1M) man page.

Trusted Tunnels

A configured tunnel is a point-to-point interface. The tunnel enables an IP packet to be encapsulated within an IP packet. A correctly configured tunnel requires both a tunnel source and a tunnel destination. For more information, see the tun(7M) man page and “Solaris Tunneling Interfaces for IPv6” in System Administration Guide: IP Services.

A tunnel creates an apparent physical interface to IP. The physical link's integrity depends on the underlying security protocols. If you set up the security associations securely, then you can trust the tunnel. Packets that exit the tunnel must have originated from the peer that was specified in the tunnel destination. If this trust exists, you can use per-interface IP forwarding to create a virtual private network.