For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Komtanoo_Pinpim's avatar
Komtanoo_Pinpim
Icon for Nimbostratus rankNimbostratus
Feb 27, 2007

redirect traffic basing on the answer from webserver

Hi,

 

 

My company just bought a 2 bigip boxes. We have a weird requirement to redirect some traffic basing on answer of webserver.

 

It works like this:

 

 

1.Client sends request to url like: http://hostname/get_file/1234.zip

 

2.BigIP forwards the request to 'webserver pool'.

 

3.Webserver pool does some permission checking and responds with the header containing: “X-Reproxy-Static: 1234.zip”.

 

4.BigIP scans the response and forward the request to 'static file pool'.

 

 

I'm not sure if irule can do this. I read the manual and tried to compose the irule but it doesn't work, the output is just the white blank page.

 

 

when HTTP_RESPONSE {

 

if {[string length [HTTP::header X-Reproxy-Static]] > 0} {

 

pool static-pool

 

}

 

}

 

 

------------

 

 

The reason that we need this rule is because those files need user permission checking and we don't want to spoon feed large files by apache webservers, but static webservers in static pool instead. There is a software solution called "PerlBal", it has this feature, but some ppl in my company don't want to have another layer of software to increase the point of failure in our system. It'll be great if irule can handle this.

 

 

Thanks.

 

Kem
application delivery
dev
devops
iRules

6 Replies

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Mar 01, 2007
    Hello Kem,

     

     

    I think the cleanest solution would be to configure the BIG-IP to perform the authentication against the auth server and then only forward authenticated requests to the static content pool. I think that would require licensing the client authentication module for the type of auth you are using.

     

     

    Else, you might be able to use an iRule to send the initial request to the web server pool and insert an encrypted token in a header or cookie if the web server pool responds with a valid response. You could then send a redirect to the client with that token. On subsequent requests you could then check for the valid token before routing the request to the static pool.

     

     

    We created a rule with an encrypted token in the PDF protection example (Click here).

     

     

    Writing such a rule seems to be beyond the scope of what most people around here would do for you in their spare time. You might consider contacting F5's consulting group to get a quote for such a rule if it's not something you're comfortable writing yourself yet.

     

     

    There might actually be a way of forcing the BIG-IP to make a second server-side request if the request if the BIG-IP gets a valid header in the first response, but I don't know if that would be a very clean solution.

     

     

    Lastly, if you know that PerlBal is free and works for this scenario, it might be the simplest solution. Though I'm fairly certain you could do this with the first two methods.

     

     

    Aaron
  • Komtanoo_Pinpim's avatar
    Komtanoo_Pinpim
    Icon for Nimbostratus rankNimbostratus
    Mar 01, 2007
    I've never thought about inserting the encrypted token like that, that's interesting. I could even inserting encrypted token by web pool and do the decrypt on static pool,( by modifying or adding a plugin into static webserver), without touching irule.

     

     

    Multiple server-side requests would be nice, there're many uses I could think of besides this problem.

     

     

    PPl in my company hate perlbal with no reason, they'll love the token solution for sure.

     

     

    Thanks for you time

     

    Kem.
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Mar 01, 2007
    SOL6141 (Click here) has information on using HTTP::retry to make another HTTP request after the initial request has been responded to. If using encoded tokens doesn't pan out, you might be able to use HTTP::retry with your original method of having the BIG-IP make both sets of requests.

     

     

    Aaron
  • Komtanoo_Pinpim's avatar
    Komtanoo_Pinpim
    Icon for Nimbostratus rankNimbostratus
    Mar 01, 2007
    Cool, arkk the solution says, "LTM versions 9.2 - 9.2.3", but what we have is "BIG-IP 9.1.2 Build 40.2", are they compatible ? I haven't tried it since I have to be on site when playing with BigIP according to our paranoid protocol.
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Mar 02, 2007
    HTTP::retry is a feature in 9.2.x and above. I don't think it's available in 9.1.x. You can upgrade from the maintenance release branch (9.1.x) to the latest feature release version, 9.2.5, following the steps in the 9.2.5 release notes. It's a pretty straightforward process of backing up your config to a UCS, and installing the upgrade via an .im file.

     

     

    You can check AskF5 for details on this:

     

     

    SOL2965: Description of the F5 Networks software version number format

     

    https://tech.f5.com/home/solutions/sol2965.html

     

     

    SOL4476: F5 Networks Software Lifecycle Policy

     

    https://tech.f5.com/home/solutions/sol4476.html

     

     

    BIG-IP LTM release notes index

     

    https://tech.f5.com/home/bigip-next/releasenotes/index.html

     

     

    Aaron