Proxy does not reset rogue TCP ACK and cause intermittent Network error (tcp_error) exception
Last Updated May 13, 2017
If a server happens to have a pre-existing TCB in that would match the same inbound SYN from Blue Coat, the server (per RFC 793) replies with a TCP ACK indicating that an existing TCB is present.
The following packet behavior is documented in RFC 793 as Figure 10. The figure labels TCP host A as 'crashing' since the re-use of a source port on specific 5-tuple should not occur, but if host were to CRASH and not maintain prior awareness of TCB states, it may re-use a port quicker than it should. TCP has a mechanism to deal with rapid re-use and it is outlined in the Half-Open Connection Discovery portion of the RFC.
Packet #4 is the TCP ACK noted in the description above. Upon receipt of out-of-sequence ACK from TCP host B, it is important to note that the stack of TCP A responds with a TCP RST packet forcing the TCB on Host B to abort and clear out, thereby allowing the following SYN to result in a SYN-ACK from TCP Host B and successful connection establishment.
However, the ProxySG appliance does not reset this rogue ACK, which could, depending on the network environment, cause intermittent Network error (tcp_error) exception.
This issue has been fixed in SGOS 126.96.36.199 or later
This issue is fixed in SGOS 188.8.131.52 and later.
Imported Document ID: 000021700
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe