Problem with passenger and mod_remoteip #1284

Closed
eschneider1271 opened this Issue Sep 19, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@eschneider1271

Running passenger 3.0.21 and mod_remoteip under Apache 2.4.9

Hello,
In an environment with load balancers and a proxy server, I'm using mod_remoteip in an Apache webserver to override the incoming client IP with the real end-user IP as determined by parsing the X-Forwarded-For header value.
This is working as expected; logging "%a" shows the end-user IP we expect in our logs and IP authentication works the way it should.

However, when the request makes it to our rails application, REMOTE_ADDR is no longer set to the end-user IP address.
It appears to be set to the "Underlying peer IP address of the connection" (i.e. the IP of a load balancer, and not the end client).
So, request.remote_ip is not correct (or consistent) which has implications within our application.

Googling, I found another user had the same problem: https://groups.google.com/forum/#!topic/phusion-passenger/lCRWoTiRWmU
But it doesn't looks like a bug report was ever filed.
It's unclear to me if the problem is on the passenger side of things, but any guidance would be appreciated.

Thanks.

@tomhughes

This comment has been minimized.

Show comment
Hide comment
@tomhughes

tomhughes Nov 9, 2014

I'm seeing this as well. The problem appears to be that while the original out of tree implementation of mod_remoteip for Apache 2.2 just changed remote_ip in the request structure the new upstream version that comes with Apache 2.4 doesn't change client_ip or client_addr but instead sets useragent_ip and useragent_addr in the request structure with the IP determined by the remoteip decoding.

I'm seeing this as well. The problem appears to be that while the original out of tree implementation of mod_remoteip for Apache 2.2 just changed remote_ip in the request structure the new upstream version that comes with Apache 2.4 doesn't change client_ip or client_addr but instead sets useragent_ip and useragent_addr in the request structure with the IP determined by the remoteip decoding.

@tomhughes

This comment has been minimized.

Show comment
Hide comment

So apache does set (http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/util_script.c?view=markup#l240) the REMOTE_ADDR variable for scripts etc from useragent_ip but passenger (https://github.com/phusion/passenger/blob/master/ext/apache2/Hooks.cpp#L894) is using client_ip.

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget Dec 10, 2014

Member

I guess it makes sense for Passenger to use useragent_ip instead of client_ip.

Member

FooBarWidget commented Dec 10, 2014

I guess it makes sense for Passenger to use useragent_ip instead of client_ip.

@tomhughes

This comment has been minimized.

Show comment
Hide comment
@tomhughes

tomhughes Dec 10, 2014

See http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html for more information on mod_remoteip but basically it allows you to look past one or more proxies to see the real IP of the actual client.

Presumably when it was merged into apache upstream they decided they wanted to keep client_ip as the actual IP of the remote end of the network connection and therefore preferred to add a new field to record the result of mapping back to the real client. The original out of tree version of mod_remoteip just overwrote client_ip instead.

See http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html for more information on mod_remoteip but basically it allows you to look past one or more proxies to see the real IP of the actual client.

Presumably when it was merged into apache upstream they decided they wanted to keep client_ip as the actual IP of the remote end of the network connection and therefore preferred to add a new field to record the result of mapping back to the real client. The original out of tree version of mod_remoteip just overwrote client_ip instead.

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget Dec 10, 2014

Member

This should be fixed in git master now. Could you check?

Member

FooBarWidget commented Dec 10, 2014

This should be fixed in git master now. Could you check?

@FooBarWidget FooBarWidget added this to the 5.0.0 beta 2 milestone Dec 10, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment