Forum Discussion

PRM_72806's avatar
PRM_72806
Icon for Nimbostratus rankNimbostratus
Nov 14, 2012

http to https rewrite serverside

Hello,

 

 

Been beating my brain trying to figure this one out (looking at a plethora of examples as well to no avail). In a nutshell here is what we have and what I'm trying to accomplish.

 

 

I have a virtual server setup to listen on all ports (wildcard port). This VS (virtual server) will take a client request and direct it to a specific node (web/app server) on the port it came in on. Also we are doing SSL offloading on the F5 (all data must be encrupted due to the sensitity of the data). I am also interrogating the header in the way in to the F5 to make a determination for which server showuld get this traffic. Here is the simple iRule to do this so far. By the way the iRule works fine until the server responds with a http back to the client (I'll explain below).

 

when HTTP_REQUEST {

 

set lower_host [string tolower [HTTP::host]]

 

set local_port [TCP::local_port]

 

switch -glob $lower_host {

 

"sqrt1.*" {

 

node 10.195.17.130 $local_port }

 

"sqrt2.*" {

 

node 10.195.17.131 $local_port }

 

"sqrt3.*" {

 

node 10.195.17.132 $local_port }

 

"sqrt4.*" {

 

node 10.195.17.133 $local_port }

 

"sqrt5.*" {

 

node 10.195.17.134 $local_port }

 

}

 

}

 

An example flow would be a client coming into the VS with the following URI "https://sqrt1.somedomain.com:9010". Our intent is to perform SSL offload and then direct that traffic to node 10.195.17.130 over port 9010. That all works great until the server responds back to the client using absolute paths with a response looking like this "http:sqrt1.somedomain.com:9010". The server is not aware of the offloading so it incorrectly inserts http: on the way back to the client.

 

 

I am hoping to somehow check that (http: inserted) on the way back to the client and hopefully be able to do a rewrite on the fly. I thought about trying to trap this on the way into the F5 but it appears to be problematic since the traffic is coming in a high port (9XXX) and is not using SSL at that point (where the F5 is set to use SSL). Is there a way to check and rewite on the way from the server back to the client?

 

 

Thanks.

 

Paul M.

 

 

6 Replies

  • This can be done a number of ways but ideally the server configuration should be changed to either use https:// or relative links. Of course that can be difficult so if not you can use a stream profile and an iRule to achieve this. It would also be worth enabling the Redirect Rewrite feature in the HTTP Profile if one is assigned. I've not got time to drop the rule in here as I'm about to travel but if no one else does, I'll do so in around 5hrs.

     

  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Paul,

    I'd try the stream profile first. See Deb's article here for a bit more detail: https://devcentral.f5.com/tutorials/tech-tips/ltm-stream-profile-multiple-replacements-regular-expressions

    I'd suggest in the Stream Profile Target box something like:

    @http://sqrt1@https://sqrt1@ @http://sqrt2@https://sqrt2@ @http://sqrt3@https://sqrt3@ @http://sqrt4@https://sqrt4@ @http://sqrt5@https://sqrt5@ 

    Not the cleanest but should work.

    There'll be a leaner and meaner iRule out there I'm sure but this might get you started.

    Hope this helps,

    N
  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Actually

    How about this:

    when HTTP_REQUEST {
       Disable the stream filter for all requests
      STREAM::disable
    }
    when HTTP_RESPONSE {
    
       Replace http:// with https://
      STREAM::expression "@http://$lower_host.somedomain.com:$local_port@https://$lower_host.somedomain.com:$local_port@"
    
       Enable the stream filter for this response only
      STREAM::enable
      }
     } 

    From: https://devcentral.f5.com/wiki/iRules.STREAM__expression.ashx

    Not got my lab available to test this but give it a go. Hopefully it'll be corrected by fellow DC peeps if incorrect.

    Rgds

    N
  • The request stream filter could be reduced to this;

    
    when HTTP_RESPONSE {
       Replace http:// with https://
      STREAM::expression {@http://@https://@}
       Enable the stream filter for this response only
      STREAM::enable
      }
     }
    
  • Thanks all for the responses to date. I was thinking about either the redirect rewrite functionality as well as the stream profile. I was hesitant to invest too much effort in digging into both of those since I wasn't sure if that was a viable path I should be following down.

     

     

    I did have a question regardnig the redirect rewrite though. I thought this only worked if the server sent a redirect (302, etc.) and that was what triggered some event ? If that is true I don;t think that would work because our servers are not sending redirects just making a bad assumption that there is no SSL and repsonding with http:. I'm pushing our app folks to try to make the relative pathing work on the servers but I can't be too sure that will ever work out.

     

     

    I'll dig into usnig the stream profile (looking at the exmples provided on this thread as well as elsewhere on devcentral as mentioned). Still curious if a rewite redirect profile would work though?

     

     

    Thanks,

     

    Paul

     

     

  • You are correct, Redirect Rewrite only applies to server 3XX redirect responses. Using the Stream profile, just assign the default Stream profile (no values for source or target) to the Virtual Server, create an iRule (as above) and also apply that to the VS and you are away.