Understanding IKE and IPsec Packet Processing
An IPsec VPN tunnel consists of tunnel setup and applied security. During tunnel setup, the peers establish security associations (SAs), which define the parameters for securing traffic between themselves. (For more information, see VPN Overview.) After the tunnel is established, IPsec protects the traffic sent between the two tunnel endpoints by applying the security parameters defined by the SAs during tunnel setup. Within the JUNOS implementation, IPsec is applied in tunnel mode, which supports the Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols.
This topic includes the following sections:
Packet Processing in Tunnel Mode
IPsec operates in one of two modes—transport or tunnel. When both ends of the tunnel are hosts, you can use either mode. When at least one of the endpoints of a tunnel is a security gateway, such as a JUNOS router or firewall, you must use tunnel mode. Juniper Networks devices always operate in tunnel mode for IPsec tunnels.
In tunnel mode, the entire original IP packet—payload and header—is encapsulated within another IP payload and a new header is appended to it, as shown in Figure 38. The entire original packet can be encrypted, authenticated, or both. With the Authentication Header (AH) protocol, the AH and new headers are also authenticated. With the Encapsulating Security Payload (ESP) protocol, the ESP header can also be authenticated.
Figure 38: Tunnel Mode
In a site-to-site VPN, the source and destination addresses used in the new header are the IP addresses of the outgoing interface. See Figure 39.
Figure 39: Site-to-Site VPN in Tunnel Mode
In a dial-up VPN, there is no tunnel gateway on the VPN dial-up client end of the tunnel; the tunnel extends directly to the client itself (see Figure 40). In this case, on packets sent from the dial-up client, both the new header and the encapsulated original header have the same IP address: that of the client's computer.
 | Note: Some VPN clients such as the dynamic VPN client and Netscreen-Remote use a virtual inner IP address (also called a “sticky address”). Netscreen-Remote enables you to define the virtual IP address. The dynamic VPN client uses the virtual IP address assigned by the Radius server during the Xauth configuration exchange. In such cases, the virtual inner IP address is the source IP address in the original packet header of traffic originating from the client, and the IP address that the ISP dynamically assigns the dial-up client is the source IP address in the outer header. |
Figure 40: Dial-Up VPN in Tunnel Mode
IKE Packet Processing
When a cleartext packet arrives on a Juniper Networks device that requires tunneling and no active Phase 2 SA exists for that tunnel, JUNOS Software begins IKE negotiations and drops the packet. The source and destination addresses in the IP packet header are those of the local and remote IKE gateways, respectively. In the IP packet payload, there is a UDP segment encapsulating an ISAKMP (IKE) packet. The format for IKE packets is the same for Phase 1 and Phase 2. See Figure 41.
Meanwhile, the source host has sent the dropped packet again. Typically, by the time the second packet arrives, IKE negotiations are complete and JUNOS Software protects it—and all subsequent packets in the session—with IPsec before forwarding it.
Figure 41: IKE Packet for Phases 1 and 2
The Next Payload field contains a number indicating one of the following payload types:
- 0002—SA Negotiation Payload contains a definition for a Phase 1 or Phase 2 SA.
- 0004—Proposal Payload can be a Phase 1 or Phase 2 proposal.
- 0008—Transform Payload gets encapsulated in a proposal payload that gets encapsulated in an SA payload.
- 0010—Key Exchange (KE) Payload contains information necessary to perform a key exchange, such as a DH public value.
- 0020—Identification (IDx) Payload.
- In Phase 1, IDii indicates the initiator ID, and IDir indicates the responder ID.
- In Phase 2, IDui indicates the user initiator, and IDur indicates the user responder.
The IDs are IKE ID types such as FQDN, U-FQDN, IP address, and ASN.1_DN.
- 0040—Certificate (CERT) Payload.
- 0080—Certificate Request (CERT_REQ) Payload.
- 0100—Hash (HASH) Payload contains the digest output of a particular hash function.
- 0200—Signature (SIG) Payload contains a digital signature.
- 0400—Nonce (Nx) Payload contains some pseudorandom information necessary for the exchange).
- 0800—Notify Payload.
- 1000—ISAKMP Delete Payload.
- 2000—Vendor ID (VID) Payload can be included anywhere in Phase 1 negotiations. JUNOS Software uses it to mark support for NAT-T.
Each ISAKMP payload begins with the same generic header, as shown in Figure 42.
Figure 42: Generic ISAKMP Payload Header
There can be multiple ISAKMP payloads chained together, with each subsequent payload type indicated by the value in the Next Header field. A value of 0000 indicates the last ISAKMP payload. See Figure 43 for an example.
Figure 43: ISAKMP Header with Generic ISAKMP Payloads
IPsec Packet Processing
After IKE negotiations complete and the two IKE gateways have established Phase 1 and Phase 2 security associations (SAs), the device applies IPsec protection to subsequent cleartext IP packets that hosts behind one IKE gateway send to hosts behind the other gateway (assuming that policies permit the traffic). If the Phase 2 SA specifies the Encapsulating Security Protocol (ESP) in tunnel mode, the packet looks like the one shown below. The device adds two additional headers to the original packet that the initiating host sends.
| Note: For information about ESP, see ESP Protocol. For information about tunnel mode, see Packet Processing in Tunnel Mode. |
As shown in Figure 44, the packet that the initiating host constructs includes the payload, the TCP header, and the inner IP header (IP1).
Figure 44: IPsec Packet—ESP in Tunnel Mode
The router IP header (IP2), which JUNOS Software adds, contains the IP address of the remote gateway as the destination IP address and the IP address of the local router as the source IP address. JUNOS Software also adds an ESP header between the outer and inner IP headers. The ESP header contains information that allows the remote peer to properly process the packet when it receives it. This is illustrated in Figure 45.
Figure 45: Outer IP Header (IP2) and ESP Header
The Next Header field indicates the type of data in the payload field. In tunnel mode, this value is 4, indicating IP-in-IP. See Figure 46.
Figure 46: Inner IP Header (IP1) and TCP Header
Related Topics
- JUNOS Software Feature Support Reference for SRX Series and J Series Devices
- VPN Overview
- Understanding Phase 1 of IKE Tunnel Negotiation
- Understanding Phase 2 of IKE Tunnel Negotiation
- Understanding Hub-and-Spoke VPNs
- IPsec VPN Configuration Overview