Bug ID 585485: inter-ability with "delete IPSEC-SA" between AZURE, ASA, and the BIG-IP system

Last Modified: Sep 13, 2023

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1

Fixed In:
13.0.0, 12.1.2, 11.6.1 HF2

Opened: Apr 05, 2016

Severity: 3-Major

Symptoms

Some IKEv1 IPsec vendor implementations (for example Cisco ASA) send a delete SPI message for an IPsec-SA and expect that the sibling IPsec-SA (the SPI in the other direction) will also be deleted by the peer. The BIG-IP system sends and expect messages with two SPI's inside.

Impact

An IPsec tunnel goes down and in some situations may not renegotiate while the BIG-IP believes that the outgoing SPI is still active. The tunnel will stay down until the lifetime of the outbound SA expires.

Conditions

An IPsec tunnel between a BIG-IP system and some other vendor may experience this. Azure and Cisco ASA are two such vendors.

Workaround

Delete the outbound SA from the BIG-IP using the tmsh command by specifying the related SA: (tmos)# delete net ipsec ipsec-sa ? Properties: "{" Optional delimiter dst-addr Specifies the destination address of the security associations spi Specifies the SPI of the security associations src-addr Specifies the source address of the security associations traffic-selector Specifies the name of the traffic selector

Fix Information

The BIG-IP system will remove both SAs associated with one traffic-selector (tunnel) when the peer sends a delete SPI message.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips