Caddy with DNS challenge using duckdns trouble

Help
1

Hello this is my first time posting. I hope someone can help me as I feel like I am very close to having a working solution, but am missing something critical. I have checked many documents and related issues, but I am not able to implement an adequate solution. Hopefully this enough info to help troubleshoot.

1. The problem I’m having:

I am unable to join my vaultwarden using the duck dns domain. Every time I enter in my domain from duck dns I get the following error “This site can’t be reached
Check if there is a typo in af-vw.duckdns.org”. I get this regardless of whether I try http or https. There doesn’t seem to be any explicit issues based on the logs as far as I can tell, so I am not sure if it an issue with caddy or my network settings.

2. Error messages and/or full log output:

log of connection to domain

curl -Iv http://af-vw.duckdns.org
* Could not resolve host: af-vw.duckdns.org
* Closing connection 0

curl -Iv https://af-vw.duckdns.org
* Could not resolve host: af-vw.duckdns.org
* Closing connection 0

log of my docker compose yml

docker compose -f vw_test.yml logs
vaultwarden  | /--------------------------------------------------------------------\
vaultwarden  | |                        Starting Vaultwarden                        |
vaultwarden  | |                           Version 1.30.0                           |
vaultwarden  | |--------------------------------------------------------------------|
vaultwarden  | | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
vaultwarden  | | official channels to report bugs/features, regardless of client.   |
vaultwarden  | | Send usage/configuration questions or feature requests to:         |
vaultwarden  | |   https://github.com/dani-garcia/vaultwarden/discussions or        |
vaultwarden  | |   https://vaultwarden.discourse.group/                             |
vaultwarden  | | Report suspected bugs/issues in the software itself at:            |
vaultwarden  | |   https://github.com/dani-garcia/vaultwarden/issues/new            |
vaultwarden  | \--------------------------------------------------------------------/
vaultwarden  |
vaultwarden  | [2023-11-26 18:04:26.033][start][INFO] Rocket has launched from http://0.0.0.0:80
caddy        | {"level":"info","ts":1701021943.083372,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
caddy        | {"level":"warn","ts":1701021943.0857005,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
caddy        | {"level":"info","ts":1701021943.0865426,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
caddy        | {"level":"info","ts":1701021943.086875,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0003a0e80"}
caddy        | {"level":"info","ts":1701021943.0869431,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
caddy        | {"level":"info","ts":1701021943.0870168,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
caddy        | {"level":"info","ts":1701021943.087364,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
caddy        | {"level":"info","ts":1701021943.087508,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
caddy        | {"level":"info","ts":1701021943.0873716,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
caddy        | {"level":"info","ts":1701021943.0877488,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
caddy        | {"level":"info","ts":1701021943.0879407,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
caddy        | {"level":"info","ts":1701021943.0880008,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["af-vw.duckdns.org"]}
caddy        | {"level":"info","ts":1701021943.0882382,"logger":"tls","msg":"finished cleaning storage units"}
caddy        | {"level":"info","ts":1701021943.0887532,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
caddy        | {"level":"info","ts":1701021943.088764,"msg":"serving initial configuration"}

This is the output of my custom caddy build based on this guide

https://github.com/dani-garcia/vaultwarden/wiki/Running-a-private-vaultwarden-instance-with-Let%27s-Encrypt-certs

caddy run --envfile caddy.env
2023/11/26 19:12:22.626 INFO    using adjacent Caddyfile
2023/11/26 19:12:22.629 WARN    Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies    {"adapter": "caddyfile", "file": "Caddyfile", "line": 2}
2023/11/26 19:12:22.630 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/11/26 19:12:22.630 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc0005d7000"}
2023/11/26 19:12:22.630 INFO    http.auto_https server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2023/11/26 19:12:22.630 INFO    http.auto_https enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2023/11/26 19:12:22.630 INFO    http    enabling HTTP/3 listener        {"addr": ":443"}
2023/11/26 19:12:22.630 INFO    failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
2023/11/26 19:12:22.631 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/11/26 19:12:22.631 INFO    http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2023/11/26 19:12:22.631 INFO    http    enabling automatic TLS certificate management   {"domains": ["af-vw.duckdns.org"]}
2023/11/26 19:12:22.632 INFO    tls     cleaning storage unit   {"description": "FileStorage:/test/AF/.local/share/caddy"}
2023/11/26 19:12:22.632 INFO    autosaved config (load with --resume flag)      {"file": "/test/AF/.config/caddy/autosave.json"}
2023/11/26 19:12:22.632 INFO    serving initial configuration
2023/11/26 19:12:22.633 INFO    tls     finished cleaning storage units

3. Caddy version:

v2.7.5 h1:HoysvZkLcN2xJExEepaFHK92Qgs7xAiCFydN5x5Hs6Q=

4. How I installed and ran Caddy:

My OS is open media vault 6 (omv6; based on debian 11). I am running Caddy as a docker compose file with vaultwarden using the omv6 web GUI (Just a nice interface that uses docker compose -d up) . I downloaded and installed a custom caddy build from the following link using the amd64 build for duckdns. This custom build has been renamed caddy as per this guide. The custom build lives in the same directory as the docker-compose.yml as specified in this guide

(https://github.com/dani-garcia/vaultwarden/wiki/Using-Docker-Compose#caddy-with-http-challenge)

I also have the build in the /usr/local/bin/ directory alongside a caddy.env file and a Caddyfile. My duckdns domain points to the ip address of the machine hosting everything.

a. System environment:

I am using OMV6. I changed the ports of this to not use ports 80 and 443 so as to avoid port conflicts (which I was getting earlier).

cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Linux kernel info

uname -r
6.1.0-0.deb11.11-amd64

b. Command:

Docker compose up -d vw_test.yml

c. Service/unit/compose file:

This is the Caddy yml that lives in the same directory as vw_test.yml

version: '3'

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: always
    environment:
      DOMAIN: "https://af-vw.duckdns.org"  # Your domain; vaultwarden needs to know it's https to work properly with attachments
    volumes:
      - ./vw-data:/data

  caddy:
    image: caddy:2
    container_name: caddy
    restart: always
    ports:
      - 80:80  # Needed for the ACME HTTP-01 challenge.
      - 443:443
    volumes:
      - ./caddy:/usr/local/bin/caddy  # Your custom build of Caddy.
      - ./Caddyfile:/etc/caddy/Caddyfile
      - /Docker/vw_test/caddy_data:/data
      - /Docker/vw_test/caddy_config:/config
    environment:
      DOMAIN: "https://af-vw.duckdns.org"  # Your domain.
      EMAIL: "myemailaddress"            # The email address to use for ACME registration.
      DUCKDNS_TOKEN: LONGDUCKDNSTOKEN  
      LOG_FILE: "/data/access.log"

d. My complete Caddy config:

This is my Caddyfile that lives in the same directory as vw_test.yml

{$DOMAIN}:443 {
  log {
    level INFO
    output file {$LOG_FILE} {
      roll_size 10MB
      roll_keep 10
    }
  }

  # Use the ACME DNS-01 challenge to get a cert for the configured domain.
  tls {
    dns duckdns {$DUCKDNS_TOKEN}
  }

  # This setting may have compatibility issues with some browsers
  # (e.g., attachment downloading on Firefox). Try disabling this
  # if you encounter issues.
  encode gzip

  # Proxy everything to Rocket
  reverse_proxy vaultwarden:80
}

I also have a Caddyfile that lives in /usr/local/bin/caddy


{$DOMAIN}:443 {
   tls {
       dns duckdns {$DUCKDNS_TOKEN}
   }
   reverse_proxy localhost:8001
}

There is an associated caddy.env file with the following info


DOMAIN=https://af-vw.duckdns.org
DUCKDNS_TOKEN=LONGDUCKDNSTOKEN

5. Links to relevant resources:

2

This implies that it’s a DNS issue, i.e. your machine’s DNS resolver isn’t properly configured.

I checked to see if that domain resolves for me, and it does, with the host command:

$ host af-vw.duckdns.org
af-vw.duckdns.org has address 192.168.0.44

Try that command yourself. If it doesn’t return the same thing, then there’s an issue with your machine’s DNS resolver.

Since you’re using Docker, I recommend using a Dockerfile for custom builds instead. See the docs on https://hub.docker.com/_/caddy, in particular the Adding custom Caddy modules section.

You only need the one Caddyfile in your Docker setup, you don’t need Caddy both inside Docker and outside.

3

The DNS resolver was definitely the issue. I can’t believe it was that simple. I forgot to add the domain and point it to my ip address. Now it works as intended with an https connection. I greatly appreciate it, you saved me a lot of time and frustration!

What is your reasoning behind using the dockerfile for custom builds? Is that just so it is easier to keep up to date with the latest releases?

4

Yes. Easier to automate builds. Infrastructure as code.

5

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