Why does XMLHTTPRequests from IE 10/11 fail intermittently against F5 LTM+APM?

Could you clarify a few things?

we see that IE sends the request headers, the VS sends an ACK followed immediately by an ACK/RST before the client sends the POST body.

Does the XHR client send a single HTTP POST request? And if so do you see a full 3-way TCP handshake, and then the HTTP request headers? Is the POST payload not in that first HTTP request?

It turns out to be precluded as a workaround for us because most of this team’s endpoints need to be accessed by both a user’s browser (where an APM session can be expected to be active) and by other application servers (which will not have an APM session)

So you're saying some requests will be coming from agents that haven't authenticated through the access policy? When the XHR requests happen, do you always see an MRHSession cookie in that request? If XHR agents are accessing the APM VIP without an initial browser session, have you made allowances for those agents to handle the initial 302 redirect to /my.policy?

If you run tcpdump on your LTM using

tcpdump -i0.0:nnn -s0 -w /var/tmp/rst.cap host x.x.x.x

where x.x.x.x is your vs address, then view rst.cap in Wireshark, you'll be able to see extra info on the RST packet that will tell you the cause of the RST.

A reset in a TCP capture isn't going to tell you a lot anyway. Because we're talking about layer 7 communications, you need to know what's happening at the application layer. You need to be able to see the HTTP requests, what's in those requests (URIs, headers, cookies, payload), what's in the responses, and who exactly is generating the error. The fact that WEBSSO::disable solves the problem almost indicates that the backend server is sending the error, so you need to be looking at both sides of the proxy.

Unless I've misunderstood, you've indicated that multiple client types access this APM virtual server: browser clients (that authenticate via APM), XHR agents inside the browser clients, and clients that are not browser-based and that do not authenticate. Is this correct? And if so, how do the third set of clients pass through the access policy? And where do the errors occur, and to whom?

Okay, so a few more questions:

1. What is your SSO doing? What type of authentication?

    

2. Is it that the 3rd group doesn't need SSO either? How do they authenticate to the backend servers?

    

3. Can you look at the HTTP requests coming from the XHR agents and see if a) the MRHSession cookie exists when it fails, and b) if there's an Authorization header in the request?

    

Do you think the fact that they're using JWT bearer tokens in the Authorization header might be playing foul with APM's expectations that Authorization should be used differently in an NTLM environment?

I'm suspecting that the Authorization header being sent by the client isn't being overwritten, or potentially is in the wrong way. The WEBSSO profile effectively inserts an NTLM Authorization header into the request stream on the way to the server. If the client is sending its own Authorization header, the WEBSSO may not be overwriting that value.

When we see it fail, it's worth noting that the request isn't technically completed. It's happening during a POST after the headers and before the POST body

Are the POST payloads very large in this case? If you watch the HTTP traffic on both sides of the F5, do you see the POST hitting the server and the server sending an error, or does it fail at the F5 without ever going to the server?

If you can see both sides of the traffic, watch what the client sends, particularly the Authorization header, and see what shows up on the server side. I'm thinking that APM isn't overwriting the client's Authorization header.