0

Problem

We have a web application that is used by many thousands of users. However, since the latter part of Jan 2020, a tiny fraction of clients (but still a significant number) have reported a similar problem.

  • unable to execute an AJAX POST (application/json)
  • is able to execute AJAX GETS
  • is able to execute AJAX POSTS (application/x-www-form-urlencoded)
  • not tied to a specific browser
  • affects all users in the client's network

The web method (ASP.NET MVC) doesn't require the user to be authenticated, and doesn't require HTTPS.

Analysis on CLIENT

Using Google Chrome's Network Tab, we captured the data as an HAR file. For the blocked requests we see:

"timings": {
    "blocked": 0.06441399999312125,
    "dns": -1,
    "ssl": -1,
    "connect": -1,
    "send": 0,
    "wait": 0,
    "receive": 0,
    "_blocked_queueing": -1
},

I interpret this as saying that this had to wait for other AJAX calls to complete (it was blocked) but that it never got around to sending the Request.

Analysis on Web Server

We installed WireShark on the webserver and captured the traffic whilst recording the HAR file.

The client (source) is described as Cisco.

For the failed request, we see the following frames:

1. Client->Server: 18497 -> 80 [SYN, ECN, CWR] 
2. Server->Client: 80 -> 18479 [SYN, ACK, ECN] 
3. Client->Server: 18497 -> 80 [ACK]
4. Client->Server: 18497 -> 80 [RST, PSH, ACK]

The first three frames seem pretty similar to the successful Posts, but here we then get the Client returning an [RST, PSH, ACK], where the successful ones don't.

I had a look 2. (Server->Client) and for the successful and failure cases, these seem pretty similar, though I confess that I'm a .NET software developer and I'm not overly familiar with the TCP level...

Investigating the [RST, PSH, ACK] from the client, I do see the following under the Flag section:

[Expert Info (Warning/Sequence): Connection reset (RST)]
    [Connection reset (RST)]
    [Severity level: Warning]
    [Group: Sequence]
.... .... ..0. = Syn: Not set
.... .... ...0 = Fin: Not set
[TCP Flags: .......APR..]

I have no idea what causes this request to be killed: is this something we're doing wrong on our Server/LoadBalancer/Firewall to cause the Client to reset the connection, or is this something incorrectly configured on the Client's side?

DrGriff
  • 99
  • 1
  • 1
  • 1
  • Just because you see a RST from the client on a server capture doesn't mean the RST originated from the client. You need to do a correlated packet capture on both a client and the server. – Greg Askew Feb 13 '20 at 12:58
  • @GregAskew - If it's something "in between" the two end points, then I'm guessing we're looking at firewalls and loadbalancers. Anything else that might be firing the RST? And if we have multiple "suspects", then what would be the most likely culprits (just trying to prioritise). THanks – DrGriff Feb 13 '20 at 13:13

0 Answers0