On Wed, Sep 02, 2009 at 05:17:28PM +0200, Alexander Staubo wrote: > On Wed, Sep 2, 2009 at 3:31 PM, Miguel Pilar > Vilagran<[email protected]> wrote: > > I am seeing (with option forwardfor) that HAProxy is replacing > > X-Fowarded-For instead of chaining the proxy chain. I know it's not an RFC > > but the defacto standard is to chain the proxies by appending to the header. > > For my usage it is not necessary but thought I'd point it out (Varnish also > > doesn't handle the header properly but there's a workaround in VCL for it). > > > > Is there a setting for this that I am missing?
Miguel, there might be something special in your config, because "option forwardfor" only appends a header, it does not remove it at all. If you want haproxy to remove the existing header, you have to explicitly tell it to do so using reqidel. > The issue is that X-Forwarded-For can be spoofed by clients, and to > prevent this, the proxy would need a list of upstream IPs for which it > will trust the X-Forwarded-For header and chain it. > > We would very much like this functionality as well. We are in a > situation where we're using HAProxy simply to bounce requests onwards > to another HAProxy (for legacy issues related to IP address > ownership), and we've had to modify our app since the client IPs are > sometimes no longer available. The problem with this header (and a few others such as Via) is that it can appear multiple times, but it must always be chained in the correct sequence. Haproxy respects this. However I've already seen some applications using any random occurrence of the header, instead of the one which corresponds to the proxy position in their architecture. For instance, if there are 2 proxies before the application, the application must use occurrence N-2 where N is the number of occurrences of the header, to find the original client's IP address. Hoping this helps, Willy
