I’m trying to set up Caddy (with security module) to secure and reverse proxy to a comsolserver. Caddy is running in a docker and the comsolserver is running on the host. I have set network to host in docker-compose, and yet still I get the " connection refused" (see below).
{
debug
order authenticate before respond
order authorize before reverse_proxy
security {
local identity store localdb {
realm local
path /data/auth/users.json
}
authentication portal myportal {
crypto default token lifetime 3600
crypto key sign-verify {env.JWT_SHARED_KEY}
enable identity store localdb
cookie domain {$DOMAIN}
ui {
links {
"COMSOL" https://server.{$DOMAIN} icon "las la-star"
"My Identity" "/whoami" icon "las la-user"
}
}
transform user {
match origin local
action add role authp/user
ui link "Portal Settings" /settings icon "las la-cog"
}
}
authorization policy admin_policy {
set auth url https://auth.{$DOMAIN}
allow roles authp/admin authp/user
crypto key verify {env.JWT_SHARED_KEY}
}
}
}
auth.{$DOMAIN} {
authenticate with myportal
}
server.{$DOMAIN} {
handle_path /files* {
authorize with admin_policy
file_server browse {
root /tmp
}
}
handle {
authorize with admin_policy
reverse_proxy * http://localhost:2036 {
transport http {
versions 1.1
}
}
}
}
I have stripped the mail/registration part of the Caddyfile security part, as I really think this issue is something obvious I can’t see right now with docker, and not about the security part. The file_server part works fine after I have authenticated…
However, you have to make sure your service on the actual host is listening on whatever host.docker.internal resolves to (usually 172.17.0.1 - the docker0 interface).
Meaning, if you configured that service on the host to only listen on 127.0.0.1 , you will have to change that.
When not using host mode, 127.0.0.1 or localhost means “this container”, so Caddy tries to connect to something in the same container, which obviously doesn’t work.
Are you sure that using host.docker.internal wouldn’t work? That should only be the case if the service running on the host is specifically binding to 127.0.0.1, instead of all interfaces (which is typically the default).
Is that Apache container running in Docker as well? In that case, you should use Docker’s networking to connect the two containers. Make sure they’re both in the same Docker network, then you can use the container’s name as the address.
I would love not to have my Caddy container to run in host network mode, but for now it seems like the only way for some weird reason I don’t understand.
Is the apache server binding to 127.0.0.1 instead of 0.0.0.0 (i.e. all interfaces)? If so that would make it not accept requests coming from 172.x.x.x i.e. Docker.
The apache server is binding fine to the docker0 interface it seems, as I can get fine response from outside docker.
(using wget as curl is not inside the caddy docker)
ufw is blocking from the container as it is another network. I don’t want to expose the port widely, so instead I need to know the subnet of the network the container is using. Found the solution here:
in my case this solved it:
$ docker network inspect caddy_backend | grep Subnet
"Subnet": "172.22.0.0/16",
$ sudo ufw allow in from 172.22.0.0/16
Rule added
