PIX dropping retransmitted SYN packets?

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.

- John

Reply to
John Caruso
Loading thread data ...

Just for posterity's sake (since it looks like I'm not going to get any other answer to this query): this was not reflective of the standard operation of the Linux kernel. Rather, in this particular test configuration the Linux box was receiving ICMP unreachables, and so it was aborting the connection as per section 4.2.9.3 of RFC 1122. When I blocked the ICMP unreachables the Linux box continued retransmitting unacknowledged SYN-ACKs, just as a good TCP stack should. So the Alteon stands alone in its freakish behavior.

It's still the case that a knob on the PIX that would tell it to forward all SYNs--even if they've been SYN-ACK'ed by the server--would get around the Alteon's bad behavior, though. I doubt such a knob exists, but if anyone knows of one (or any other way to achieve the desired behavior) I'd be very grateful to hear about it.

- John

Reply to
John Caruso

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.