Having trouble with HTTP_FORWARDED_FOR iRule.

Enable the HTTP profile's X-Forwarded-For header option, instead of using an iRule. If you still want to use an iRule use below

when HTTP_REQUEST {
     HTTP::header insert CLIENTIP [IP::client_addr]
}

Hi,

 

I was playing with HTTP profile Insert X-Forwarded-For parameter. Be aware that it is adding separate X-Forwarded-For header with client IP.

 

If your request is already containing XFF header then you will have two of them. It's not really good situation for most logging solutions that are using XFF to store client IP.

 

If I am not wrong multiple XFF are allowed but most logging solutions prefer to have one. One XFF can however contain multiple IPs - if traffic is passing via multiple proxies inserting XFF - not 100% sure but first IP from the left is inserted by last proxy before server.

 

If your are using both HTTP profile and iRule to insert XFF you will end up with two XFF instead of one.

 

So stick with one option, of course iRule is most powerful and allow for example:

 

• Remove all existing XFF and insert new
• Remove all existing XFF (preserving IPs reported) and merge those IPs with own IP so you can preserver whole path from client (of course if you can trust proxies between you and client :-)

Piotr

 

Hi,

 

I am repeating myself but would like to make it 100% clear (based on my experience what trouble multiple XFF headers can cause for logging on backend server).

 

HTTP profile approach is quite OK but you need to be aware of those important outcomes:

 

Insert X-Forwarded-For - always adds header not replace/erase XFF already in request. It's not as well follow practice of adding client IP to already existing XFF (why?) like X-Forwarded-For: client, proxy1, proxy2 - opposite that I stated before - each proxy adds previous proxy IP to the end of XFF. So proxy2 in this case will be IP added by proxy3 which IP in turn will be one inserted by BIG-IP in XFF inserted by itself - in my opinion BIG-IP should follow the rule and add IP to already existing XFF - but...

 

So if client request already contains XFF - this header will be preserved, not replaced, BIG-IP will add another XFF and place it as last header. This is not situation healthy for backend logging!

 

Best approach when using HTTP profile is:

 

• Request Header Erase: X-Forwarded-For - removes all instances of XFF from client request
• Insert X-Forwarded-For: Enabled - adds XFF created by BIG-IP

In result it is guaranteed that request reaching backend srv will have only one XFF.

 

To be 100% clear - Accept XFF is only important for another modules/functionalities (Analytics, ASM etc.) it will not change any headers in request.

 

Good examples of iRules for XFF manipulation can be found here

 

Piotr