Bitwarden won't get behind my reverse proxy 🤷🏾‍♂️

[lanre]

I have a DSM918 running a number of containers in Docker. I have set up linuxserver’s swag as my secure nginx, and I seem to be having a lot of trouble getting bitwarden_rs behind it.

Here’s my docker-compose for bitwarden (I have to docker-compose up --no-start because I’ve set up a custom bridge network and can’t fathom how to get the right syntax to connect the container to it when created, then re-edit the network settings container in portainer, then start):

version: "3"

services:
  bitwarden:
    container_name: bitwarden
    image: bitwardenrs/server:latest
    ports:
      - "680:80/tcp"
      - "3012:3012/tcp"
    environment:
      TZ: 'Europe/Somewhere'
    #  DOMAIN: 'https://sub.mydomain.com/bitwarden'
      ADMIN_TOKEN: 'noneofyourbloodybusiness'
      WEBSOCKET_ENABLED: 'true'
    volumes:
      - '/volume1/docker/bitwarden/:/data/'
    restart: unless-stopped

the DOMAIN is hashed out because every time I leave it in, I get 404 error whenever I got to the HTTP://DSM_IP:680. Hashed out, I can get to it. I have the same issue when I put the DOMAIN in the admin page or in config.json. If I docker exec into swag, I can ping the hostname bitwarden…

Here’s my swag subfolder config for the reverse:

location /bitwarden {
    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 64;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    add_header Front-End-Https on;
    proxy_pass http://bitwarden:680;
}
 
location /notifications/hub {
    proxy_pass http://bitwarden:3012;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

going to https://sub.mydomain.com/bitwarden just gives me a 502 error. in the nginx log, it says
[error] 410#410: *33 connect() failed (111: Connection refused) while connecting to upstream, client: 172.10.1.1, server: _, request: "GET /bitwarden/ HTTP/2.0", upstream: "http://172.10.1.136:680//", host: "sub.mydomain.com"

I’m at my wit’s end with this - I’ve tried multiple different subfolder configs, multiple different docker-compose setups, and the best I can do is to access bitwarden from within my network, which is pretty useless…

Would be eternally grateful for any help! ‍♂

[lanre]

My brain is turning to jelly…

My setup worked for a few hours, I was advised to update the config with $ variables for security, and now I’m getting a 404 error. I can get to bitwarden from my LAN, but using the https://sub.mydomain.com/bitwarden gives me a 404 error from Rocket (not 502 like before).

Here’s the config:
location ^~ /bitwarden/ {
proxy_headers_hash_max_size 512;
proxy_headers_hash_bucket_size 64;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header Front-End-Https on;
set $upstream_bitwarden bitwarden;
set $upstream_port 80;
proxy_pass http://$upstream_bitwarden:$upstream_port/$upstream_bitwarden;
}

location ^~ /notifications/hub {
set $upstream_bitwarden bitwarden;
set $upstream_port 3012;
proxy_pass http://$upstream_bitwarden:$upstream_port;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}

and my docker-compose:
version: “3”

services:
  bitwarden:
    container_name: bitwarden
    image: bitwardenrs/server:latest
    networks:
    - mynet
    ports:
      - "680:80/tcp"
    environment:
      TZ: 'Europe/Somewhere'
      DOMAIN: 'https://sub.mydomain.com'
      WEBSOCKET_ENABLED: 'true'
      LOG_FILE: '/data/bitwarden.log'
    volumes:
      - '/volume1/docker/bitwarden:/data'
    restart: unless-stopped
    
networks:
  mynet:
    external: true

Please…send help…!

[gpopesc]

Use my settings from this post

[SOLVED] Websocket setup on Synology

Hello I am using ssl from cloudflare (not the one from synology), I have not tried in other configuration (without ssl or other ssl providers), but it should work. The email settings you can add later, there are not necessary from first time. Admin_token it is the admin password for respectiv access panel, also not necessary from first time. Network is bridge setup in docker. If you know how to work with docker compose you can use the following configuration. Folder “bit” you need to create…

[lanre]

thanks, but I am using swag as my reverse proxy, and the issue seems to be between that and bitwarden_rs. As mentioned in my post, bitwarden works fine within my LAN, so no issues that I can see with docker-compose. I just can’t get swag to reverse proxy to it. Any tips for fixing that?

[jjlin]

If you’re running under a subdir, this needs to be included as part of your DOMAIN env var. See https://github.com/dani-garcia/bitwarden_rs/wiki/Using-an-alternate-base-dir.

[lanre]

dammit I KNEW it was a simple mistake - thank you!!!

[aciim]

I have this very same issue. I have blank page having only “Bitwarden” -text. Here are my confs:

<docker-compose.yml>
version: "3.7"
services:
  bitwarden:
    image: bitwardenrs/server:latest
    container_name: bitwarden
    volumes:
      - ./bitwarden:/data
    restart: unless-stopped
    environment:
      WEBSOCKET_ENABLED: "true"
      SIGNUPS_ALLOWED: "false"
      TZ: "Europe/Somewhere"
      DOMAIN: "https://sub.domain.net/bitwarden"
      LOG_FILE: '/data/bitwarden.log'
    expose:
      - 80
      - 3012
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "1"
    networks:
      - proxy
networks:
  proxy:
    external: true

<bitwarden.subfolder.conf>
location ^~ /bitwarden {
        proxy_headers_hash_max_size 512;
        proxy_headers_hash_bucket_size 64;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header Front-End-Https on;
        set $upstream_bitwarden bitwarden;
        set $upstream_port 80;
        proxy_pass http://$upstream_bitwarden:$upstream_port/$upstream_bitwarden;
}

location ^~ /notifications/hub {
        set $upstream_bitwarden bitwarden;
        set $upstream_port 3012;
        proxy_pass http://$upstream_bitwarden:$upstream_port;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
}

I have read Wiki and tested many configurations. Originals from SWAG and modified with trailing slash and without. Last I tried confs from this thread. No luck.

BW works great directly on subdomain. I would appreciate any help a lot!

[SolarPolarPear]

This is my first post so bear with me:

I followed the SpaceInvaderOne videos to setup a reverse proxy through Swag and Vaultwarden dockers on unRAID. They are working well and I haven’t had any issues accessing the vault’s URL, syncing passwords, etc. Swag’s log confirms the subdomain’s been processed. I’ve setup Fail2Ban, GeoIP2, and HSTS to secure it best I can. I tested the domain on ssllabs.com and had an A+ rating so I felt confident it was setup well.

While in the Vaultwarden Admin Panel’s diagnostics page, I noticed it listed “uses a reverse proxy” as No, so my concern is I’ve missed something and I’m a sitting duck. I’ve enclosed my support string and am hoping for some guidance on how to get my vault behind the reverse proxy. If there are other logs that would be helpful, please let me know.

Thanks in advance,

• Vaultwarden version: v1.22.2
• Web-vault version: v2.21.1
• Running within Docker: true
• Environment settings overridden: true
• Uses a reverse proxy: false
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Time Check: true
• Domain Configuration Check: false
• HTTPS Check: true
• Database type: SQLite
• Database version: 3.35.4
• Clients used:
• Reverse proxy and version:
• Other relevant information:

[BlackDex]

Looks like you do not send the original IP with headers to Vaultwarden.

It checks for X-Real-IP, X-Client-IP and X-Forwaded-For or whatever you configured as IP_HEADER.

If those can’t be found it assumes there is no reverse proxy, but a direct connection.

That header is used to determine the external IP used by the clients and show in the logs during login attempt’s or in a mail which notifies you that a new device has logged in.

[SolarPolarPear]

I’ve enclosed what my config.json file states for the IP header & it looks unchanged.

I’ve searched my Swag/nginx/proxy-config file as well & didn’t see anything.

I forgot to mention earlier I have HSTS enabled in ssl.conf after following the “Securing Swag” wiki

Could HSTS be messing with the Vaultwarden admin page recognizing the reverse proxy?

Am I potentially more vulnerable in this situation?

Thanks again

[BlackDex]

I’m not seeing the X-Real-IP in your proxy config. So if that is not send, then Vaultwarden can’t read it.

HSTS is only client side.

[SolarPolarPear]

Thanks again for your guidance and patience with this.

Under appdata\swag\nginx\proxy.conf I have the default proxy header settings:

proxy_set_header Connection $connection_upgrade;
proxy_set_header Early-Data $ssl_early_data;
proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Real-IP $remote_addr;

Would you suggest I put the URL for my vault instead of $remote_addr to help or is there another file you suggest I correct?

[BlackDex]

But it’s that file included in your Vaultwarden config. If not, then it will not sent that data. Maybe best to enable log_level=trace, that will output all the headers when you visit a page like the /admin for example. You should be able to see there what headers are coming in.