Forum Discussion

Matt_Elkington's avatar
Matt_Elkington
Icon for Nimbostratus rankNimbostratus
Sep 03, 2007

Using REMOTE_ADDR

This is my first iRule :-), and the first service I have depoloyed behind a LTM.

 

 

We have a web application that uses the REMOTE_ADDR header to preform tracking, originally it was not behind a load balancer, so REMOTE_ADDR reported the actual client IP of the originating http request.

 

 

Now the web server (well web servers now :-) ) are behind a LTM, the REMOTE_ADDR header is reported as the internal floating IP of the LTM pair.

 

 

Now if I apply the following iRule to the service, will it report the correct REMOTE_ADDR, and will it still work?

 

 

when HTTP_REQUEST {

 

HTTP::header insert REMOTE_ADDR [IP::remote_addr]

 

}

 

 

Or would it be better to insert my own header and get the app guys to rewrite their application to use a custom header instead?

 

 

Such as

 

 

when HTTP_REQUEST {

 

HTTP::header insert REAL_CLIENT_IP [IP::remote_addr]

 

}

 

 

Many thanks in advance.

4 Replies

  • The only comment I have is that you may not receive the results you are expecting if the REMOTE_ADDR header already exists in the request.

     

     

    In this case, using "HTTP::header replace" is probably a better idea, to either replace an existing header or insert a new one as appropriate.
  • You can preserve the original client Ip using the x-forwarded-for header...

     

     

    Check this links:

     

     

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

     

     

    http://devcentral.f5.com/weblogs/Joe/archive/2005/09/23/1492.aspx

     

     

    Hope this helps.
  • We had the same problem using weblogic (logging was using the float IP from the F5 Load Balancers). Here's what I used to foward the client IP.

     

     

    when HTTP_REQUEST {

     

    set clip [IP::client_addr]

     

     

    HTTP::header insert WL-Proxy-Client-IP $clip

     

    }

     

     

    Kevin Kirwan
  • Thanks for all your responses.

     

     

    All great ideas, I have ended up using x-forwarded-for as it seems that the developer of the webserver was unable to get the header REAL_CLIENT_IP to display (user error, as from a TCPDump it was in there).