[bug]: Problem with HTTP Reverse Proxy in Docker setup

[miccico]

What happened?

I am trying to set up stalwart behind a reverse proxy. I use nginx for that but i assume any reverse proxy would show the same behavior. My configuration is that all ports except http/https use streams proxy with proxy protocol enabled. For the http port i need to host more services so i am using a regular http reverse proxy. In no combination of proxy networks and use x-forwarded-for settings i am able to get the setup to work (except by overwriting the proxy networks on the http listeners to something invalid - but then i do not get the actual client ip but the ip of the proxy instead)

How can we reproduce the problem?

configure the following

server.http.use-x-forwarded = true
server.proxy.trusted-networks.0 = "10.193.1.0/24"
server.listener.http.proxy.override = false

and try to access the http port via a reverse proxy that connect to stalwart from eg 10.193.1.1

the headers the proxy is sending look as follows:

GET /manage/directory/accounts/edit HTTP/1.1
Host: xxx.xxx.xx
Connection: close
X-Real-IP: 10.211.110.5
Forwarded: for=unknown
X-Forwarded-For: 10.211.110.5
X-Forwarded-Proto: https
X-Forwarded-Host: xxx.xxx.xx
X-Forwarded-Port: 443
cache-control: max-age=0
sec-ch-ua: "Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
dnt: 1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=
sec-fetch-site: none
sec-fetch-mode: navigate
sec-fetch-user: ?1
sec-fetch-dest: document
accept-encoding: gzip, deflate, br, zstd
accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
priority: u=0, i

Version

v0.9.x

What database are you using?

RocksDB

What blob storage are you using?

None

Where is your directory located?

Internal

What operating system are you using?

Docker

Relevant log output

listenerId = "http", localIp = ::, localPort = 8080, tls = false, reason = "invalid proxy header"

Code of Conduct

• I agree to follow this project's Code of Conduct

[mdecimus]

Since you're seeing this error:

listenerId = "http", localIp = ::, localPort = 8080, tls = false, reason = "invalid proxy header"

It means that your proxy is not sending the headers.

[miccico]

I can pretty much guarantee that the headers are there because the request listed above is what i intercepted by pointing the proxy at a listening netcat. Any ideas how to investigate further?

[miccico]

OK - i understood the problem looking at the code. The forwarded header gets evaluated first and as this says unknown the X-Forwarded-For does not get evaluated at all. With that the topic can be closed :) - Thanks for the help!

[miccico]

If i may abuse this thread as it is somewhat concerning the same topic.
In the UI I can configure the HTTP listener like this:

This would be due to the intention to just disable proxy for the HTTP listener but keep it on for all other listeners.

Practically this however does not seem to work because what the code checks is just whether there is a network in the override list - not whether the flag is set to true

let mut proxy_networks = Vec::new(); let proxy_keys = if config .value(("server.listener", id, "proxy.trusted-networks")) .is_some() || config.has_prefix(("server.listener", id, "proxy.trusted-networks")) { ("server.listener", id, "proxy.trusted-networks").as_key() } else { "server.proxy.trusted-networks".as_key() }; for (_, network) in config.properties(proxy_keys) { proxy_networks.push(network); }

So if I want to un-proxy-network the listener i have to add a "dummy" network in order to get the connection to work

Thanks for providing such a great product btw

[mdecimus]

@miccico you're correct, the override value is only used by the webadmin to keep the UI clean by hiding the list. However, the webadmin should empty the proxy-networks list when this checkbox is disabled (if it doesn't you've found a bug!).