ASA drops retransmission packets because of alteon randomization

[jeremy.renard]

Hello all,

Here is my problem. I have a customer that is having an ASA 5520. My customer uses an Alteon to load-balance sessions between its servers.

The problem occurs during the establishment of the session. The client sends a SYN packet (seq = 0) to establish the session. The ASA sees the packet and create a session. Then, the Alteon receives the packet and answers with a SYN,ACK (seq = random; ack= 1). That is normal. But, because of the quality of the Internet link, the SYN,ACK is lost. So, the client sends a new SYN packet (seq =0) with the same sequence number. The ASA sees that new packet. As it is having a session for that device, it does not create a new one. Then the Alteon receives the SYN packet. It answers with a new randomized sequence number for the SYN,ACK (seq = ramdom2; ack = 1). When the ASA sees that new packet it drops it because it does not understand why the sequence number is different.

Is there any way to change the behavior of the ASA? Concerning the alteon, the only solution seems to be to disable the "dbind" option. But to do so, my customer needs to use only clientip persistence. And he would prefer to use cookie.

Thanks in advance for your help.

jr

[Panos Kampanakis]

What version are you running on the ASA?

I think you might have some luck with an upgrade to later interims. The ASA behavior was changed to not strictly inspect the TCP-handshake (only) for various reasons. There was also a defect related to it.

You might have luck with versions later than 7.2.4.14, 8.0.4.5 or 8.2.

If you need further investigation of it you can work with TAC to see if something can be done.

I hope it helps.

PK

[jeremy.renard]

Hello,

My customer is running 7.0(5). You are talking about tcp-handshake inspection. Is it the default behavior that has changed or do we need to set a particular configuration? In that case, does it significate that we have less security?

jr

[Panos Kampanakis]

No config is required. The behavior was changed and the ASA. It doesn't strictly inpsect the seq numbers of the TCP handshake packets. That was changed for various valid reasons.

So there is still hope for you since you are running 7.0 :). To verify it you can still look at it with TAC, of course. Or you can try the upgrade to a version that has the change integrated.

PK

[Panos Kampanakis]

And FYI, it doesn't make your set up more vulnerable because the rest of the ASA check are happening and DoS protection can still take place.

PK