Forum Discussion

Dean_Brown_01_1's avatar
Dean_Brown_01_1
Icon for Nimbostratus rankNimbostratus
Aug 20, 2013

Can Big-IP Handle Outside Site redirects transparently to client

I am receiving a web client url that gets redirected to an outside site under certain circumstances. That outside site then returns a redirect request (302) that would ordinarily be returned back to the web client to handle. Is there a way for the Big IP to handle the redirect request, then return the redirected page back to the web client?

 

Here is the irule I have for the vs that gets the url request. I'm not sure what to put in the second HTTP::is_redirect section. I added an empty HTTP::is_redirect in the HTTP_REQUEST section just in case the new redirect triggers another HTTP_REQUEST. Not sure that's right either.

 

when HTTP_REQUEST { if { [HTTP::is_redirect] } {

 

} else { log local0. "MS365_Redirect virtual server" HTTP::redirect "https://login.microsoftonline.com"

 

} }

 

when HTTP_RESPONSE { log local0. [HTTP::status] if { [HTTP::is_redirect] } { What goes here to make new redirect? } }

 

9 Replies

  • after the 1st http redirection, client and outside site will communicate to each other directly (i.e. no bigip). so, i think you may try to rewrite uri instead of redirection. anyway, you may also have to rewrite response if outside site domain name is embedded in the payload.

     

    just my 2 cents.

     

  • A couple of considerations.

    1. The [HTTP::is_redirect] command detects the presence of a 30x status message in a response. It has no meaning in an HTTP request.

    2. If the 30x response is not flowing through the BIG-IP, an iRule can't see it. In other words, if the outside site issues a redirect, the BIG-IP would not see it.

    3. If capturing redirects in a response, there are a few things you can do, but probably one of the easiest is to simply rewrite the Location header. Example:

      when HTTP_RESPONSE {
          if { [HTTP::is_redirect] } {
              HTTP::header remove Location
              HTTP::header insert Location "https://www.somwehere.else.com"
          }
      }
      
  • ok, after thinking about it further, I agree that the client will be pointing to an outside site after the redirect anyway. So that breaks our "container" in that all web client requests must go through our Big-IP (mobile client, controlled access).

     

    An option that I was thinking about was mapping all the https://www.microsoftonline.com urls coming back to our https://mydomain.ms/xxx. Then when the user clicks on the web page URL, it comes back through our Big-IP, where I can then route it and remap it back to the microsoftonline.com url and redirect it to the site. Does that sound feasible? I thought we could modify the HTTP stream going through the Big-IP.

     

  • Does that sound feasible? I thought we could modify the HTTP stream going through the Big-IP.

     

    yes, i understand it can be done. to modify header, HTTP::uri and HTTP::header can be used. for payload, you may try stream profile.

     

    LTM stream profile: Multiple replacements & regular expressions by Deb Allen

     

    https://devcentral.f5.com/articles/ltm-stream-profile-multiple-replacements-regular-expressions

     

  • So essentially load balance the remote microsoftonline.com site through your BIG-IP? Yes you can. You need a gateway configuration and route to the Internet from the BIG-IP, and DNS configured if you're going to send the traffic via hostname vs IP/pool. Then if URI starts_with "/ms365", pool msonline_pool...

     

  • Is there a way to modify the HTTP request to make my virtual server the client?

     

    An HTTP redirect is simply a RESPONSE message type, with a 30x status code (301, 302, etc.), and a "Location" header that tells the client browser to go somewhere else. Example:

     

    HTTP/1.0 302 Found
    Location: http://www.somewhere.else.com

    In order for the VIP to be the client, you have a few options:

     

    1. Load balance the traffic to a pool or node. The BIG-IP isn't technically "the client", but because it's a full proxy, the connection is at least discreet. The real client is still in control of making the requests.

       

    2. A sideband call. This is where the BIG-IP is truly the client. A sideband call is a "blocking" request mechanism used in iRules to send data out somewhere, get a response, and then finish processing the configured request (send to pool). In this case the VIP/iRule is in charge of making the request, so anything you need from the client (user/pass), you need to get beforehand. You also won't expect the client to see the responses from the remote site (ie. a logon page).

       

    3. If we're JUST talking about a remote logon page, you can also use Access Policy Manager (APM) module to either a) call the remote logon page for you, or b) SSO to the remote logon page.

       

  • Thanks Kevin. Guess I was looking for option 4. Receive HTTP response, modify the destination url, and forward it to the new URL address, and then get responses back through the Big-IP to modify the stream and return to the client.

     

    Haven't found that option anywhere. :(

     

  • Well, you can do that actually. The only significant problem so far is that you're missing a request or two. If you take the response from one server (flowing back through the BIG-IP), and redirect it away from the client to another remote host, that host is expecting a request - not a response. If you know what the request is, you can write your own and send it. I like to think of it like a ping pong match - each request is followed by a response. You can't have a response without a request and a response would only come AFTER a request. Technically speaking these are different message types in HTTP, so you'd be sitting in the middle (at the net) proxying that information and potentially adding or removing data, and maybe even tilting the table. But you must absolutely keep the momentum going.

     

  • For the most part you're going to use a lot of the HTTP commands and events:

     

    HTTP iRules wiki

     

    Happy to help of course, but still struggling to understand the intended data flow.