Bug ID 737437: IKEv1: The 4-byte 'Non-ESP Marker' may be missing in some IKE messages

Last Modified: Nov 07, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1

Fixed In:
14.1.0, 14.0.1.1, 13.1.1.4, 12.1.5

Opened: Jul 19, 2018
Severity: 3-Major

Symptoms

The BIG-IP system might fail to re-establish an IKEv1 phase 1 security association (ISAKMP-SA) when the Initiator starts the exchange using UDP port 4500. The exchange progresses to the point of NAT detection, whereupon the BIG-IP system stops using the Non-ESP marker and sends malformatted ISAKMP.

Impact

-- Establishment of an ISAKMP-SA will fail until the peer device switches to UDP port 500. -- The remote peer may send INVALID-SPI messages quoting SPI numbers that do not exist.

Conditions

All of the following must be true: -- The BIG-IP system is an IKEv1 Responder. -- ISAKMP phase 1 negotiation starts on UDP port 4500. -- NAT is detected on only one side during the phase 1 exchange.

Workaround

To help workaround this issue, you can try the following: -- Make sure the BIG-IP system is always the Initiator. -- Bypass NAT. -- Configure both the BIG-IP system and remote peer to use address IDs that are not the same as the IP addresses used in the ISAKMP exchange, thus causing the BIG-IP system to think there is NAT on both sides.

Fix Information

The BIG-IP system now keeps the Non-ESP marker when NAT is detected.

Behavior Change