Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
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, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 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, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2
Fixed In:
16.1.0, 15.1.4.1, 14.1.4.5, 13.1.5
Opened: Aug 14, 2020 Severity: 4-Minor
As the BIG-IP system attempts to open a TCP connection to a server-side object (e.g., a pool member), retransmissions of the initial SYN segment incorrectly use a non-zero acknowledgement number.
Depending on the specific server implementation, or the security devices present on the BIG-IP system's server-side before the server, a SYN containing a non-zero acknowledgement number may be rejected. In turn, this may cause connections to fail to establish.
This issue occurs when the following conditions are true: -- Standard TCP virtual server. -- TCP profile with Verified Accept enabled. -- Receipt of the client's ACK (as part of the client-side TCP 3-way handshake) is delayed. Due to Verified Accept being enabled, this delay causes the BIG-IP system to retransmit its SYN to the server until the client's ACK is received.
If compatible with your application and specific needs, you can work around this issue by disabling Verified Accept in the TCP profile.
SYN segment retransmissions now correctly use 0 as the acknowledgement number.