Forum Discussion
Matt_Elkington
Nimbostratus
NimbostratusUsing 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.
- AaronJB
SIRT
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. 
Jose_Santiago_OYou 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.
kckirwan_49724We 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
Matt_ElkingtonThanks 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).
