Transport and Tunnel Modes in IPsec
The IPsec standards define two distinct modes of IPsec operation, transport mode and tunnel mode. The key difference between transport and tunnel mode is where policy is applied. In tunnel mode, the original packet is encapsulated in another IP header. The addresses in the other header can be different.
In transport mode, the IP addresses in the outer header are used to determine the IPsec policy that will be applied to the packet.
In tunnel mode, two IP headers are sent. The inner IP packet determines the IPsec policy that protects its contents.
Tunnel mode can be applied to any mix of end systems and intermediate systems, such as security gateways.
The packets can be protected by AH, ESP, or both in each mode. The modes differ in policy application, as follows:
In transport mode, the IP header, the next header, and any ports that the next header supports can be used to determine IPsec policy. In effect, IPsec can enforce different transport mode policies between two IP addresses to the granularity of a single port. For example, if the next header is TCP, which supports ports, then IPsec policy can be set for a TCP port of the outer IP address.
Tunnel mode works only for IP-in-IP packets. In tunnel mode, IPsec policy is enforced on the contents of the inner IP packet. Different IPsec policies can be enforced for different inner IP addresses. That is, the inner IP header, its next header, and the ports that the next header supports can enforce a policy. Unlike transport mode, in tunnel mode the outer IP header does not dictate the policy of its inner IP packet.
Therefore, in tunnel mode, IPsec policy can be specified for subnets of a LAN behind a router and for ports on those subnets. IPsec policy can also be specified for particular IP addresses, that is, hosts, on those subnets. The ports of those hosts can also have a specific IPsec policy. However, if a dynamic routing protocol is run over a tunnel, do not use subnet selection or address selection because the view of the network topology on the peer network could change. Changes would invalidate the static IPsec policy. For examples of tunneling procedures that include configuring static routes, see Protecting a VPN With IPsec.
In Oracle Solaris, tunnel mode can be enforced only on an IP tunneling network interface. For information about tunneling interfaces, see Chapter 4, About IP Tunnel Administration, in Administering TCP/IP Networks, IPMP, and IP Tunnels in Oracle Solaris 11.2 . IPsec policy provides a tunnel keyword to select an IP tunneling network interface. When the tunnel keyword is present in a rule, all selectors that are specified in that rule apply to the inner packet.
The following figure shows an IP header with an unprotected TCP packet.
Figure 6-3 Unprotected IP Packet Carrying TCP Information
In transport mode, ESP protects the data as shown in the following figure. The shaded area shows the encrypted part of the packet.
Figure 6-4 Protected IP Packet Carrying TCP Information
In tunnel mode, the entire packet is inside the ESP header. The packet in Figure 6–3 is protected in tunnel mode by an outer IPsec header and, in this case, ESP, as shown in the following figure.
Figure 6-5 IPsec Packet Protected in Tunnel Mode
IPsec policy provides keywords for tunnel mode and transport mode. For more information, review the following:
For details on per-socket policy, see the ipsec(7P) man page.
For an example of per-socket policy, see How to Use IPsec to Protect Web Server Communication With Other Servers.
For more information about tunnels, see the ipsecconf(1M) man page.
For an example of tunnel configuration, see How to Protect the Connection Between Two LANs With IPsec in Tunnel Mode.