Forum Discussion

GavinW_29074's avatar
GavinW_29074
Icon for Nimbostratus rankNimbostratus
Apr 16, 2012

Random HTTPS Redirects?!?!

Hi there,

I'm starting to configured some services on the F5 which support HTTP. Prior to this, all our services have been over HTTPS.

However I'm having some issues with random HTTPS redirects creeping in, which causes the connection to be rejected.

An example VIP config is:

 (/Common)(tmos) list /ltm virtual GABStaging_RPG.app/rpg.go-aheadstaging.card.co.uk_http
ltm virtual X_RPG.app/rpg.x.card.co.uk_http {
    app-service /Common/X_RPG.app/X_RPG
    destination 172.16.6.115:http
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        Caching_RPG { }
        HTTP_Rewrite { }
        oneconnect { }
        stream { }
        tcp {
            context clientside
        }
        tcp-lan-optimized {
            context serverside
        }
        wan-optimized-compression { }
    }
    rules {
        ProxyPass
        SplunkHTTP
        CacheControl
        CatchErrors
        HeaderStripping
        MaintenancePage
        HandleErrors
        NameVHost
    }
    snat automap
    vlans-disabled
}
 

A request to this VIP returns:

curl -ik http://postgateway.x.card.co.uk/Gateway-web

HTTP/1.1 301 Moved Permanently

Location: https://postgateway.x.card.co.uk/Gateway-web/

Content-Type: text/html; charset=iso-8859-1

Connection: close

Vary: Accept-Encoding

If I connect directly to the back-end application server I don't get redirected to HTTPS...

So the only place I can think this is being introduced is in the ProxyPass iRule, as that's the main rule that responds to the client...

Any ideas????

Cheers

Gavin

  • Just to add to this, I've started doing some packet captures at various points to be 100% sure that it's not an application/app server issue...

     

     

    Running a tcpdump on the back-end application server, I can trace the TCP connection for my GET request, and confirm that the response returned DOESN'T have HTTPS in it.

     

     

    So it looks like the F5 is doing the HTTP>HTTPS redirect...

     

     

    Excerpt from the TCP dump is:

     

    GET /Gateway-web HTTP/1.1

     

     

    User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

     

     

    Host: postgateway.go-aheadstaging.card.co.uk

     

     

    Accept: */*

     

     

     

     

    HTTP/1.1 301 Moved Permanently

     

     

    X-Powered-By: Servlet/2.5

     

     

    Location: http://postgateway.go-aheadstaging.card.co.uk/Gateway-web/

     

     

    Content-Type: text/html; charset=iso-8859-1

     

     

    Transfer-Encoding: chunked

     

     

    Date: Mon, 16 Apr 2012 11:25:29 GMT

     

     

     

     

    0

     

     

    More to follow...

     

     

    Gav
  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Gav

     

     

    Could it be the HTTP_Rewrite profile you've got set on the VIP, rather than the proxypass irule?

     

     

    Rgds

     

    Nathan
  • Posted By nathan on 04/16/2012 04:33 AM

     

    Gav

     

     

    Could it be the HTTP_Rewrite profile you've got set on the VIP, rather than the proxypass irule?

     

     

    Rgds

     

    Nathan

     

    Nathan

     

     

    Didn't realise you could do it on the HTTP profile.. Can't see anything obvious..

     

     

    Relevant config:

     

    gavinw@act-bun-f502(Active)(/Common)(tmos) list /ltm profile http HTTP_Rewrite

     

    ltm profile http HTTP_Rewrite {

     

    app-service none

     

    defaults-from http

     

    redirect-rewrite all

     

    }

     

    gavinw@act-bun-f502(Active)(/Common)(tmos) list /ltm profile http http

     

    ltm profile http http {

     

    adaptive-parsing enabled

     

    app-service none

     

    basic-auth-realm none

     

    lws-width 80

     

    max-header-size 32768

     

    oneconnect-transformations enabled

     

    pipelining enabled

     

    request-chunking preserve

     

    response-chunking selective

     

    }

     

     

     

    Cheers

     

    Gavin

     

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Gav

     

     

    From the rewrite profile it's set at All (the default is none) so it will rewrite as https all "HTTP 301, 302, 303, 305, or 307 redirects" and from your initial post there's a redirect from /Gateway-Web to Gateway-Web/ - i think this askf5 doc will explain:

     

     

    http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6912.html

     

     

    Alongside a tech tip about redirects:

     

     

    https://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/220/Rewriting-Redirects.aspx

     

     

    Rgds

     

    N
  • Ahh, ok... Wasn't aware that that was how the redirect-rewrite functionality worked...

     

     

    Seems like slightly strange functionality if I'm honest...

     

     

    Will review in a bit more detail and see what my options are.

     

     

    Cheers

     

    Gav
  • Ok, think I've got a work-around to this issue...

    As I'm using ProxyPass, I thought it's the logical place to make the correction, rather than relying on redirect-rewrite in the HTTP Profile.

    Below is a patch that I've generated against the v10.5 ProxyPass rule.

    Logic was that the additional correction of the Redirect location value is only required when the rule is not rewriting the Response Payload, as the Location is rewritten already as part of that process.

    Was also only interested in Redirect responses as application links are fine.

    Comments welcome.

    Gav

     @@ -474,6 +476,20 @@
                 log local0. "$log_prefix: Rewriting response content enabled, but disabled on this response."
              }
     
    +  Check for Redirect responses
    + if { [HTTP::is_redirect] } {
    +if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Response is redirect. Checking Location Header."}
    +
    + Get the protocal from the Location header value. 
    +set redirect_proto [string range [HTTP::header "Location"] 0 [expr [string first : [HTTP::header "Location"]] +2]]
    +if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Redirect Proto is: $redirect_proto." }
    +if { not ($redirect_proto == $protocol) } {
    +if { $static::ProxyPassDebug > 1 } { log local0. "$log_prefix: Redirect Proto doesn't match request protocol. Correcting." }
    +HTTP::header replace Location [string map -nocase "$redirect_proto $protocol" [HTTP::header Location]]
    +}
    +
    + }
    +
               Need to explicity disable the stream filter if it's not needed for this response
               Hide the command from the iRule parser so it won't generate a validation error
                 when not using a stream profile 
  • Is it possible that your back end server contains some hard coded https:// ?

     

     

    To debug I'd put in a listener for the 443 and terminate at the F5 and the following iRule:

     

    when HTTP_REQUEST {

     

    set H [HTTP::host]

     

    set U [HTTP::uri]

     

     

    log local0.info "[IP::client_addr] $U"

     

    }

     

     

    I had to so this lately to watch who & what was being called on an old VIP I was decom.

     

     

    This isnt a solution to your problem but it may help with some debug, to track what was asked for over https://
  • Could be useful in some scenarios I think :)

     

     

    As above, think the issue has been tracked down to the redirect-rewrite value in use. By adding the above block to the ProxyPass iRule we're using, the issue has been resolved.

     

     

    Cheers again for assistance.

     

     

    Gav