J LANCE WILKINSON wrote:
Wow. Thanks. I'll share that w/ my network colleagues. One of them has
wanted to use WireShark against this problem, but complained that since much
of the dialog is SSL encrypted, WireShark has some issues with this
apparently. Any guidance on that?
Further research has shown that the requests in question, as they come thru our
load balancer, all have the requisite X-Forwarded-For: header that we depend on
to associate the request with the "REAL" IP address of the browser making the
request.
We use mod_remoteip to honor this header.
The requests which are failing to be processed correctly are coming thru a VPN
connection which assigns a 172... private non-routable address. Observation
suggests that when requests come from those addresses, the substitution of the
load balancer's IP address with the X-Forwarded-For: header is failing to
happen. Access log entries show the request with the load balancer's IP address.
We have another VPN which imposes a 146... address. These log the 146...
address just fine.
And requests that don't use a VPN of course are logging with the browser's, not
the load balancer's address.
So I found what I *think* is the source code online (somebody else complied
the .so file we use so I can't check the source he actually used), and sure
enough there's code that limits its function for private IP addresses in lines
348 thru 380. The implication to ME is that if the proxy is an INTERNAL one,
the private IPs are allowed, while for non-internal trusted proxies are
ignored. So I added RemoteIPInternalProxy directive to my existing
RemoteIPTrustedProxy, both specifying my load balancer's address.
Turning on debugging, the error log contains documentation to support this too:
[Fri Feb 24 10:52:27 2012] [debug] mod_remoteip.c(368): [client 128.118.12.34]
RemoteIP: Header X-Forwarded-For value of 172.25.2.162 appears to be a private
IP or nonsensical. Ignored, referer:
http://daytripper.libraries.psu.edu/psul/home.html?
Now, this is in effect with
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 128.118.12.34
RemoteIPInternalProxy 128.118.12.34
in place...
Tried with only RemoteIPInternalProxy specified as well, same results.
Thoughts?
--
J.Lance Wilkinson ("Lance") InterNet: lance.wilkin...@psu.edu
Systems Design Specialist - Lead Phone: (814) 865-4870
Digital Library Technologies FAX: (814) 863-3560
E3 Paterno Library
Penn State University
University Park, PA 16802
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
