Proxy does not reset rogue TCP ACK and cause intermittent Network error (tcp_error) exception


Article ID: 168167


Updated On:


ProxySG Software - SGOS


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.

  TCP A                                           TCP B

  1.  (CRASH)                               (send 300,receive 100)

  2.  CLOSED                                           ESTABLISHED

  3.  SYN-SENT --> <SEQ=400><CTL=SYN>              --> (??)

  4.  (!!)     <-- <SEQ=300><ACK=100><CTL=ACK>     <-- ESTABLISHED

  5.  SYN-SENT --> <SEQ=100><CTL=RST>              --> (Abort!!)
  6.  SYN-SENT                                         CLOSED

  7.  SYN-SENT --> <SEQ=400><CTL=SYN>              -->

                     Half-Open Connection Discovery

                               Figure 10.

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 or later


This issue is fixed in SGOS and later.