PIX dropping retransmitted SYN packets?

Discussion in 'Cisco' started by John Caruso, Nov 15, 2006.

  1. John Caruso

    John Caruso Guest

    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
    John Caruso, Nov 15, 2006
    1. Advertisements

  2. John Caruso

    John Caruso Guest

    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 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
    John Caruso, Nov 20, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.