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:
Any thoughts or help is greatly appreciated.
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.
When we see issues with re-initializing SSL after the Gateway, the issue normal is linked back to a client mutual authentication problem.The SSL can be re-initialized but the back end may be expecting the initial Client Mutual which is no long occurring.
Director, CA Support