Oddities in XForwardedFor?

Hi,

Have you tried to create an iRule to check this ?

for example:

when HTTP_REQUEST_SEND {
log local0. "request from [IP::client_addr] with X-FORWARDED-FOR value: [HTTP::header "X-Forwarded-For]"
}

Then you check your log in /var/log/ltm for the logging result. It should help you !

Ensure to write properly the name of the HTTP header X-Forwarded-For

HTH

I will add this to my rules but I'm not sure when it will happen again.

 

 

Thanks for the suggestion on the diagnostic, though.

 

 

I just don't see how this is happening though. The LTM is directly attached to the ethernet and IP space from the colo -- nothing to get in the way!

It's possible that a client or previous network device is inserting an XFF header. It's also possible that the BIG-IP is inserting an invalid value (bug?). nmenant's example should help you determine what's happening. If you get a runtime error from the example when trying to use the HTTP::header command in the HTTP_REQUEST_SEND event, you could try forcing the HTTP::header command into the clientside context using 'clientside {HTTP::header "X-Forwarded-For"}'.

If you are using the client IP address for anything more important than reporting, it would be good to use an iRule to remove any existing instances of the header you're going to insert before you actually insert the new header. Here's an example:

when HTTP_REQUEST {
    Remove all instances of the custom header
   while {[HTTP::header exists X-Forwarded-For]}{
      HTTP::header remove X-Forwarded-For
   }
    Insert a new XFF header with the client IP address as a value
   HTTP::header insert X-Forwarded-For value [IP::client_addr]
}

Aaron

Thanks, Hoolio! That's neat.

 

 

Now, the question is, how is this different from checking the checkbox in the profile (Insert XForwarded For ...)?

The HTTP profile option would just add a new XFF header with the client IP address. It wouldn't touch any existing XFF headers.

 

 

The XFF header LTM inserts would be the last XFF header in the request and in theory this is the one the server should parse for its logging.

 

 

The iRule ensures that no prior XFF headers are included in the request sent to the server.

 

 

Aaron

Thanks for the quick feedback Hoolio!

 

So, I leave the http profile as it is (with the Insert XFF option enabled) and add this iRule to the virtual server right?

 

 

Manuel

The rule will remove all existing instances of the XFF headers and insert one, so you do not need to enable the XFF option on the HTTP profile.

 

 

Aaron