I want to verify the behavior of a PIX (running 6.3(5)) during the TCP 3-way handshake, when the server's initial SYN-ACK is lost after it traverses the PIX. The issue appears to be that the PIX doesn't forward retransmitted client SYN packets to the server as long as the PIX itself has seen the SYN-ACK from the server. Here's a diagram what I'm talking about:1) client's SYN --> PIX --> server 2) server's SYN-ACK --> PIX --> (lost somewhere on the Internet) 3) client's retransmitted SYN --> PIX --> (dropped by the PIX)
So in step 3, when the client retransmits its SYN (because it never saw the SYN-ACK from the server), the PIX does *not* forward this retransmitted SYN on to the server. Is this an accurate description of PIX behavior? And more importantly, if it is, is there any way to get the PIX to forward *all* SYN packets, whether or not it's already seen a SYN-ACK from the server for the SYN in question?
It's possible that this is legal behavior for the PIX, because by virtue of having seen the server's SYN-ACK it knows that the server received the SYN-- so why retransmit that SYN? Well, the reason why is that various TCP stacks don't retransmit SYN-ACKs unless they receive a retransmitted SYN from the client. I'm not sure if this is legal (as per RFC 793, section 1.5) but it's apparently pretty common; I'm running into it in particular with an Alteon load balancer, but it also happens with a Linux server (2.6 kernel). So the fact that the PIX drops retransmitted SYNs if it's already seen the server's SYN-ACK is causing connection timeouts to occur where they wouldn't otherwise occur.
BTW, this doesn't appear to be related to the embryonic connection limit.