Extending mod_remoteip to support Host/Port/Protocol mangling natively

[ghost]

While 'protocol' (HTTPS) part of it looks a bit hacky, I think this deserves to be included one way or other, it's pretty much helpful when running behind (popular nowadays) reverse proxies. Basically, this one extends mod_remoteip to support RemoteHost, RemotePort and RemoteProto, allowing for mangling Host header, using different ports and transitioning HTTPS to HTTP.

More details (and configuration details) here: https://alex-at.ru/blog/apache-mod_remoteip-mod_rpaf

I'm ready to work on that to bring it to the applicable state if something is wrong with it. HTTPS part surely looks hacky, so I'm eager to get expert opinions on how to make this proper.

[AlexAT]

Actually Apache 2.4.48 allows to completely integrate this module patch without any hacky tricks it seems.
I'm working on adjusting the additions for Apache 2.4.48 and will create a pull request once I'm done testing it.

[sriccio]

Hello,

We're using Caddy as a TLS terminator for our apache. Caddy communicates with apache using http (well actually h2c) on localhost.

For compatibility reason with other modules we need to use apache 2.4.37 (centos package) and we found this patch for mod_remoteip that seems to work on 2.4.37 after a bit of editing.

Here is the edited patch that compiles with 2.4.37:
https://gist.github.com/sriccio/5199659169d867570dd7adf82a6abb40

However, with our config it works as long as we request the homepages of the sites. (https://site.tld).
As soon as we try to request anything else (https://site.tld/whatever) it returns a 403 access denied.

# Let apache know we're behind a SSL reverse proxy (caddy)
<IfModule mod_remoteip.c>
        RemoteIPHeader "X-Forwarded-For"
        RemotePortHeader "X-Port"
        RemoteProtoHeader "X-Forwarded-Proto"
        RemoteAllowOnlyInternalProxies on
        RemoteIPInternalProxy 127.0.0.0/8
</IfModule>

We found out that setting RemoteAllowOnlyInternalProxies on to off resolves the issue and everything seems to be rocking. Still I'm curious about if that should happen.

All requests to apache are being made by Caddy through loopback interface and they are declared as InternalProxies.
Could this be a bug of the patch or I'm misunderstanding the meaning of InternalProxies ?

Thanks a lot for the help.

Kind regards.

[AlexAT]

Hello Sebastien,

Please try to adjust the following one for your version of Apache (it is the last version of the pre-#191 patch):
https://alex-at.net/b2evo/media/blogs/blog/quick-uploads/apache-mod_remoteip-mod_rpaf/httpd-2.4-remoteip-rpaf-2.4.41.patch

Take care this one (#68) is obsolete and contains SSL flag 'emulation' hacks that may give errors under some very specific configurations. If possible at all, newer Apache versions and #191 should be used instead.

If you are using H2 for this one, please also try to use just normal HTTP instead for frontend to backend connections. H2 in older 2.4 versions actually gave me a lot of pain and since then I ditched any attempts to use it for backends, that is patch unrelated.

[sriccio]

Hello Alex and thanks a lot for the information.

I was able to recompile mod_remoteip with the latest pre-#191 patch on 2.4.37. It compiled without the need to adapt it.

However the issue persisted when setting RemoteAllowOnlyInternalProxies on

After a bit of trial and error, I found out that adding these headers in caddy reverse proxy fixed the problem:

reverse_proxy h2c://127.0.0.80:80 {
    header_up Host {host}
    header_up X-Real-IP {remote}
    header_up X-Forwarded-For {remote}
    header_up X-Forwarded-Port {server_port}
    header_up X-Forwarded-Proto {scheme}
}

This is was very strange because by default it is supposed to populate automatically X-Forwarded-For and X-Forwarded-Proto as per caddy documentation.
https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults

So it turns out that when it populates it automatically the X-Forwarded-For only contains the remote client IP.
When populating it manually with {remote} it contains REMOTE_IP:REMOTE_PORT

It seems to me that it is what is causing the 403 errors we get when using RemoteAllowOnlyInternalProxies on.

Could it makes sense?

[AlexAT]

Hard to tell without protocol trace to be honest.
Makes me think there was some issue with proxy filling headers properly for every request, but that's only a wild guess.
Even if it looks fixed, I recommend tcpdump'ing traffic between frontend and backend under erring conditions to see if there is indeed a valid reason, to make sure it's really fixed and so avoid hitting side issues afterwards.

[sriccio]

Yes, you're right. Again thanks a lot!