Forum Discussion

gusf5_117081's avatar
gusf5_117081
Icon for Nimbostratus rankNimbostratus
Feb 14, 2014

X-forwarded-for solution IIS 7.5 Aplication Pool, CMS application

Hello,

 

We have a F5 Load Balance solution set up in passthrough mode. In the VS we have the HTTP profile enable with X-Forward-For and is logging the right information in the IIS Logs. We also have a CMS application that connects to the application pool in IIS 7.5 to get analytic information and does not know how to read the X-Forward-For header information. The only solution I can think of is to re-build the F5 enviroment in routed mode...is there anything that can be done in iRules or VS settings to log the X-Foward-For information in the client IP field inside the HTTP header?

 

Thanks

 

application delivery
deployment
devops
iRules
LTM
microsoft

4 Replies

Sort By
  • IheartF5_45022's avatar
    IheartF5_45022
    Icon for Nacreous rankNacreous
    Feb 14, 2014

    Hi gusf5,

    Are you just looking for an alternate header in which to place your source IP?

    when HTTP_REQUEST {
    HTTP::header insert Client-IP [IP::remote_addr]
}

    Another option if you would like to preserve your source IP but you still want to use oneconnect, is to use a oneconnect_host profile which is based on oneconnect but uses a 255.255.255.255 mask. That way you can trust your source IP and don't need a header at all.

    • Arie's avatar
      Arie
      Icon for Altostratus rankAltostratus
      Feb 17, 2014
      In keeping with the RFC you ought to use the prefix "X-" for custom headers.
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Feb 18, 2014

    Presumably you've applied a SNAT, and using the XFF header as a way to get the client's true address to the web server. Short of disabling SNAT (and configuring the environment in such a way that SNAT isn't necessary), you must find some place to put this information that an application can read. A routed mode configuration would probably be the simplest, if that's one of the only ways your CMS app can see the address, but there are still other options - all highly dependent on what the CMS app is capable of:

     

    1. The TCP::options command set allows you to read/write information into option 28 of the TCP packet.

       

    2. You could potentially tack on query string values or embed the values in request or response content.

       

    Can you elaborate on how the CMS app interacts?