It would be nice if in mod_remoteip, you could specify a list of headers and not just one. suggestion is to allow multiple parameters to RemoteIPHeader, eg: RemoteIPHeader X-Forwarded-For, X-Forward RemoteIPTrustedProxy 10.0.2.0/24 RemoteIPTrustedProxy gateway.localdomain Headers would preferably to be checked for in the provided order. Use case example is : 1. If there is X-Forwarded-For header use it (as the traffic is through a forward proxy, such as squid) 2. Otherwise if there is X-Forward header use it (traffic is direct, but via a SNAT-ing content switch) 3. Otherwise use the connection's REMOTE_ADDR as usual (traffic is direct - and not via a SNAT-ing content switch OR a forward proxy) In the current mod_remoteip, you can only pick one header - the different headers in our case are created by different devices. The content switch makes X-Forward with a single ip address and the forward proxy adds X-Forwarded-For in the usual manner. Both headers rewrite fine using the existing code, except i must choose to rewrite either the content switch header OR the forward proxy header, but not both.
I could use this too
Mike, this statement confuses me... /* If no RemoteIPInternalProxy, RemoteIPInternalProxyList, RemoteIPTrustedProxy or RemoteIPTrustedProxyList directive is configured, all proxies will be considered as external trusted proxies. */ mod_remoteip should not be translating any addresses from an unrecognized proxy. These untrusted addresses continue to live in the header they were presented in (e.g. X-Forwarded-For) for modules to inspect, but must not enter the authnz scheme of httpd. Is this an issue with the module's logic (original, or as-patched), or just a mis-statement?
Ignore the earlier comment #2, I meant to direct that to #55962
This is a good suggestion, but I think we should take this one step further... RemoteIPInternalHeader X-RemoteIP RemoteIPHeader X-Forwarded-For, X-Forward In the absence of an RemoteIPInternalHeader list, the RemoteIPHeader list would be used instead to unwind the forwarded addresses for RemoteIPInternalProxy members. When the RemoteIPInternalHeader list is exhausted, the RemoteIPInternalProxy list would continue to be honored, but treated as trusted external proxies, for purposes of dis-honoring private IP addresses. This should ensure maximum compatibility with existing configurations and offer the fewest unintended consequences of a misconfiguration. It's unclear to me if https://tools.ietf.org/html/rfc7239 will see widespread adoption and how it would interact with older conventions. The header "Forwarded" could be treated as a special-case, supporting the new RFC, but deciphered in the order it appears. (I imagine it would typically be first where the immediate proxies which are trusted have adopted the convention). Sadly, https://tools.ietf.org/html/rfc7239#section-7.4 is less than helpful on this subject :)
+1 This would be extremely useful, as modern proxies have moved away from X-Forwarded-From, to their own header for each (Cloudflare, Securi, etc.)
I too would like to see multiple Headers supported here for the very reason that Tom mentions in Comment #5: This would be extremely useful, as modern proxies have moved away from X-Forwarded-From, to their own header for each (Cloudflare, Securi, etc.) I find myself wrestling with Load Balancer's which use one Header and CloudFlare which uses another. Installing both mod_cloudflare and mod_remoteip will cause Apache to crash if both modules attempt to set different IPs. I'd like to keep control of the headers in one place as well. It's simple enough to emulate mod_cloudflare with mod_remoteip but in doing so we cannot convert our LB IPs because mod_remoteip only accepts one header.
It's been 7 years and the bug is still open - is it really still not possible to use multiple headers?
RemoteIPHeader still accepts only one parameter, so no, it is still not possible. (read: patches welcome :) )
Just a note to mention I have need of this too. I have two different domain names pointing at the same webserver, but they are fronted by different upstream proxies, each of which has their own header they use. Having them individually in the config was my first attempt: RemoteIPHeader X-Real-IP RemoteIPTrustedProxy 127.0.0.1/24 ..etc RemoteIPHeader CF-Connecting-IP RemoteIPTrustedProxy 173.245.48.0/20 ..etc but this just ignores the first value completely..
Having this would be a game changer. It seems you can do this per virtual host, but it's unmanageable for servers with a large number or when you have other users creating them, any of which may or may not use any available proxy.