2mo ago

Can't access Vaultwarden

I'm trying to host a vaultwarden instance through docker and failing miserably. This isn't my first attempt either but I've got much further than before.

I'm using a DuckDNS domain with caddy as reverse proxy, but it appears that the domain is defaulting to port 80 no matter how I set up the config. I can't specify a port number in DuckDNS as far as I can tell. If the simple solution is to just buy a domain name I will consider it. Otherwise could really use some help in sorting out why it's not connecting.

I can't access Vaultwarden on the internal IP as it's not being served as SSL but both Vaultwarden and Caddy are running with no errors in logs. I've left out a bunch of admin env variables for the Vaultwarden service to truncate the code.

docker-compose:

`[___](services:

vaultwarden:

        container_name: vaultwarden

    image: vaultwarden/server:latest

    restart: unless-stopped

    ports:

      - 11808:80

      - 11443:443

    volumes:

      - ./data/:/data/

    environment:

      - ROCKET_PORT=11444

caddy:

        image: caddy:2

    container_name: caddy2

    restart: always

    ports:

      - 1808:11808

      - 1443:11443

    volumes:

      - ./caddy:/usr/bin/caddy

      - ./Caddyfile:/etc/caddy/Caddyfile:ro

      - ./caddy-config:/config

      - ./caddy-data:/data

    environment:

      DOMAIN: "https://example.duckdns.org"

      EMAIL: "example@domain.com"
            
      DUCKDNS_TOKEN: "token"

      LOG_FILE: "/data/access.log")`

Caddyfile:

' {$DOMAIN}:1443 {

log {

        level INFO

    output file {$LOG_FILE} {

      roll_size 10MB

      roll_keep 10

    }

}

tls {

        dns duckdns {$DUCKDNS_TOKEN}

}

encode gzip

Notifications redirected to the WebSocket server

reverse_proxy /notifications/hub vaultwarden:3012

Proxy everything else to Rocket

reverse_proxy vaultwarden:11444

Any idea where I'm going wrong?

12 comments

idk what nonsense the other commenter is posting but essentially your network flow should look like this:
internet user -> your IP (found via dynamic DNS) -> firewall/router DNAT port 443 -> proxy (nginx/caddy) listening on 443, backend set to port 80 -> vaultwarden port 80
You’d load your SSL certificate into the reverse proxy, I’m not familiar with caddy but I use nginx for this purpose.
- Yup wouldn’t work over any other ports. Had to move the other service off of it but it now works.

I host Caddy and Vaultwarden using Docker. The traffic into the reverse proxy, Caddy, works over port 443, not 1808 or 1443. Using the Caddyfile, you can tell Caddy which port to send the traffic over.
Caddy docker-compose.yml
docker

services: caddy: ports: - "80:80" - "443:443"
Caddyfile, although there are other ways to do this

*.example.com { @vaultwarden host vaultwarden.example.com handle @vaultwarden { reverse_proxy :11808 }
Vaultwarden docker-compose.yml
docker

services: vaultwarden: ports: - 11808:80
- I think you can also use
  
  services: vaultwarden: expose: - 80
  And use 80 instead of 11808 in the caddy file.
  Then the port will be available internally for caddy but not to the outside world. That may also need a network created in docker though. I'm on my phone so I can't check the finer details at the moment.

Theres a lot of different things going on here although it sounds simple, you're actually touching many different technologies. I started a few years ago to self host and it took me a while to get my head around these and still have issues so don't worry too much!
Im not familiar with caddy but the ports look wrong. It would be looking for 80 and 443 presumably on the docker host (right hand side / "RHS Ports". You could use any ports on the left hand side ("LHS Ports").
The section "DOMAIN}:1443" might be telling caddy to be looking on port 1443 inside docker, which means the port need to be flipped around. The RHS Ports are what the service inside docker is looking to use (often these are set by the developer but they can be changed in settings, it's easier to leave these as default and only change the LHS Ports). The LHS Ports are what you choose to expose on the actual server itself. https://docs.docker.com/get-started/docker-concepts/running-containers/publishing-ports/
Theres no mention of the router settings so the problem might be there. Are you forwarding the right ports through? You would need to forward ports 80 and 443 to the LHS Ports you choose for caddy. These port forwards would also need to point to your servers internal address. (Search "
<your router name>
port forward settings")
What do you have on port 80 as I would recommend to change that to something else and have caddy on ports 80 and 443. I would also suggest trying nginx proxy manager which is available on docker, has a nice web interface to add reverse proxy's, and can handle your SSL certificates (inc automatic renewals). This would replace caddy and would use ports 80 and 443 on your server. https://nginxproxymanager.com/
Also, just to mention, your safest option is not to expose vaultwarden to the internet unless your very sure you need to and add other protections (firewalls, fail2ban etc). If it's just you/a few people, look into using a VPN like tailscale (easiest but relies on external party) or Wireguard (fully yours to control but pretty complicated).
You would still need an SSL cert but your can do this through DuckDNS using https://github.com/maksimstojkovic/docker-letsencrypt. You could also buy a cheap domain and never have to expose anything, as they would give you a certificate to download (cloudflare or porkbun are good - https://kb.porkbun.com/article/71-how-your-free-ssl-certificates-work) and you manually upload it to caddy or nginx proxy manager. the best option is to use nginx proxy manager or certbot to handle these as the certificates expire. You can set up "DNS challenge" in your SSL certificate manager which needs details from your DNS to obtain the SSL certificates on your behalf.
If I was you, I would search for online guides and setup in this order: nginx proxy manager, SSL cert (buying your own cheap domain from cloudflare and setting up DNS challenge in nginx proxy manager), tailscale, then vaultwarden.
- Solved with this solution. It would only work over 80 and 443.
  Lighttpd was using port 80 for pihole. Back when I set it up you could change the server port but it would be overwritten every time pi hole was redeployed, hence why I didn’t just change this in the first instance. They seem to have updated it so that editing the .conf and changing the port number will persist.

I’m using a DuckDNS domain with caddy as reverse proxy, but it appears that the domain is defaulting to port 80 no matter how I set up the config. I can’t specify a port number in DuckDNS as far as I can tell.
A domain or DNS in general has nothing to do with ports. DNS is primarily used so that you don't have to remember IP addresses.

You're missing the point of Caddy, and your ports are all wrong. You don't need it if you're already exposing ports via Docker to 80/443. Remove Caddy.
- I should have said in the main text, I have something else on port 80 and I though best practice was not to expose 80 or 443?
  
  Map host port 8080 to container port 80. 8443 to 443.
  
  You can configure caddy to use 80 and be a reverse proxy for both the services, serving one site or the other depending on the name (you will need a second DNS entry pointing to the same IP). about not exposing 443, I really doubt that caddy can automatically retrieve SSL certificates for you if not running on the default port. Check the documentation, if I'm right either you open an empty website on 443 just for the sake of getting SSL certs to run https, and manually configure the other port to do the same, or you get the certificates manually using the DNS verification (check let's encrypt documentation) and configure caddy to use them.
  
  If you don't want to expose port 80 or 443, then just change the ports they are running on. Right now you're mapping 80/443 in docker, so just change those numbers to something else if you don't want to use them. The number on the right is the internal service port, and the left of the colon is the port you're opening to proxy to the port on the left. Adding Caddy does exactly the same thing and serves no purpose except another layer of obfuscation you don't need.

12 comments