What I assumed transparent did was to pass on the requester’s ip address (via the reverse proxy) to home assistant. But what HA seems to be getting is the IP of where the caddy server is running (turns out the same machine as HA server). If I trust that IP then every requester both in my lan and on the internet is trusted…yikes. If I only trust the ip I am trying to log in from then I am NOT trusted
So I suppose if I could see the outgoing header to HA of all requesters maybe I could see what is happening. I am logging that entry and I can see the correct requester IP but I am not seeing the details of the corresponding outgoing header.
Maybe I just don’t understand what transparent is doing in this case and if caddy can support the trusted ip feature of HA when doing a reverse proxy.
As you can see, all it’s doing is setting a bunch of headers! Other than Host, they’re all prefixed with X-, too - they’re not actually functionally required, nor checked by default.
When it comes to IP addresses specifically, there’s no feasible way to fool an upstream server that isn’t programmed explicitly to look for one of the headers that includes the original client’s IP address and use that instead of the actual connecting IP address.
If one were to spoof the original client’s IP address in order to make the backend think it really did come from them… Well, the backend would try to send its reply packets straight back to the client. Not likely to work for a huge variety of reasons…
So - yes, transparent in Caddy v1 is indeed sending the backend that information (the requester’s IP address), as extra data. What it looks like, unfortunately, is that the backend isn’t making use of that extra data.