AnsweredAssumed Answered

Receiving responses with mianpart=null when "Use Keep-Alive" setting is turned off, and SSL termination on the backend load balancer is turned on

Question asked by RF00028 on Oct 25, 2017
Latest reply on Nov 15, 2017 by Stephen_Hughes
  • Comment • 2

#

Hi Community,

 

We're seeing mainpart = null in responses when the "Use Keep-Alive" setting is turned off, while also terminating SSL on a load-balancer (which also scans traffic once traffic is decrypted), and then re-initiates SSL to the backend servers. Has anyone ever seen this behavior before? We are not receiving any SSL or certificate issues that I am aware of.

 

Please note, if we terminate SSL at the servers/pass SSL through the load balancer, and turn the "Use Keep-Alive" setting off, it works just fine. Repeat: We are only seeing the issue when the load balancer is configured to terminate SSL, and the Layer 7 routing assertion "Use Keep-alive" setting is on. This issue is only ocuring in one of 4 of our environments.

 

To better lay out our results, please see the below:

 

  1.       When the Layer 7 points directly to the backend service endpoints/JVMs, Layer 7 sees the correct response from the Applications/JVMs
  2.      When the F5 is configured to pass SSL traffic from Layer 7 through, to the backend accessNS business servers, Layer 7 sees the correct response from the Application/JVMs
  3.      When the F5 is configured to terminate SSL, scan using ASM, then reinitiate SSL to the backend accessNS business servers, we see a response with Mainpart=Null which is causing the application to fail

 

Any thoughts or help is greatly appreciated.

 

Thanks!

Richard Fair

 

Charles_Lilienkamp
Charles_Lilienkamp Employee Oct 30, 2017 2:28 PM
Correct Answer

Richard,

Where are you evaluating or seeing the null response.mainpart? Is it in the policy via an audit? Or is it on the end client? 

 

If its on the gateway I would think we would need to evaluate the policy and the backend requirements possibly including a sniffer to validate if the gateway is getting something back or if for some reason that something in the policy is overwriting the response message. (possibly with a message content variable)

 

But if the gateway has the response.mainpart and its lost at the F5 when its not doing pass-through then that would be a different thought. (maybe some session affinity or something in this area?). But this probably warrants a support case for pursuing.

 

Thanks.

See the reply in context
No one else had this question

Outcomes