SSL Offloading not working as expected

Try to change the setting for Redirect Rewrite in your HTTP Profile from "None" to either "All" or "Matching" and test.

Thanks for the suggestions. I tried the following:

• Applied the default stream profile to the 443 virtual server
• Applied the following iRule

when HTTP_REQUEST {
    Disable the stream filter for all requests
   STREAM::disable

    LTM does not uncompress response content, so if the server has compression enabled
    and it cannot be disabled on the server, we can prevent the server from
    sending a compressed response by removing the compression offerings from the client
   HTTP::header remove "Accept-Encoding"
}
when HTTP_RESPONSE {
    Check if response type is text
   if {[HTTP::header value Content-Type] contains "text"} {

    Replace http:// with https://
   STREAM::expression {@http://@https://@}

    Enable the stream filter for this response only
   STREAM::enable
   }
}

• Updated the HTTP Profile, Redirect Rewrite from "None" to "All" to "Matching" to "Nodes"

None of these combinations has resolved the issue.

Packet capture is my friend...

Navigating to the 443 VS gets you to the logon page successfully. Entering a username/password takes you to a blank page w/o errors.

can you try http analyzer tool? just wondering what the blank page request is.

HttpFox

can only echo what nitass is saying, just applying this or that without knowing why isn't the way to go in my opinion.

The 'blank page' has the following content:

  
  Halogen Software
  
  
  

  
    
    
    
  

Here are the responses from the back-end server from the following HTTP POST:

POST /Halogen/eAppraisal/workflow/security HTTP/1.1
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://agtsthalo.altagas.ca/Halogen/welcome/login.jsp
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; InfoPath.3; .NET4.0E)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: agtsthalo.altagas.ca
Content-Length: 92
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: f5_cspm=1234; JSESSIONID=D09979723FE0DFB6601674B3E1C5327B; bbbbbbbbbbbbbbb=NEEIMBEIKDAJONJDGJKOMKEICNNGHOBHCGFEPHIMBMBDEPLGFKJKJJEKOPEAHBFJNGHIFDCLEPCGEPHNJJAFCEDAKJHPKIEHPCLHLHCJFBIMMPEGGNFOLOKDJFLBPPDO; f5_cspm=1234; __utma=224565450.1383843014.1418246750.1422040049.1430250792.7; __utmz=224565450.1418246750.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); aaaaaaaaaaaaaaa=NMEAJBPFHFANLDLOKBMBHMJEBILLDMBGMAINABGCMIPCNHIPFAEOIMMKKDCAGGFEAIANFKPBKNMIDDHKAFLCHNHKIPOHOHEECPBFHIGHHILAJHNOEPLMKMKNOHMJEKBK

halogenLoginID=XXXXXXXX&halogenLoginPassword=XXXXXXXX&halogenLoginPassword-text=Password

Failed logon (VS x.x.x.x:443 w/ SSL Client Profile):

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
X-UA-Compatible: IE=EmulateIE8
Content-Length: 0
Date: Fri, 29 May 2015 17:42:09 GMT

Successful logon (VS x.x.x.x:80 w/o SSL Client Profile):

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
X-UA-Compatible: IE=EmulateIE8
Set-Cookie: JSESSIONID=E5C7BBAF8B90AB619472E7594BBDC79B; Path=/Halogen/; HttpOnly
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 29 May 2015 17:42:56 GMT

1402
...

The obvious differences are the Set-Cookie, Content-Type, and Transfer-Encoding headers received on a successful logon which are not present on a failed logon.

Failed logon (VS x.x.x.x:443 w/ SSL Client Profile):

i might be lost but isn't post request same on both virtual servers? why one is success but the other one fails?

Failed logon (VS x.x.x.x:443 w/ SSL Client Profile):

i might be lost but isn't post request same on both virtual servers? why one is success but the other one fails?

I used Fiddler to capture 3 different scenarios:

1. POST to VS x.x.x.x:443 w/ Client SSL Profile
2. POST to VS x.x.x.x:80
3. POST to back-end server y.y.y.y:8080 - back-end server w/o encryption

The results are identical, with the exception:

1. POST to VS x.x.x.x:443 has a header of "Cache-Control: no-cache"
2. POST to VS x.x.x.x:80 has a header of "Pragma: no-cache"
3. POST to back-end server y.y.y.y:8080 has a header of "Pragma: no-cache"

The latter 2 provide a successful logon and the application functions as expected.

Reading link text section 14.32 states:

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives.

Pragma            = "Pragma" ":" 1pragma-directive
pragma-directive  = "no-cache" | extension-pragma
extension-pragma  = token [ "=" ( token | quoted-string ) ]

When the no-cache directive is present in a request message, an application SHOULD forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive has the same semantics as the no-cache cache-directive (see section 14.9) and is defined here for backward compatibility with HTTP/1.0. Clients SHOULD include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant.

Pragma directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives might be applicable to all recipients along the request/response chain. It is not possible to specify a pragma for a specific recipient; however, any pragma directive not relevant to a recipient SHOULD be ignored by that recipient.

HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". No new Pragma directives will be defined in HTTP.

Note: because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response

Why would the client browser use "Cache-Control" with SSL connections and "Pragma" with non-SSL connections? This seems to be consistent with IE10/Firefox/Chrome/Opera.

Thoughts?