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