Services in Caddy using `bind tailscale/` are inaccessible

Containers in Tailscale
1

I have a single server, running a set of containers with docker-compose. I use Caddy in a container as a reverse proxy for all of the containers, so that I can access them through HTTPS. I would like to be able to keep some of the services private, whilst having some public.

I have built a docker container for Caddy including the Tailscale module: GitHub - tailscale/caddy-tailscale: A highly experimental exploration of integrating Tailscale and Caddy.

My Caddyfile includes a block like this:

*.example.com {
  bind tailscale/ tailscale+tls/

  tls {
    dns cloudflare {env.CLOUDFLARE_API_TOKEN}
  }

  @service host service.example.com
  handle @service {
    reverse_proxy service:1234
  }
}

When I write blocks like this without Tailscale binds they work just fine, I can access the server through the public address. When I use the Tailscale bind and set the CNAME record of the subdomain to the magic DNS subdomain of the Caddy instance, I can’t connect:

Port 443:

* Connected to service.example.com (100.X.X.X) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to service.example.com:443
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to service.example.com:443

Port 80:

* Connected to service.example.com (100.X.X.X) port 80 (#0)
> GET / HTTP/1.1
> Host: service.example.com
> User-Agent: curl/7.84.0
> Accept: */*
>
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

In the Caddy logs I can see some sort of connection starting, but nothing happens:

caddy               | {"level":"info","ts":1674233471.977188,"msg":"Accept: TCP{<my laptop TS IP>:57052 > <caddy TS IP>:80} 52 tcp non-syn"}
caddy               | {"level":"info","ts":1674233471.9867551,"msg":"Accept: TCP{<my laptop TS IP>:57052 > <caddy TS IP>:80} 133 tcp non-syn"}

If this needs escalating I’d be happy to provide more details to TS team :slight_smile:

For additional context, the host is also running Tailscale - I don’t know whether this is a factor.