Header issue in docker SOLVED

Help
1

1. Caddy version (caddy version):

V2.4.1

2. How I run Caddy:

I run Caddy in docker on a synology DS720+:

b. Command:

See above

c. Service/unit/compose file:

#!/bin/bash


docker run -d \
	-p 2080:80 \
	-p 2443:443 \
	--name Caddy \
	--restart unless-stopped \
	-v /volume1/docker/Caddy/Data:/data \
	-v /volume1/docker/Caddy/Config:/config	\
	-v /volume1/docker/Caddy/Caddyfile:/etc/caddy/Caddyfile \
	Caddy

a. System environment:

I run in docker on a synology DS720+. I don’t use the synology interface or package but run the bash script instead.

d. My complete Caddyfile or JSON config:

www.server_1.nl {
reverse_proxy * 192.168.3.201:5000	

	log {
		output file /data/caddy-server_1nl.log {
			roll_keep_for 14d
		}
	}
}
www.server_2.nl {
reverse_proxy * 192.168.3.200:31417	

	log {
		output file /data/caddy-server_2.log {
			roll_keep_for 14d
		}
	}
}
ha.server_3.nl {
reverse_proxy * 192.168.3.200:8123	

	log {
		output file /data/caddy-haserver_3nl.log {
			roll_keep_for 14d
		}
	}
}
server_4.nl {
	reverse_proxy * http://192.168.3.200:10080
	
	log {
		output file /data/caddy-server_4nl.log {
			roll_keep_for 14d
		}
	}
}
www.server_4.nl {
	reverse_proxy * http://192.168.3.200:10080
	
	log {
		output file /data/caddy-server_4nl.log {
			roll_keep_for 14d
		}
	}
}

3. The problem I’m having:

I use Caddy to direct traffic to the right server. The users can log in to the correct servers and have no issue. I can’t see the original users IP address, I see the internal docker address instead.

4. Error messages and/or full log output:

This is a log entry:

{"level":"info","ts":1626532822.3207395,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_addr":"172.17.0.1:44994","proto":"HTTP/1.1","method":"GET","host":"www.server_3.nl","uri":"/webapi/entry.cgi?camId=8&api=SYNO.SurveillanceStation.Camera.Event&version=1&method=MotionEnum&_sid=KRPQMVPOGQlrQcZ1Pm4eAHWGIa2ncMBO9ScRFbzOrvkMffPzHIdtZoICSSas0-jrtxq5xDarYROClLxFWFM4mw","headers":{"Cookie":["id=KRPQMVPOGQlrQcZ1Pm4eAHWGIa2ncMBO9ScRFbzOrvkMffPzHIdtZoICSSas0-jrtxq5xDarYROClLxFWFM4mw; smid=bbIyvQfSpJAVpHWQpn6cn-oQXJL5EmdAhxBzK_W3EY3KO5rgqa0vHbdkI76yzAVzOIt6i2aU7dDO9llQZsK9Tw"],"User-Agent":["python-requests/2.25.1"],"Accept-Encoding":["gzip, deflate"],"Accept":["*/*"],"Connection":["keep-alive"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","proto_mutual":true,"server_name":"www.server_3.nl"}},"common_log":"172.17.0.1 - - [17/Jul/2021:14:40:22 +0000] \"GET /webapi/entry.cgi?camId=8&api=SYNO.SurveillanceStation.Camera.Event&version=1&method=MotionEnum&_sid=KRPQMVPOGQlrQcZ1Pm4eAHWGIa2ncMBO9ScRFbzOrvkMffPzHIdtZoICSSas0-jrtxq5xDarYROClLxFWFM4mw HTTP/1.1\" 200 370","duration":0.11634775,"size":370,"status":200,"resp_headers":{"Date":["Sat, 17 Jul 2021 14:40:22 GMT"],"Content-Type":["application/json; charset=\"UTF-8\""],"Server":["Caddy"],"Vary":["Accept-Encoding"],"X-Content-Type-Options":["nosniff"],"Expires":["0"],"Content-Encoding":["gzip"],"Set-Cookie":["id=KRPQMVPOGQlrQcZ1Pm4eAHWGIa2ncMBO9ScRFbzOrvkMffPzHIdtZoICSSas0-jrtxq5xDarYROClLxFWFM4mw;expires=Sat, 24-Jul-2021 14:40:22 GMT;path=/;HttpOnly"],"Cache-Control":["max-age=0, no-cache, no-store, must-revalidate"],"Pragma":["no-cache"],"X-Xss-Protection":["1; mode=block"]}}

Log file entry in Docker.

17T15:57:53.468056638Z {"level":"error","ts":1626537473.4675727,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"www.server_4.nl","error":"no information found to solve challenge for identifier: www.server_4.nl"}

5. What I already tried:

I made sure that the proxy server is trusted by the Synology. I looked into header management in the documentation. It should be okay by default. Maybe there is something wrong in the docker file, because I don’t see the original IP in the log file anywhere. I am a bit surprised about this part in the log:
api=SYNO.SurveillanceStation.Camera.Event&version=1
Where does this come from?

6. Links to relevant resources:

2

Hi, welcome back – can you do us a favor and fix the formatting of your post? It’s a bit hard to read and will make it difficult to help you.

3

Sorry for that. I messed up the code blocks. Fixed it now

4

Thanks. That error usually happens when a challenge is started by one Caddy instance and is trying to be completed by another, but they don’t share the same storage. Make sure they share the same storage configuration/backend, or that the same instance that starts the challenge also finishes it.

Full logs would be helpful, as the template asks for. Out of context that single log message is hard to diagnose.

5

This seems suspect. Did you set up your router to map incoming requests on ports 80 and 443 to ports 2080 and 2443 of the machine on which you’re running Docker?

Caddy must be publicly accessible on ports 80 and 443 to solve the ACME HTTP and/or TLS-ALPN challenges. See the docs:

I recommend using a path like /logs instead of /data (with another docker volume). Caddy expects to own /data, so we can’t really guarantee that that path remains untouched.

6

Matt and Francis,
I did some more digging and the problem is in docker, not in caddy. The original IP address is not passed on to the container. 127.17.0.1 is the source instead. There appears to be a fix, but I chose to abandon docker instead. This issue is solved, but a new one presented itself. I’ll do a bit more digging for that first.

This seems suspect. Did you set up your router to map incoming requests on ports 80 and 443 to ports 2080 and 2443 of the machine on which you’re running Docker?

Yes. I did this to prevent issues with the synology. It didn’t interfere with direct access to the synology’s website. No issue now.

I recommend using a path like /logs instead of /data (with another docker volume). Caddy expects to own /data, so we can’t really guarantee that that path remains untouched.

I’ll move this elsewhere. Thank you both!

1 Like
7

This topic was automatically closed after 30 days. New replies are no longer allowed.