Jump to content

Nginx Proxy Manager won't redirect to vaultwarden

Go to solution Solved by Eigenvektor,
9 hours ago, Julian Ewald said:

I found the error 😄

I just forgot to open port 8080 in the firewall

You should not need to open port 8080 in the firewall. That port should not be reachable from the outside world. Your server should be reachable on port 80 and 443 only. These ports should be serviced by nginx. Nginx should then forward traffic to port 8080 internally (i.e. 127.0.0.1/localhost).

I'm trying to set up vaultwarden in my raspberry pi 4 but I run in some issues with nginx.

This is my setup so far. I have docker running on my raspberry pi with vaultwarden on and nginx both seem to be working so far because I can acces them local with the right port. Also I've created a DDNS on Duck DNS. Everything I did was according to those guides (https://www.wundertech.net/how-to-setup-duckdns-on-a-raspberry-pi/, https://www.wundertech.net/nginx-proxy-manager-raspberry-pi-install-instructions/, https://www.wundertech.net/how-to-self-host-bitwarden-on-a-raspberry-pi/). I also forwarded Port 80 and 443 in my router to my pi. Port 80 and 443 are also open in ufw.

Screenshot2023-10-11200339.png.bcbe2bcd8183f7da410ca2b97c2baa46.pngScreenshot2023-10-11195300.thumb.png.540db75f0cc399e1336f9007c3c3dfbf.png

The config in nginx looks like this (I replaced the domain name):
Screenshot2023-10-11200625.png.307b974bb53edb9def75ffc69689d055.pngScreenshot2023-10-11200738.png.104d8b56511408f334c5cfd15fecf5aa.png

Now when I enter the Duck DNS domain name in my browser I get a 504 gateway timeout, but when I enter the current IP that is displayed on the Duck DNS site I get this: Screenshot2023-10-11194941.thumb.png.8e209cd8727088da5a1cfc9f4fe3e706.png

I'm not quite sure what this means or where I did go wrong. I'm newbie to this field and would apreciate some help to improve 😄

I've also added the logs from my docker containers if that helps. Please let me know if you need more information.

_vaultwarden_logs.txt _portainer_logs.txt _nginx_db_1_logs.txt _nginx_app_1_logs.txt

Link to comment
Share on other sites

Link to post
Share on other sites

You're forwarding to port 8080, but it looks like Vaultwarden is configured to listen on port 80:

[2023-10-11 17:36:54.862][start][INFO] Rocket has launched from http://0.0.0.0:80

 

This is what it looks like on my machine:

[2023-10-08 09:27:54.300][vaultwarden::api::notifications][INFO] Starting WebSockets server on 0.0.0.0:3012
[2023-10-08 09:27:54.305][start][INFO] Rocket has launched from http://0.0.0.0:8080

 

Not sure how much it'll help you since you're using UI tools for configuration, but this is what my nginx-configuration for Vaultwarden looks like:

Spoiler
# The `upstream` directives ensure that you have a http/1.1 connection
# This enables the keepalive option and better performance
#
# Define the server IP and ports here.
upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8080;
  keepalive 2;
}
upstream vaultwarden-ws {
  zone vaultwarden-ws 64k;
  server 127.0.0.1:3012;
  keepalive 2;
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name <external-hostname>;

    access_log  /var/log/nginx/vaultwarden_access.log vaultwarden;
    error_log   /var/log/nginx/vaultwarden_error.log;

    # Don't show the nginx version number, a security best practice
    server_tokens off;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name <external-hostname>;

    access_log  /var/log/nginx/vaultwarden_access.log vaultwarden;
    error_log   /var/log/nginx/vaultwarden_error.log;

    # Don't show the nginx version number, a security best practice
    server_tokens off;

    ssl_dhparam /etc/nginx/dhparams.pem;
    ssl_certificate /etc/letsencrypt/live/<external-hostname>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<external-hostname>/privkey.pem;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/<external-hostname>/fullchain.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256;

    # Perfect Forward Secrecy(PFS) is frequently compromised without this
    ssl_prefer_server_ciphers on;

    ssl_session_tickets off;
    # Enable SSL session caching for improved performance
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    # By default, the buffer size is 16k, which corresponds to minimal overhead when sending big responses.
    # To minimize Time To First Byte it may be beneficial to use smaller values
    ssl_buffer_size 8k;

    # Security headers
    ## X-Content-Type-Options: avoid MIME type sniffing
    add_header X-Content-Type-Options nosniff;
    ## Content-Security-Policy (CSP): Yes
    ## No 'script-src' directive, you need to test it yourself
    add_header Content-Security-Policy "object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; frame-ancestors 'self';";
    ## The safest CSP, only block your website to be inside an inframe
    # add_header Content-Security-Policy "frame-ancestors 'self';";
    ## Strict Transport Security (HSTS): Yes
    add_header Strict-Transport-Security "max-age=15552001; preload" always;

    client_max_body_size 128M;

    location / {
      proxy_http_version 1.1;
      proxy_set_header "Connection" "";

      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_pass http://vaultwarden-default;
    }

    location /notifications/hub/negotiate {
      proxy_http_version 1.1;
      proxy_set_header "Connection" "";

      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_pass http://vaultwarden-default;
    }

    location /notifications/hub {
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";

      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Forwarded $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_pass http://vaultwarden-ws;
    }
}

 

 

Remember to either quote or @mention others, so they are notified of your reply

Link to comment
Share on other sites

Link to post
Share on other sites

I found the error 😄

I just forgot to open port 8080 in the firewall

Link to comment
Share on other sites

Link to post
Share on other sites

9 hours ago, Julian Ewald said:

I found the error 😄

I just forgot to open port 8080 in the firewall

You should not need to open port 8080 in the firewall. That port should not be reachable from the outside world. Your server should be reachable on port 80 and 443 only. These ports should be serviced by nginx. Nginx should then forward traffic to port 8080 internally (i.e. 127.0.0.1/localhost).

Remember to either quote or @mention others, so they are notified of your reply

Link to comment
Share on other sites

Link to post
Share on other sites

On 10/12/2023 at 6:43 AM, Eigenvektor said:

You should not need to open port 8080 in the firewall. That port should not be reachable from the outside world. Your server should be reachable on port 80 and 443 only. These ports should be serviced by nginx. Nginx should then forward traffic to port 8080 internally (i.e. 127.0.0.1/localhost).

Oh okay. Would it be okay if you help me to understand the whole thing more?

As far as I understood it:

http/https (Port 80/443) requests to example.duckdns.org get redirected to my router (in my example fritzbox). Therfore the ports 80 and 443 need to be forwarded to my rasspberry pi in the router. My pi uses ufw as firewall and runs vaultwarden and nginx as a container in docker.

The pi needs to accept requests from port 80 and 443 therefore in ufw thesse ports must be open. Then nginx takes this request and forwards it to port 8080. I also set the ROCKET_PORT env from vaultwarden to 8080. Is that right so far?

I just found the error while explaining it haha. The destination in nginx was set to the pi ip in my router/fritzbox network and not to the internal docker ip of the vaultwarden container.

Link to comment
Share on other sites

Link to post
Share on other sites

56 minutes ago, Julian Ewald said:

Oh okay. Would it be okay if you help me to understand the whole thing more?

Sure 😊 Though I guess you found the main issue already.

 

The domain "example.duckdns.org" simply resolves to your external IP, so there's no forwarding going on yet.

 

If I go to http://example.duckdns.org, my browser will resolve that to your IP and then try to do a GET-request against that IP on port 80.

 

That will be received by your router, who will forward the request to the configured  internal IP and port, where nginx should be listening.

 

Nginx in this case will simply reply with: Please use HTTPS instead.

 

The browser will repeat the GET, this time using port 443, your router forwards to nginx again, which decrypts the requests, then forwards the (now HTTP) request to the docker container on port 8080.

 

Its response goes back to nginx, who encrypts the answer, then sends it to your router who finally sends the response back to my browser.

Remember to either quote or @mention others, so they are notified of your reply

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×