Selfhosted behind Nginx reverse proxy

Hi all,
there are already plenty of topics regarding the configuration of Bitwarden behind the reverse proxy but unfortunately I didn’t find a solution working for me for that reason I would like to share with you my use case.

I have a Self hosted version of Bitwarden running on Debian 10. Everything is working until I try to configure it on our reverse proxy. Unfortunately I have to try to work with sub-folder and not sub-domain. I know that with the second solution would be much easier, but in our company we use the first solution.

As Reverse proxy I use Nginx and as starting point I’m using this link : reverse-proxy-confs/bitwarden.subfolder.conf.sample at master · linuxserver/reverse-proxy-confs · GitHub

I made it simple:

location ^~ /bitwarden/ {

    # Timeout if the real server is dead
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
    
    # Proxy Connection Settings
    proxy_buffers 32 4k;
    proxy_connect_timeout 240;
    proxy_headers_hash_bucket_size 128;
    proxy_headers_hash_max_size 1024;
    proxy_http_version 1.1;
    proxy_read_timeout 240;
    proxy_redirect http:// $scheme://;
    proxy_send_timeout 240;
    
    # Proxy Cache and Cookie Settings
    proxy_cache_bypass $cookie_session;
    #proxy_cookie_path / "/; Secure"; # enable at your own risk, may break certain apps
    proxy_no_cache $cookie_session;
    
    # Proxy Header Settings
    proxy_set_header Connection $connection_upgrade;
    #proxy_set_header Early-Data $ssl_early_data;
    proxy_set_header Proxy "";
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header X-Forwarded-Host $host:$server_port;
    proxy_set_header X-Forwarded-Method $request_method;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-Ssl on;
    proxy_set_header X-Forwarded-Uri $request_uri;
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass https://bitwarden/;
}

On Bitwarden side on the global.override.env I just changed:
globalSettings__baseServiceUri__vault=<https://myreverseproxy/bitwarden>

and on the config.yml I changed only

url: https://myreverseproxy/bitwarden/
real_ips:
- 10.28.8.166   (IP address of reverse proxy)

Let’s arrive to the problem. The first page is loading correctly, but for example if I try to do a login I have a problem and that’s because I have a redirect to

https://myreverseproxy/identity

and not https://myreverseproxy/bitwarden/identity.
The same for the API.

It seems that on nginx side everything is ok, but the application is not configured properly to work with the sub-folder.

Somewhere on the net I found also another variable that could be set on the global overrides, and I used like this:
globalSettings__baseServiceUri__identity=https://myreverseproxy/bitwarden/identity

It seem not having any effect.

I hope it is clear, if not please feel free to ask additional information.
Thanks in advance to everybody

BR
Marco

Hi @Marco and welcome to the community,

Sorry to hear you are having issues with your self-hosted installation.

From what I can tell this may very well be a limitation of the back-end server & web component not being built for this type of scenario.

Sorry to be a the bearer of bad news :confused:

Hi @cksapp ,
happy to be part of this community. I think I will be active in the next months.
I just started my experience with self hosted version and enterprise version.

Regarding the topic, I arrived at the same conclusion really fast, but then I found this link

GitHub - linuxserver/reverse-proxy-confs: These confs are pulled into our SWAG image: https://github.com/linuxserver/docker-swag

and also another topic regardin Vaultwarden

Using an alternate base dir · dani-garcia/vaultwarden Wiki · GitHub

Then I tough maybe with some effort is possible.

Anyway I’m testing the solution with sub-domain instead of sub-folder. In case a solution exist, I will be happy to switch to the sub-folder.

Thanks for the answer and your time.

BR
Marco

Hey @Marco I too have gone down this path. I have a current reverse proxy handling my site services, and do not want Bitwarden on my base domain and I currently do not have wildcard SSL certicates for a subdomain.

So I went down the path of trying to get the sub-folder working /bitwarden. So many hours lost.
I’ve got the login screen working, but as above the underlying back-end server config of Bitwarden doesn’t handle sub-folder within the target domain.

So you have: https://sample.com/bitwarden as a valid login page (relative paths), when Bitwarden tries to get server side resources it’s hard coded to example: https://sample.com/api/ and doesn’t appear to take into account the defined ‘Full URL’ defined in the config.yml, even if it does contain a subfolder.

I do not understand enough about docker and how the backend server and web compontents are configured, but not sure why it’s not ‘simple’ enough to use the defined URL, when it’s asked for in installation. I’ve looked at nginx/default.conf file and working on if that can be manually ‘fixed’ or there are other issues.

The linked sites I think relate to Vaultwarden an alternative to Bitwarden and appears to be better configured for integration into hosted reverse proxies. I’d prefer to stick with Bitwarden, bit it’s more of a challenge than it should be.

Yes, luckily for me the subdomain was an option possible (not clean for our internal standard) and at the moment I solved using it.

BR
Marco