Forum Discussion

rws's avatar
rws
New Contributor
10 years ago

How to connect through an SSL-terminated load balancer?

When we use SoapUI 4.5.2 to invoke a Soap web service on a server behind a BigIP load balancer that was recently SSL Terminated, we get an unexpected response:

 

"Your browser does not support JavaScript, Press Continue to proceed...".

 

I use the term "SSL-Terminated" to mean the load balancer completes the SSL session with the client and then creates a new SSL session with the back-end server, instead of passing through the SSL handshake from the client directly to the back-end server. Sometimes this is referred to as "SSL Offloading".

 

Previously, we were able to use SoapUI successfully when going through the same load balancer before it was SSL-Terminated. And we are still able to use SoapUI successfully to connect through load balancers that are not SSL-Terminated, so we have narrowed the issue down to the SSL terminated load balancer.

 

When we use a browser (IE 8 and Firefox 35) to connect via HTTPS to the server through the same load balancer, the response is good, just like it was before the load balancer was SSL Terminated, so we have narrowed the issue down to SoapUI.

 

I will post the full SoapUI Http log below. To summarize it, you will see the following interaction:

(1) POST - request from SoapUI

(2) HTTP 302 Found - response from the BigIP load balancer

(3) GET - from SoapUI

(4) HTTP 200 OK - response from BigIP (this one contains the "Your browser does not support JavaScript..." error message)

 

When testing through a load balancer that is not SSL Terminated, steps (2) and (3) are not found in the SoapUI Http log, just the (1) POST request and (4) HTTP 200 OK response (with good results).

 

In monitoring this test on the back-end server, we determined that the request never reached the server on the back-side of the SSL-Terminated load balancer.

 

If anyone has an idea of how we can configure SoapUI to work around this, it would be greatly appreciated. We are using SoapUI version 4.5.2 and are unable to upgrade at this time, but if that is the recommendation, then we will do that. We have configured all SoapUI projects to use Javascript as the Script Language. We are using SOAP version 1.1 and Java 1.7.0.

 

Thank you!

rws

 

Here is the full Http log from SoapUI, with blank lines and step numbers (e.g. (1)) inserted to identify and separate the different steps:

 

(1)

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "POST /soap/default HTTP/1.0[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "Accept-Encoding: gzip,deflate[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox/36.0[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "Content-Type: text/xml;charset=UTF-8[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "SOAPAction: "SA_SOR_ide_testGetSaSor_Binder_getSaSor"[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "Authorization: Basic xxxxxxxxxxxxxxx[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "Content-Length: 1042[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "Host: ide-is-stg.csd.disa.mil[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "Connection: Keep-Alive[\r][\n]"

Mon Apr 13 17:23:32 EDT 2015:DEBUG:>> "[\r][\n]"

Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> "

[\n]" Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> "[\n]"

Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> "[\n]"

Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> "[\n]"

Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> "000000070[\n]"

Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> "true[\n]"

Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> "[\n]"

Mon Apr 13 17:23:33 EDT 2015:DEBUG:>> ""

 

(2)

Mon Apr 13 17:23:33 EDT 2015:DEBUG:<< "HTTP/1.0 302 Found[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "Server: BigIP[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "Connection: Close[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "Content-Length: 0[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "Location: /my.policy[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "Set-Cookie: LastMRH_Session=0b63f4d6;path=/;secure[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "Set-Cookie: MRHSession=6b9f4feb7c661d196a5960fc0b63f4d6;path=/;secure[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:<< "[\r][\n]"

 

(3)

Mon Apr 13 17:23:34 EDT 2015:DEBUG:>> "GET /my.policy HTTP/1.1[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:>> "Host: ide-is-stg.csd.disa.mil[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:>> "Connection: Keep-Alive[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:>> "User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]" Mon Apr 13 17:23:34 EDT 2015:DEBUG:>> "Cookie: LastMRH_Session=0b63f4d6; MRHSession=6b9f4feb7c661d196a5960fc0b63f4d6[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:>> "Cookie2: $Version=1[\r][\n]"

Mon Apr 13 17:23:34 EDT 2015:DEBUG:>> "[\r][\n]"

 

(4)

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "HTTP/1.0 200 OK[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Server: BigIP[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Cache-Control: no-cache[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Pragma: no-cache[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Content-Type: text/html[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Connection: Close[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Content-Length:394[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Set-Cookie: LastMRH_Session=0b63f4d6;path=/;secure[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "Set-Cookie: MRHSession=7aceb03e03f441e8b9cd41140b63f4d6;path=/;secure[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "[\r][\n]"

Mon Apr 13 17:23:35 EDT 2015:DEBUG:<< "

Note: Your browser does not support JavaScript, Press Continue to proceed...

"

1 Reply

  • rws's avatar
    rws
    New Contributor

    This was what was happening and how we resolved it: The load balancer and the back-end server were not able to agree on a cipher to use for the SSL handshake, so BigIP sent the redirect back to the client. After we enabled a cipher on the server that BigIP was using, the SSL handshake completed successfully, no redirection occurred, the HTTP POST went through to the server successfully, and a normal response was returned to the client. Btw, I used the term "SSL Termination" in this issue, but should have been using the term "SSL Bridging", since we were required to have SSL between the load balancer and the server, as well as between the client and the load balancer.