There should be no need to use a port at all. If using the reverse proxy, site should be reachable on default web server port 80:443, which needs to be forwarded to your proxy device.
so with this method i should be able to use the ios app? ill try again with a fresh install
Ok so I did the following things after reinstalling dietpi.
First I installed vaultwarden and certbot.
Then I sudo nano /mnt/dietpi_userdata/vaultwarden/vaultwarden.env and I only changed,
IP_HEADER=X-Forwarded-For
WEBSOCKET_ENABLED=true
WEBSOCKET_ADDRESS=0.0.0.0
WEBSOCKET_PORT=3012
DOMAIN=https://mydomain.ddnsprovider.com
#ROCKET_TLS={certs="./cert.pem",key="./privkey.pem"}
Then I created a file at /etc/nginx/sites-dietpi/vaultwarden.conf and this is the full content of the file,
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 https://mydomain.ddnsprovider.com:8001;
}
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 https://mydomain.ddnsprovider.com:8001;
}
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 https://mydomain.ddnsprovider.com:3012;
}
Then I went to sudo nano /etc/nginx/sites-available/default and commented the following lines
# location / {
# try_files $uri $uri/ =404;
# }
Then I ran sudo dietpi-letsencrypt, filled in https://mydomain.ddnsprovider.com and my email and enabled https, created the certs but it failed because it said some port was blocked. So, I opened ports 80 and 443 on my router and forwarded them to my pi and ran the command again. It worked and the certs were created successfully. Then I restarted my pi.
Now if I go to, 192.168.1.90, the address of my pi, I get this instead of the bitwarden login page,
404 Not Found
---
nginx
And If i go to https://mydomain.ddnsprovider.com, I get this,
502 Bad Gateway
nginx
When I close the ports on the router, the url can’t even be reached.
I don’t think I’ve set up the reverse proxy properly.
No idea what to do now.
Here are the vaultwarden logs,
Dec 19 15:54:56 DietPi vaultwarden[493]: [INFO] No .env file found.
Dec 19 15:54:56 DietPi vaultwarden[493]: [2022-12-19 15:54:56.547][vaultwarden::api::notifications][INFO] Starting WebSockets server on 0.0.0.0:3012
Dec 19 15:54:56 DietPi vaultwarden[493]: [2022-12-19 15:54:56.593][_][WARN] Detected TLS-enabled liftoff without enabling HSTS.
Dec 19 15:54:56 DietPi vaultwarden[493]: [2022-12-19 15:54:56.593][_][WARN] Shield has enabled a default HSTS policy.
Dec 19 15:54:56 DietPi vaultwarden[493]: [2022-12-19 15:54:56.593][start][INFO] Rocket has launched from https://0.0.0.0:8001
Dec 19 15:55:13 DietPi vaultwarden[493]: [2022-12-19 15:55:13.325][rocket_http::tls::listener][WARN] tls handshake with 192.168.1.99:63287 failed: received corrupt message
Dec 19 15:55:13 DietPi vaultwarden[493]: [2022-12-19 15:55:13.329][rocket_http::tls::listener][WARN] tls handshake with 192.168.1.99:63288 failed: received corrupt message
Dec 19 15:55:14 DietPi vaultwarden[493]: [2022-12-19 15:55:14.367][rocket_http::tls::listener][WARN] tls handshake with 192.168.1.99:63289 failed: received corrupt message
Dec 19 15:55:14 DietPi vaultwarden[493]: [2022-12-19 15:55:14.371][rocket_http::tls::listener][WARN] tls handshake with 192.168.1.99:63290 failed: received corrupt message
Dec 19 15:56:26 DietPi vaultwarden[493]: [2022-12-19 15:56:26.432][rocket_http::tls::listener][WARN] tls handshake with 192.168.1.99:63291 failed: tls handshake eof
Locally you still have to request the websocket port 8001
http://192.168.1.90:8001 should work.
For external access you use your domain and the reverse proxy, to get to the site without using the port in the URL.
This is expected since you are not able to reach the webserver anymore. If you call a domain you make a request to the related IP on port 80/443. If you close the ports the webserver can not respond to this requests. These ports must stay forwarded.
And I think you get a 502 because of your wrong vaultwarden.conf.
proxy_pass https://mydomain.ddnsprovider.com:8001; should be
proxy_pass http://192.168.1.90:8001;
So http and not https and the local IP of the device and not your domain
ALso set this for the notification hub with port 3012.
Port 80:443 would need to be open all the time. Otherwise, your revers proxy is not working. As well you are not able to refresh certificates once needed. It’s key to forward them from router to DietPi
Yes, you set incorrect proxy_pass https://mydomain.ddnsprovider.com:8001; inside the Nginx configuration file. It would need to be the local IP address of your system, instead of the DDNS name. If both, Nginx and Vaultwarden, running on same system., it could be localhost IP http://127.0.0.1:8001 as well. You need to adjust this 3 times inside config file.
Always use the DDNS address and not the local IP, because your need to pass the proxy to get the valid certificate. Using IP address will not work on HTTPS ans this is what is needed for Vaultwarden to work. Using HTTP will result in issues, as Vaultwarden might reject the access 
So I changed all the ips to http://127.0.0.1 and I got the same error, so i tried https://127.0.0.1 and it works now on the internet under https. thanks!
I have one last question, is there anyway to access it locally so I don’t have to expose it to the internet? Because I have a wireguard server on another computer and it would make it more secure.
that would be surprising since you have https disabled on Vaultwarden? You have not?
You need to get yourself clear what setup you like to go with.
- If you like an official SSL certificate and the possibility to access Vaultwarden from internet without using VPN, you need to expose port 80:443.
- If you like to access via VPN only and there is no need for direct internet access, we could have skipped the whole exercise of setting up a revers proxy and you could stay with the initial setup.
I am not sure if I have disabled https on vaultwarden, I did all the steps I listed above.
Sorry, I did not realize they were going to be different methods. I am glad that it works like this. But I was hoping that I could eventually only access it using iOS or another laptop while my wireguard VPN was connected to the same network.
Is that actually possible? Because with the initial setup there was no cert issued and the app wouldn’t let me connect.
You could have told this at the very beginning as we went to a completely different road now. We could have saved a lot of time. 
On iOS you need to import the DietPi self-singed certificate manually. Otherwise, iOS is rejecting the access.
Yes, you can access Vaultwarden locally without the need to having a revers proxy, official SSL certifactes aso. Just have a look to our online docs Cloud and Backup Systems Software Options - DietPi.com Docs There is a blue box at the bottom of Vaultwarden section, describing how to import certificate into macOS. For iOS you could search the web. There as well you can import self-singed cert.
Ok thanks! I think in that case I will stick to the internet method instead of the vpn method. Manually doing the certificates is a pain.
One by the way if I want to do regular backups of the data, I should backup the /mnt/dietpi_userdata/vaultwarden/ folder correct?
Yes, inside this directory is all the data. But I’m not sure if you can back up this way on a fresh installation, since in the webpanel there is a tool for export of your vault and they differentiate between account backup (can only imported into the current account) and a password protected backup (can be imported into any bitwarden account)
An explanation of the different types of export files can be found here:
https://bitwarden.com/help/export-your-data/
have a look to Vaultwarden Github to get some idea on possible backup scenario Backing up your vault · dani-garcia/vaultwarden Wiki · GitHub
1 Like
Because I want to do an auto backup / mirror to another location. Don’t think I can use the web interface to do that.
Hi there!! So i wanna also jump into this topic, because i´m very new to DietPi but i´m looking to learn something new and wanna get better. So i read through this topic and i think i managed a lot of it. But there are some things to ask, so i hope i can get some help here.
My setting is this: i have installed Pihole, Unbound, Docker, Docker-compose and Portainer and recently i installed NGINX with the SQlite database (the LESP config) Vaultwarden as the certbot software.
So all good so far, i have access to vaultwarden from local under https://192.168.178.22:3012 and i have unlocked the Admin Page as well. Now i have the problem to get access from outside and i dont can reach my Pihole Admin page too, so can i just post my settings here and get feedback from the forum?
/you already forward port 80/443 from your router to your DietPi device?`
In case of PiHole, did you activate blocking for external access? Should be an option during install process. Do you recall?
Hi Joulinar! Thanks for your answer. Yes both ports are open and I do recall that I’ve choosen blocking Pihole from outside back then.
Follow Joulinar advice…he really knows his stuff
Yes, I too setup a vaultwarden…the safest thing to do would be to do a cloudflare tunnel so you don’t have to expose your home network (aka port forwards thru your firewall) otherwise you would put whatever port you want to connect to your private server from the wan thru the firewall pointing it to the vaultwarden “listening” port 8080 ->8001
Cloudflare Tunnels: Getting Started with Domains, DNS, and Tunnels - YouTube
I used his method…I got a domain for like $12 a year (wherever domains are sold)…built the tunnel and kapow…I can use https anywhere, on my laptop, cellphone, home computers…as long as I have power and internet, I can use bitwarden client to connect to my personal vaultwarden server
I set up a reverse proxy (but I use lighttpd web server) and configured fail2ban to block IPs after 3 failed login attempts.
You can of course do this with nginx too. I you are interested I can share my fail2ban config and I’m sure somebody else can you show how to set up a reverse proy with nginx.
IMO this is a pretty secure way to expose the vault to the public internet.
Normally I access my services via a VPN connection but this is a nice failback, if my VPN fails for some reason.
There you go 
This is blocking your external access for PiHole. You are running Nginx as web server to host PiHole?
Sorry for all the questions but we need to sort thinks first before going into a configuration. We had a case once where we spend 2 weeks on configuration thinks, before we recognized hunting into wrong direction.
One more question, did you already create SSL cer4tificates for your web server?
Let’s check ports open on your system actually in use
ss -tulpn | grep LISTEN
Hi Joulinar,
sorry i was busy for a few days.
so that´s a good question. What i did was i installed Pihole and Unbound a few weeks ago with the lightttp option, which was part of the Pihole installtion routine, then i deinstalled it (lightttp) and installed the Nginx software package.
No problem i have to thank you, for fixing my leaks!!
So i installed the certbot software with the Nginx software and created keys for Nginx, yes
tcp LISTEN 0 256 127.0.0.1:8953 0.0.0.0:* users:(("unbound",pid=497,fd=6))
tcp LISTEN 0 1024 0.0.0.0:3012 0.0.0.0:* users:(("vaultwarden",pid=573,fd=36))
tcp LISTEN 0 5 127.0.0.1:4711 0.0.0.0:* users:(("pihole-FTL",pid=489,fd=10))
tcp LISTEN 0 4096 0.0.0.0:9002 0.0.0.0:* users:(("docker-proxy",pid=1110,fd=4))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=489,fd=5))
tcp LISTEN 0 1000 0.0.0.0:22 0.0.0.0:* users:(("dropbear",pid=309,fd=4))
tcp LISTEN 0 256 127.0.0.1:5335 0.0.0.0:* users:(("unbound",pid=497,fd=4))
tcp LISTEN 0 256 [::1]:8953 [::]:* users:(("unbound",pid=497,fd=5))
tcp LISTEN 0 5 [::1]:4711 [::]:* users:(("pihole-FTL",pid=489,fd=15))
tcp LISTEN 0 4096 [::]:9002 [::]:* users:(("docker-proxy",pid=1124,fd=4))
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=489,fd=7))
tcp LISTEN 0 1000 [::]:22 [::]:* users:(("dropbear",pid=309,fd=5))