Last updated on: June 16 2024.

IPsec Security Association

This page explains what an IPsec Security Assocition (IPsec SA) is and how to interpret the display of them.

To display IPsec SAs, refer to the View IPsec Security Association page.

For the config behind IPsec SAs, refer to IPsec-Policy Config Explained

TL;DR

The SA state must be “mature” and survive for the duration of at least the “soft lifetime”.

IPsec SA Purpose

An IPsec SA is a definition of the parameters for encapsulating and sending a packet between two endpoints. The SA describes the encapsulating IP protocol, commonly ESP. The SA describes the authentication and encryption ciphers and more.

An SA is not a tunnel, it describes a tunnel flow for one direction.

In order for an SA to exist, two peers must negotiate a set of mandatory parameters via ISAKMP. If the mandatory parameters do not match, the SA negotiation will fail and mostly likely start again soon after.

Understanding the Output

Here is an example IPsec SA on a BIG-IP.

IPsec::SecurityAssociations
172.16.1.1 -> 172.16.2.1                   
----------------------------------------------------------------------------------------------------
  tmm: 6                                   
  Direction: out;  SPI: 0xbec2922(200026402);  Policy ID: 0xe991(59793)
  Protocol: esp;  Mode: tunnel;  State: mature   
  Authenticated Encryption : aes-gcm128    
  Current Usage: 3634816 bytes             
  Hard lifetime: 24158 seconds; unlimited bytes  
  Soft lifetime: 7646 seconds; unlimited bytes   
  Replay window size: 32                   
  Last use: 06/13/2024:04:40                                               Create:  06/12/2024:11:23
Field Example Value Info
IP to IP 172.16.1.1 -> 172.16.2.1 172.16.1.1 sends packets over the tunnel to 172.16.2.1
tmm 6 Every IPsec SA is owned by one TMM. In this case the owning tmm is #6.
Direction out This SA is for transmitting (not receiving) packets over the tunnel.
This means 172.16.1.1 must be the local peer IP.
SPI 0xbec2922(200026402) The SPI, used to identify each ESP flow, is 0xbec2922 in hex and 200026402 decimal. Logs primarily reference the hex value.
Policy ID 0xe991(59793) The index number of the configured policy. This does not change. This ID is referenced by the traffic selector show output.
Protocol ESP This can be ESP (Encapsulating Security Payload) or AH (Authentication Header). AH is inadvisable and rarely used.
Mode Tunnel This can be tunnel or transport. Even when an interface mode tunnel is used, the output will say tunnel. Transport mode is inadvisable and rarely used.
State Mature Mature indicates the SA is established and usable. Larval means the tunnel setup is in progress. Dying means that the SA is about to be deleted (see "Soft lifetime").
Authentication Encryption aes-gcm128 This can be any number of ciphers. In this case aes-gcm128 is used for the authentication of the ESP payload.
Current Usage 3634816 The number of bytes handled by this SA.
Hard lifetime 24158 The number of seconds this SA has left to live. When the counter expires the SA is deleted. "unlimited bytes" indicates that there is no limit related to the amount of traffic (lifebytes) the SA can carry before it must be replaced. Lifebytes are a configuration option as with lifetime.
Soft lifetime 7646 The number of seconds left before IPsec tries to negotiate a replacement SA. SAs must be replaced before the hard lifetime expires in order to ensure unbroken tunnel connectivity.
Replay window size 32 There is a mechanism to prevent replay DOS attacks, since decryption is compute heavy. This value specifies the maximum out of sequence number. Sequence numbers normally go up by one for each packet, meaning in a practical sense up to 32 previous packets could be replayed without being discarded by the IPsec peer.
Last use 06/13/2024:04:40 The last time this SA was used to handle a packet.
Create 06/12/2024:11:23 The date and time this SA was established.

Common Problems

If State is always in larval, the SA is failing to negotiate. When the BIG-IP knows that is must start a tunnel, it will create a placeholder IPsec SA and look for an ISAKMP SA to leverage. Therefore, the IPsec SA technically appears before the ISAKMP SA, but no actual negotiation of the IPsec SA can happen until the ISAKMP SA goes up. If the IPsec SA is always in a larval state, check that the ISAKMP SA is establishing.

If the SA state is mature, is the SPI change every few minutes? Causes:

  1. In rare cases, it is possible for one end of the IPsec tunnel to think the tunnel is up after a negotiation, but the remote peer has failed at the end. The remote peer may keep trying to start the tunnel.

  2. Network connectivity problems can lead to Dead Peer Detection (DPD or liveness checks) to determine the tunnel is dead.

  3. Problems sending ESP packets, for example getting eaten by a firewall, can cause some vendors to idle out the tunnel and start it again.

If the SA state is mature, but “Last use” shows nothing is happening on this SA, this points to a problem getting packets into the tunnel, rather than a problem with the SA or tunnel negotiation.

Is the lifetime or lifebytes too low?

Read the ESP Protocol page and verify whether ESP packets are passing between the two peers. Capture the packets to verify if necessary. Look at the virtual server and traffic selector counters.

Top | Flowchart | Contents