X-Forwarded-For points to my router and not my laptop

[WoJ]

I have just installed Authelia (light) and managed my first authentication to whoami with the new forward_auth implementation (THANK YOU for that!)

https://whoami.example.eu {
	forward_auth authelia:9091 {
		uri /api/verify?rd=https://auth.example.eu
		copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
	}
	reverse_proxy whoami:80
}

I have all the containers dockerized, the host is 192.168.10.2, its gateway is 192.168.10.1 (this is my router, connected to the fiber)

• caddy on 127.18.0.20 (127.18.0.0/16 is my default docker network)
• authelia on 127.18.0.34
• whoami on 127.18.0.35

When going to https://whoami.exemple.eu I get authelia’s authentication screen and after a successful login I see whoami output:

Hostname: 1eb10164839a
IP: 127.0.0.1
IP: 172.18.0.35
RemoteAddr: 172.18.0.20:40140
GET / HTTP/1.1
Host: whoami.exemple.eu
(...)
Referer: https://auth.example.eu/
Remote-Email: (...)
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 192.168.10.1
X-Forwarded-Host: whoami.exemple.eu
X-Forwarded-Proto: https

What I do not understand is why in no place I see the IP of my laptop from which I did the call (192.168.10.11) but the only

• IP: 172.18.0.35 → whoami (OK)
• RemoteAddr: 172.18.0.20 → caddy (why?)
• X-Forwarded-For: 192.168.10.1 → my router (why?)

The result is the same without Authelia (just using reverse_proxy to whoami:80, it is just I discovered it now.

I expected both RemoteAddr and X-Forwarded-For to point to my laptop (or at least X-Forwarded-For) but this is not the case.

Is there something I should configure to have the right information at the container level? (= provided to the containers behind caddy)

---

EDIT: I see that @WoJ already posted a similar problem two years ago (How to set X-Forwarded-For so that it contains the IP of the original caller?) but that noob made a configuration mistake (he he he), so this question is much better

[francislavoie]

Since you’re running in Docker, it’s probably because Docker has its userland proxy enabled, which rewrites TCP packets and makes the IP address on the packets look like they originated from Docker instead of from the original client. You’ll probably need to turn off the userland proxy (via a daemon config option, google it).

[WoJ]

Thank you for the hint. I tried the solution at how to disable userland-proxy for docker-compose - Stack Overflow that disabled the proxy but the result is, unfortunately, the same.

[francislavoie]

Do you have another proxy in front of Caddy, technically? Can you try to make the request from your phone or something over cellular networks (not via LAN); does that look ok?

Maybe your router is doing funny things with the TCP packets itself

[WoJ]

Ha. You are right, and I should have (again) looked to the earlier chain instead of suspecting caddy.

It looks like my hairpinning is not configured correctly: I did it for forwarded ports (and this is why I always saw the source IPs from Internet correctly), and implied that this is going to be the same for DNAT. Turns out it is not and my internal traffic (that I did not care that much above, at least from that perspective) is rewritten.

Good catch, thank you very much.

[francislavoie]

Sweet