Forum Discussion

Gravanda_33760's avatar
Gravanda_33760
Icon for Nimbostratus rankNimbostratus
Feb 18, 2009

Beginner - rewrite and redirect URI question

I need to create an iRule to do a few things:

 

 

1. redirect incoming HTTPS requests to a specific URI

 

2. rewrite the URL to the virtual server

 

 

I have a VS that has 4 nodes in a pool. Incoming requests are HTTPS with SSL off-loading connecting to HTTP:82 on the back-end nodes. I need something that allows me to maintain my HTTPS connection, direct all users hitting this VS to a specific URI, and rewrite the URL so that that VS is always present in the browser. Here is an example of what I need:

 

 

a. Users hits https://somesite.com (a VIP on LTM) using SSL off-loading

 

b. an iRule sends that user to the attached pool using the "/something" URI

 

c. The user sees a redirect in the browser to be https://somesite.com/something ad NOT the real server in the pool on a different port.

 

d. I need to maintain the SSL connection throughout

 

 

Th rewrite and SSL persistance is the biggest thing for me. The VS works great without redirecting to a specific URI. Once I do this with an http::redirect rule, it goes straight to the real server in the back-end and loses my SSL session. (back-end server is HTTP:82).

 

 

Thanx for any help!!

7 Replies

  • Hi,

    I'm not sure I understand what you're trying to do and what's failing. Are you wanting to decrypt the client SSL traffic, inspect/modify the HTTP headers and/or content and then re-encrypt the traffic to the server? Or are you wanting just client side SSL?

    Is the issue that clients are being redirected by the application to an http://... location? If so, you can rewrite the redirects using the HTTP profile option for Rewrite Redirects. Or you could use an iRule:

     
     when HTTP_RESPONSE { 
      
         Check if response is a redirect 
        if {[HTTP::is_redirect]}{ 
      
            Replace http:// with https:// and port :82/ with / 
           HTTP::header replace Location [string map -nocase {http:// https:// :82/ /} [HTTP::header value Location]] 
        } 
     } 
     

    This is a bit of a stab in the dark. So if this doesn't address the issue, can you use a browser plugin like HttpFox for Firefox or Fiddler for IE to see exactly what's failing?

    Thanks,

    Aaron
  • Sorry - I am bad at explaining this stuff.

     

     

    I need to terminiate client-ssl only. Then I need to pass along to a pool of servers that connects on http port 82. When it goes to this pool, I need it to add the URI of /seomthing/ to request. Example:

     

     

    1. User request = https://somesite.com

     

    2. LTM does client-ssl and sends to a pool of servers

     

    3. When teh traffic is sent to the pool of servers, it appends a /something/ URI on the end

     

    4. the LTM rewrites the HTTP request to always have the VIP showing and not the real server in pool

     

    5. The user sees https://somesite.com/something/ in the browser when making the connection and NOT the real server on back end using http port 82.

     

     

    Not sure if an iRule is needed or I can just use a HTTP Class profile? F5 TAC indicated I would need an iRule to accomplish.

     

     

    This make sense?
  • OK.....

     

     

    3. We need to insert /something/ to all requests. The user can see it - not a big deal.

     

     

    4. Maybe I am not thinking correctly about the rewrite. Right now I have a redirect in an iRule. This sends the request right to the real server and it shows that way in the browser. I need the browser to maintain the client-ssl connection to the VIP and to always have the virtual server name in the browser and not the real server. I though this would be accomplished through a rewrite......am I off? Or is this even needed?
  • For background, an HTTP redirect instructs the client to make a new GET request to the redirect URL in the location header. The response status for the redirect is generally a 301 or 302. The browser will show the updated URL in the address bar. Contrast this with LTM receiving a request from the client and rewriting the Host header in the request it proxies to the pool member. The browser address bar would still show the original URL.

     

     

    Maybe it would be easier for you to explain what are you trying to accomplish rather than what you're thinking you want to do in an iRule. Are you trying to have a client connect to an existing web application using a URL and then have LTM rewrite the request to a server that answers using a different hostname? If this doesn't sound correct, can you elaborate on what you're trying to do?

     

     

    Thanks,

     

    Aaron
  • I am trying to have a client connect to a VIP, maintain it's cllient-ssl profile connectivity, and have the URI of /something/ added to the HTTP request.

     

     

    This woudl be for all HTTP requests that do nota already have /something/ in it's request. So, https://somesite.com would actually connect to http://website.com:82/something/.

     

     

    Now.....I also need he /something/ added to EVERY request. Some files/imgaes require the /something/ directory as per code on app.

     

     

    All the while, I need the browser to maintain it's SSL integrity and show the VIP as it's FQDN and not the real server. It can have any URI appended after it, but need to maintain the https://somesite.com throughout.

     

     

    make sense?
  • I think you're confusing the issue somewhat by your request:

    > c. The user sees a redirect in the browser to be https://somesite.com/something ad NOT the real server in the pool on a different port.

    Unless you really screw things up, the user would NEVER see the real server in the URL. In fact, you'd have to go a long way out of your way to make that happen.

    Here's a stab at what I think you're after:

    when HTTP_REQUEST { 
     if { ![HTTP::uri] starts_with "/something" } { 
     HTTP::uri "/something/[HTTP::uri]" 
     } 
     }

    This basically says that if the URI does not begin with "/something", prepend /something to the URI before passing it onto the server. This is transparent to the client. The client never sees /something,