In an intranet environment, I have a relatively involved scenario, all on the same server:
IIS server acting as a reverse proxy listening on 443
forwards matching requests to localhost:1080/redmine
Apache reverse proxy is listening on 1080
forwards matching requests to localhost:3001 or localhost:3002 (thin servers in front of Redmine)
Thin1 and Thin2 web servers listening on 3001 and 3002 to handle requests
The issue is that Apache's remoteip module seems to disregard the X-Forwarded-For header. The configuration is:
# in the httpd.conf file
LoadModule remoteip_module modules/mod_remoteip.so
# elsewhere, in a VirtualHost declaration
# define the header to use to retrieve the remote ip address
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1 10.101.24.161 ::1
# for debugging only
LogFormat "%a %h %{c}a *** %{x-forwarded-for}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" redmine
#LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" redmine
CustomLog "logs/access-redmine.log" redmine
With the above debugging LogFormat I expected, according to the documentation, the %a token to contain the original client's IP. However, I get this:
::1 ::1 ::1 *** 10.106.33.206, 10.106.33.206:63804 - - [07/Sep/2022:16:08:24 +0200] "GET /redmine/projects HTTP/1.1" 200 10718 "https://redacted.org/redmine/my/account" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
%a or %{c}a (see here) are supposed to contain the client IP but actually, both contain the reverse proxy's IP ::1. The actual client IP is visible in the log line as 10.106.33.206 via the %{x-forwarded-for}i token which incidentally proves that the HTTP header is successfully populated by IIS.
I have attempted all kinds of permutations of RemoteIPTrustedProxy, RemoteIPInternalProxy, etc. but none have led to successfully populating the %a token with the original client's IP address.
(An apparently similar question did not answer my problem.)
