Hey there, friends!
Working on the next part of getting my self-hosted Murena server together. @smu44 helped me out in my PMs, but I figured I’d discuss this part publicly so it can help others.
My goal is to use a Vaultwarden server hosted on a different VM on the same VMWare host as my Murena server. Since I only have a single WAN IP, I need to piggyback off the Nginx reverse proxy server integrated into the Murena script…and I got it working, and I wanted to help others who might make similar mistakes.
Here’s my working .conf file:
server {
listen 8000;
server_name passwords.example.com;
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 4430 ssl http2;
server_name passwords.example.com;
ssl_certificate /etc/nginx/conf.d/passwords.example.com.crt;
ssl_certificate_key /etc/nginx/conf.d/passwords.example.com.key;
include /etc/nginx/params/ssl_params;
include /etc/nginx/params/headers_params;
client_max_body_size 512M;
location / {
proxy_pass https://192.168.1.3:8001;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Lesson #1: If you’re using commercial certs/keys, as I am, you need to put them somewhere. On the docker host server, put them here: /mnt/repo-base/config/nginx/sites-enabled/. This maps to /etc/nginx/conf.d/ within the docker container, so putting the certs alongside the .conf file for your other server can be done in this way.
There are a few different ways to do this, of course - one can add an additional folder to the nginx config file, or one could make an ssl folder within the conf.d folder to avoid populating it too much, or of course, one could configure the Let’s Encrypt config to add the additional domains to the renewal tasks…but
1.) I’m too lazy to get Let’s Encrypt working right now, and
2.) I’m not skilled enough in Docker kung-fu to mess with the existing config files, and
3.) even if I was, I’d be too nervous that the next server upgrade would either undo my modifications, or that my modifications would break the upgrade…so this method seems to avoid all of those things.
Lesson #2: Yes, you’re listening on ports 8000 and 4430. Why, you ask? Well, if you go with your gut and use 80 and 443 like one would immediately expect, the autodiscover server will preempt your domain and you’ll never get to the domain you want. Listen on 8000 and 4430 and it’ll work fine.
Lesson #3: Don’t assume you’re smarter than Sylvian. Lesson #2 was only learned because I thought I was smarter than him and changed the 8000/4430 entries in the sample config he gave me to 80/443, and this post originally started as a support request to see why I was getting the autodiscover page instead of my Vaultwarden instance like I was expecting. Doing what he told me to do in the first place solved my problem, so instead of a support request, I got to turn it into a ‘thank you for your help / contribute to the community’ post.
I might append this later as I add more things, but for the moment, I hope this helps someone else who’s trying to utilize the nginx reverse proxy more effectively.
