Bug 59669 - mod_remoteip seems to remove X-Forwarded-For header in some cases
Summary: mod_remoteip seems to remove X-Forwarded-For header in some cases
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_remoteip (show other bugs)
Version: 2.4.20
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-07 13:08 UTC by Vegar Nilsen
Modified: 2017-04-25 13:46 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vegar Nilsen 2016-06-07 13:08:25 UTC
We have a setup with Nginx, Varnish and Apache, where Nginx terminates HTTPS-traffic and proxies everything to Varnish. All HTTP-traffic goes through Varnish, before hitting Apache.

After upgrading to Apache 2.4.20 we've started noticing that when looking at PHP's phpinfo() output (PHP is running as an Apache module), HTTP_X_FORWARDED_FOR is frequently missing from the reported Apache environment.

I'm using this config for mod_remoteip.conf:
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1/8
RemoteIPInternalProxy ::1

Output from varnishlog for one such request:

**  << BeReq    >> 230295    
--  Begin          bereq 230294 pass
--  Timestamp      Start: 1465298356.399670 0.000000 0.000000
--  BereqMethod    GET
--  BereqURL       /XXXXXXX.php
--  BereqProtocol  HTTP/1.1
--  BereqHeader    Host: XXXXXXX.no
--  BereqHeader    X-Real-IP: XXX.XXX.XXX.XXX
--  BereqHeader    X-Forwarded-Proto: https
--  BereqHeader    X-Secure-Port: 443
--  BereqHeader    Pragma: no-cache
--  BereqHeader    Cache-Control: no-cache
--  BereqHeader    Upgrade-Insecure-Requests: 1
--  BereqHeader    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36
--  BereqHeader    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
--  BereqHeader    Accept-Encoding: gzip, deflate, sdch, br
--  BereqHeader    Accept-Language: en-US,en;q=0.8,nb;q=0.6,sv;q=0.4
--  BereqHeader    grace: none
--  BereqHeader    Surrogate-Capability: apt24=ESI/1.0
--  BereqHeader    X-Forwarded-Port: 443
--  BereqHeader    X-Forwarded-For: XXX.XXX.XXX.XXX, 127.0.0.1, 127.0.0.1
--  BereqHeader    Cookie: bjarne=anders
--  BereqHeader    X-Varnish: 230295

As you can see the request from Varnish to the backend (Apache) had the X-Forwarded-For header present, but that header was not available to PHP.

If I change mod_remoteip configuration to this, it works for HTTPS sites but not for HTTP, since it's Nginx that adds the X-Real-IP header:

RemoteIPHeader X-Real-IP
RemoteIPProxiesHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1/8
RemoteIPTrustedProxy ::1

However, the variable REMOTE_ADDR will then get the wrong IP.

Any tips for fixing this is appreciated.
Comment 1 KakersUK 2017-04-25 13:10:13 UTC
We're seeing the same thing. We've got NGINX and Varnish in front of Apache and passing the X-Forwarded-For and X-Real-IP Headers. Apache is using the event MPM and passing PHP to FastCGI.

All of the headers come through when doing a var_dump on $_SERVER. However when using the X-Forwarded-For or the X-Real-IP headers for RemoteIPHeader, you get the right IP for REMOTE_ADDR but the header disappears.
Comment 2 Eric Covener 2017-04-25 13:46:30 UTC
(In reply to KakersUK from comment #1)
> We're seeing the same thing. We've got NGINX and Varnish in front of Apache
> and passing the X-Forwarded-For and X-Real-IP Headers. Apache is using the
> event MPM and passing PHP to FastCGI.
> 
> All of the headers come through when doing a var_dump on $_SERVER. However
> when using the X-Forwarded-For or the X-Real-IP headers for RemoteIPHeader,
> you get the right IP for REMOTE_ADDR but the header disappears.

AFAICT this is intentional in mod_remoteip. Addresses essentially move from XFF to the internal representation of the client address. Entries only remain in if they're not trusted.