websockets TCP RST through ASA+IPS and ACE

msantiveri · ‎01-14-2015

Hello,

We recently deployed a new websockets project within our existing web infrastructure. The websockets traffic (as all the rest of normal web traffic) is crossing an ASA + IPS module where I do NAT and and then is forwarded to an ACE load balancer where two real server are configured in the server farm in active/standby mode (not load balancing) due the websockets nature. Everything seems to work fine but sometimes (once every 4 days or so) and based upon the server logs a TCP Reset gets the application server and bring down the whole application.

It's clear that this application as a bug but I would like to avoid that TCP reset as a workaround while application team fix the ibug as the go-live is soon. Anybody faced this issue and can help me to find where that supposed TCP reset comes from? I didn't get IPS alerts.

Server log:

"Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)"

Thanks,

Miquel

Kanwaljeet Singh · ‎01-15-2015

Hi Miquel,

A packet capture on the server shall show the origin of TCP RST. If you are natting the source traffic then take front end pcaps at front end of firewall as well as at backend and similarly for ACE, to see what is the origin of TCP RST. Normally, it should be from client if it is received on the server. LB's just forward the traffic to the server but it depends and it could be loadbalancer resetting the connection. But we don't have any details to be sure. So packet captures would be our best friend here.

Regards,

Kanwal

Note: Please mark answers if they are helpful.

msantiveri · ‎02-05-2015

Hello and thanks Knawal for your reply.

For anyone that could be interested in the future, the resets came from the load balancer because of the "connection term forced" command in the probe configuration. Those fequent resets sent from the load balancer probe was bringing the service down, the websockets software provider fixed this issue with a patch.

Kind regards,

Miquel