Immich Kiosk behind reverse proxy?

[semiligneous]

Has anyone got Immich Kiosk working behind a reverse proxy? I couldn't find anything in the discussion here about https/caddy/reverse proxy - but maybe I missed it, apologies if so!

I have kiosk working (service added to main immich docker-compose file, plus extra config.yaml with just the immich url and api key) if I access via http://:3000. However, if I put it behind Caddy reverse proxy, which works for other services I have set up, I get a caddy error:

{"level":"error","ts":1725630295.529699,"logger":"http.log.error","msg":"dial tcp: lookup immich_kiosk on 127.0.0.11:53: server misbehaving","request":{"remote_ip":"10.x.x.x","remote_port":"60266","client_ip":"10.x.x.x","proto":"HTTP/2.0","method":"GET","host":"kiosk.my-domain.com","uri":"/","headers":{"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Te":["trailers"],"Accept-Language":["en-GB,en;q=0.5"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Mode":["navigate"],"Priority":["u=1"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0"]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"kiosk.my-domain.com"}},"duration":0.014890664,"status":502,"err_id":"fudh4ufpx","err_trace":"reverseproxy.statusError (reverseproxy.go:1265)"}

my Caddyfile has:

kiosk.{$MY_DOMAIN} {
    reverse_proxy immich_kiosk:3000
    tls {
        dns cloudflare {$CLOUDFLARE_API_TOKEN}
    }
}

Which refers to the service name in docker:

 immich-kiosk:
    image: damongolding/immich-kiosk:latest
    container_name: immich-kiosk

thanks in advance!

[damongolding]

I'd love to get this working for you. I can't run a reverse proxy, I have to use tunnels due to my ISP so I can't test this.

Happy to trouble shoot with people using the development docker image.

[semiligneous]

I actually run caddy as an internal-facing service in order to give nice DNS names and valid ssl certs to all my services - eg immich.my-domain.com etc (and I also use a cloudflared tunnels if/when "public" access is required to a couple of services).

I use caddy as per https://github.com/DoTheEvo/selfhosted-apps-docker/tree/master/caddy_v2 and build with the lets encrypt DNS challenge plugin, which works with Cloudflare. Works nicely.

That is to say, if you are interested in setting up Caddy as an internal-only reverse proxy, you could do that - no obligation to do so, just wanted to let you know if you were interested!

Do you have any leads on where I might begin troubleshooting why it doesn't work behind the proxy?!

[damongolding]

Ahh ok so https://immich.domain.com actually points to a local IP on your network?

[semiligneous]

That's correct.

immich.domain.com points to internal IP eg 10.1.1.1. DNS for this is set up on my router, but it could be done by a public DNS (with a private IP) or with pihole, AdGuard, or whatever other DNS approach you control and use locally. I have a similar DNS entry for service-A.domain.com, service-B.domain.com etc, all pointing to that same IP.

10.1.1.1 is where Caddy runs, listening on port 443. In my case, that's actually VM I use for all my docker containers, one of which is Caddy, and another is Immich, another Plex etc.

I remove the port section of the docker-compose files, so that there is actually no port open on the VM itself. Instead, each docker container is added to a docker network (called caddy_net in my case).

Caddy is instructed to listen on port 443 and forward requests based on the URL/domain/sub-domain to the relevant docker container. Since Caddy is also on the same docker network (caddy_net), it can 'see' the container's ports despite them not being exposed on the VM itself.

Caddy handles the tls certs - in my case it uses letsencrypt to make certs, and proves ownership of the domain by using cloudflare's API, but there's a few options there.

Each container can then not worry about handling https and certs itself.

This setup means that I can have memorable names for all the services, plus "proper" https certs (not self signed) so there are never any issues when connecting etc, all managed in one place and renewed automatically. If required, I can also use Caddy to be more precise about who can access from where.

This seems to work every time I add a new service, but in the case of kiosk, it does not. I can't work out why (yet!).

[damongolding]

That sounds like an awesome setup. I did start looking into a solution to internal crts a while back but decided it was easier just to deal with browsers “site is not secure” warning. Does Kiosk give any errors from its logs or does your request not even hit Kiosk?

…

On 7 Sep 2024 at 11:43 PM +0100, semiligneous ***@***.***>, wrote: That's correct. immich.domain.com points to internal IP eg 10.1.1.1. DNS for this is set up on my router, but it could be done by a public DNS (with a private IP) or with pihole, AdGuard, or whatever other DNS approach you control and use locally. I have a similar DNS entry for service-A.domain.com, service-B.domain.com etc, all pointing to that same IP. 10.1.1.1 is where Caddy runs, listening on port 443. In my case, that's actually VM I use for all my docker containers, one of which is Caddy, and another is Immich, another Plex etc. I remove the port section of the docker-compose files, so that there is actually no port open on the VM itself. Instead, each docker container is added to a docker network (called caddy_net in my case). Caddy is instructed to listen on port 443 and forward requests based on the URL/domain/sub-domain to the relevant docker container. Since Caddy is also on the same docker network (caddy_net), it can 'see' the container's ports despite them not being exposed on the VM itself. Caddy handles the tls certs - in my case it uses letsencrypt to make certs, and proves ownership of the domain by using cloudflare's API, but there's a few options there. Each container can then not worry about handling https and certs itself. This setup means that I can have memorable names for all the services, plus "proper" https certs (not self signed) so there are never any issues when connecting etc, all managed in one place and renewed automatically. If required, I can also use Caddy to be more precise about who can access from where. This seems to work every time I add a new service, but in the case of kiosk, it does not. I can't work out why (yet!). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[semiligneous]

It works nicely, and now it's set up it is normally pretty easy to make work with a new container. I'll have a dig in the logs - I assume you would expect me to look at logs using:

docker logs

Right?

Also - I wanted to provide some context about why I want to have a reverse proxy. It's mainly so that I can control who/what can access the kiosk URL, since it's not authenticated. Anyone on the network could pull photos randomly from the Immich server, which I'd like to prevent.

[semiligneous]

so it turns out it is a docker networking issue, and my fault - apologies!

lookup immich_kiosk on 127.0.0.11:53: server misbehaving

Is an issue with Docker's DNS - caddy is trying to resolve "immich_kiosk" and can't.

That's because I named the container immich-kiosk, with a hyphen not an underscore.

Updated to hyphens, and all is working as expected.

[damongolding]

Fab! Glad it's working for you 😊