I thought that Vaultwarden install was going to be a little simpler but after having consulted a few guides here and there its maybe less straightforward than I thought.

My use-case is to use it on may internal LAN only with not access from outside whatsoever. In theory, http should be fine, but as this tool will contain quite a bit of sensitive data, I can see why it may be a good idea to go https. Are most of you internal users only setting up https?

My network is behind a pfSense setup that uses unbound to resolve all DNS. Locally, all my DNS requests are being forwarded on the subnet I will have Vaultwarden installed.

  • First question is whether for internal network use only, I need to go https.
  • Second question is whether I need to follow this guide?
  • trilobite@lemmy.mlOP
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    8 hours ago

    I’m picking up on this because I’m getting a bit confused. I’ve run this through docker compose using the below yaml. I’ve done it as normal user, “Fred” (added to docker group) rather than root (using sudo although it make no difference as I get the same outcome). I normally have a “docker” folder in my /home/fred/ folder so is /home/fred/docker/vaultwarden in this instance (i.e. my data folder is in here).

    I get the same issue highlighted here which is all about the SSL_ERROR_RX_RECORD_TOO_LONG when trying to connect via https, whereas when I try to connect via http, I get a white page with Vaultwarden logo in top left corner and the spinning wheel in the center. I’ve got no proxy enabled and I’m still not clear why I need one if I’m only accessing this via LAN. Is this something on the lines of “you must yse this through a proxy or it won’t work” thing? Although that not why I understood the from the guidance. I’m clearly missing something although not sure what exactly it is …

    services:
      vaultwarden:
        image: vaultwarden/server:latest
        container_name: vaultwarden
        restart: always
        environment:
          # DOMAIN: "https://vw.home.home/"
          SIGNUPS_ALLOWED: "true"
        volumes:
          - ./vw-data/:/data/
        ports:
          - 11001:80
    
  • Matt The Horwood@lemmy.horwood.cloud
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 days ago

    You could go HTTP only if your happy that anything on the network could see your traffic, I don’t trust anything on my networks so HTTPS everything.

    Depending on if you have a proxy in front of vaultwarden will depend on what you need setup, I have nginx and traefik in front of my instance.

      • N0x0n@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        ·
        23 hours ago

        Time to learn how to use one :) ! I always use https for all my services in my LAN with a local certificate authority !

        I can access all my services with a LAN domaine like the following: https://*.home.lab

        The reverse proxy allows to listen on 80 and 443 and forward your traffic to your specific service (https://vaultwarden.home.lab/) and back without the need to fiddle arround with ports and IPs. Thus avoiding port collision if 2 services are listening on the same port !

        May I suggest Traefik if you go the docker route? Nginx is also a good solution but way more complex to setup.

        • trilobite@lemmy.mlOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          6 hours ago

          I hadn’t considered the port conflict issue … probably shows how ignorant I am on all this stuff, not just on proxies … :-)

  • Creat@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    6
    ·
    2 days ago

    Never run something like Vaultwarden with unencrypted traffic. Throwing in a self signed cert is basically free insurance. You never know when even in your “trusted network” something starts listening in. Just why risk it?

  • manwichmakesameal@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    2 days ago

    FWIW, here’s my compose file. I 100% use https for everything internal. With LetsEncrypt and Pihole, why wouldn’t you? It’s dead-simple.

    networks:
      backend:
        external: True
    
    services:
      vaultwarden:
        container_name: vw-svr-00
        image: vaultwarden/server
        environment:
          - TZ=My/Timezone
          - DOMAIN=https://my.internal.domain/
    #    ports:
    #      - "82:80"
        volumes:
          - ./vw_data:/data
        networks:
          - backend
        restart: always
        labels:
          - "traefik.enable=true"
          - "traefik.http.routers.vaultwarden.rule=Host(`my.internal.domain`)”
          - "traefik.http.routers.vaultwarden.entrypoints=websecure"
          - "traefik.http.routers.vaultwarden.tls=true"
          - "traefik.http.services.vaultwarden.loadbalancer.server.port=80"
    

    edit: I also run my instance on a subdomain vs a path. So my instances is actually at vw.internal.domain.

  • DesolateMood@lemmy.zip
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 days ago

    I run vaultwarden local only and use https, mostly because vaultwarden doesn’t allow itself to be run over http. The way I did it was to get a domain (you can buy one if you want, I used duckdns for a free one) and when prompted for an IP to point it to, use your server’s internal IP instead your public IP. Other than that you should be able to follow all the guides as normal

  • Coolcoder360@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 days ago

    I think when I set up vault warden with the docker compose it had scripts to generate it’s own self-signed certificate. So it was already set up to use https.

    I have a CA I created with easyrsa so I went and found the csr from vault warden and signed it with my own CA, so I didn’t have to juggle two certs.

    But otherwise yeah, running it on my local LAN, no let’s encrypt.