Forum Discussion

solaikumar_1217's avatar
solaikumar_1217
Icon for Nimbostratus rankNimbostratus
Feb 13, 2016

SSL Offloading not functioning properly for SharePoint 2013

Dear All,

 

We have a share point application which needs to be load balanced through F5. The applications have been configured using F5 verified iApp and the same is working well when we run as HTTP in both front & back end . Since the requirement is to do the SSL offloading , we have recreated the same using iApp and we realized some application accessibility issue .there are some HTTP references inside the webpage itself and most of the images are not loaded at the client end.

 

When we inspect partially loaded webpage at client browser, have received Mixed content warning . Do you have any suggestion regarding this ?

 

I believe that iApp is designed in such a way that it should support smooth integration of most of the complex applications in F5.

 

3 Replies

  • It sounds like you're experiencing the "reverse proxy problem". Essentially, internal applications don't know that they're being proxied, so they return localized URLs, that the client inevitably cannot reach. Generally the best way to handle this issue is with a rewrite function. In your case it may just be that HTTP:// URLs need to be rewritten to Apply a generic STREAM profile to the virtual server and this iRule:

    when HTTP_REQUEST {
        STREAM::disable
        HTTP::header remove Accept-Encoding
    }
    when HTTP_RESPONSE {
        if { [HTTP::header exists Location] } {
            HTTP::header replace Location [string map -nocase {"http://" "https://"} [HTTP::header Location]]
        }
        if { [HTTP::header Content-Type] contains "text" } {
            STREAM::expression {@http://@https://@}
            STREAM::enable
        }
    }
    

    More information on the STREAM command can be found here: https://devcentral.f5.com/wiki/iRules.STREAM.ashx

  • Leave the values empty. The iRule provides the match/replace information. You can actually just use the default (parent) STREAM profile here.

     

  • Interesting. Well, the next step requires some additional troubleshooting. You need to know exactly why requests are failing, and to do that you need a client side capture. Using something like HTTPwatch or Fiddler, you need to watch the client side of the exchange. At some point the browser will attempt a request that will fail, which will very likely be because the URL is wrong. How the URL is wrong, and which previous response gave it that wrong URL are important. Find that and we can develop a better solution to the problem.