ASA5520 killing outbound connections

[rrich]

Hi,

We have a customer that is having problems with one specific client-server application. The app protocol looks kind of like HTTP on the wire, but isn't. The server is on the Internet, and the client is behind the 'inside' interface. Whenever the client has a long download, it will use a single TCP connection, and send polling requests over the wire that look like HTTP GETs. After a period of time, from 5-30 minutes, the ASA generates a RST that kills the connection. This RST is not logged by the pix, even at debug level. This messes up the client badly.

Any ideas where i can look? We've confirmed the PIX is generating the RST b/c the typical TTL at the client is 53, but for the RST its 255 (client is just inside the PIX). Also, when we do a simultaneous capture inside and outside the firewall, the packet only appears on the inside.

In addition to this, there are many anecdotal reports of dropped connections for a variety of applications, many of which use log running connections.

Thanks for any suggestions you can provide!!!

[jim]

WE are having the exact same problem. I have a tac case open but no repsonse as of yet :(

[rrich]

I guess that's good to hear :)

I have packet captures and syslog output if needed. If the ASA was shunting the connection due to triggering some kind of IDS signature, where would that get logged?

[jgervia_2]

Have you checked 'show asp drop' during the connection to see if anything is showing up there?

--Jason

[rrich]

Will do. Thanks for the tip.

[autobot130]

I think you are on the right track. I was troubleshooting an ASA5540 and it automatically SHUN the source IP and doesnt log anything in the debugging syslog.

Try performing a "show shun" and see if theres anything displayed.

Then do a "clear shun" if you see anything.

[swharvey]

This is most likely not related, but I share it for consideration. We run site2site 3des vpn tunnels to our asa5520, and found that voice signal traffic (sccp tcp 2000) would drop at random times for no apparent reason, causing our remote Cisco 7900 phones to reset.

The remedy for us was to turn off the global inspection of the skinny protocol while TAC researches the problem.

Conversely we needed to enable inspection for our SIP voice phone connections to work.

If possible you may wish to scrutinize your inspect statements, and enable/disable for the protocols you are running.

Good luck

[rrich]

Interestingly enough, the vendor had already instructed them to disable the skinny fixup for the same reason. I'll have to review the text config (they use pdm) to see how completely its disabled.

Thanks

[rrich]

Thanks for the tip, we'll try that out.

[bob.penland]

Same exact issues here. We had to disable skinny to get the phones from dropping ever 30 minutes or so.

Also, we have a similiar issue with an application and random disconnects. TAC says there is nothing wrong with the 5520 and application guys say there is nothing wrong with the app.

[swharvey]

The TAC guy on my case is sharp. We needed skinny inspection enabled for IPC softphones coming inbound via our DMZ interface from an ssl vpn appliance, but needed inspection off for our site2site 7900 phones whose vpns terminate on the asa5520.

He wrote a clever inspection class map to enable skinny inspect based on acls for specific voice networks, and disabled it globally on the firewall, so we have a nice work around in place.

In parallel, he got with one of his voice colleagues and they are replicating our issue with our configs in their lab, because they are fairly certain there is a bug.

Credit to Cisco they dug in deep and understand the aspects of the problem, and it's my hopes that the results they acheive will resolve other issues and make the product all the better.

My suggestions are to contact your local account exec and have submit feature requests (e.g. dscp marking for qos, etc.)

At the end of the day though I'll go with Cisco anyday over the other guys.

Good luck!