blackvoid NGINX proxy manager

Guess this article was one long overdue considering how many Docker containers I run and a decent amount of those are running via reverse proxy.

Considering that I run Docker on Synology NAS, I used the built-in reverse proxy feature for years for several reasons. It was built in, it offered enough options out of the box, and I was lazy to run my separate one.

Well as it turns out, there are some solutions out there that require several features inside your reverse proxy to make them run correctly. This was the main reason why I made the switch to NGINX proxy manager.

Let's see how to run your version in parallel to your Synology NAS one.

Continue reading...

 

[jono]

I've been using this for a while.

I like the fact that you setup the proxy and the certificate in the same modal, instead of switching to different parts of DSM's Control Panel with Synology's built in one

 

[Rusty]

I've been using this for a while.

I like the fact that you setup the proxy and the certificate in the same modal, instead of switching to different parts of DSM's Control Panel with Synology's built in one

Like I said, long overdue...

 

[ilbarone87]

Hi Luka, great work, i love your guides. Since i discovered your blog my containers grew from 5 to 20 . Can I ask you something about this one? I'm using the in-built process in syn to create/renew the cert for synology.me domain. If I swap to NPM would this process still be managed automatically through the NAS and automatically imported to NPM or i will need to import manually the renewed cert every time it expires? Usually the Synology cert expires in 90 days.

Thanks

 

[Rusty]

Hi Luka, great work, i love your guides. Since i discovered your blog my containers grew from 5 to 20 . Can I ask you something about this one? I'm using the in-built process in syn to create/renew the cert for synology.me domain. If I swap to NPM would this process still be managed automatically through the NAS and automatically imported to NPM or i will need to import manually the renewed cert every time it expires? Usually the Synology cert expires in 90 days.

Thanks

Guilty!

If you import the one from syno you will have to do it again each time and to make matter worse you will have to import it and rebind each host again to the new cert (pain I know). version 3 of npm should fix cert management. Still this is only for the imported custom carts.

If you make and generate the cert from within npm it should be automatically renewed when the time comes but I still haven’t tried it so far (not enough time has passed) considering that I always use a custom docker container for cert generation to allow me to be independent from any other system and yet to have the option to use my certs anywhere.

So in short that’s that. Bit of a pain with custom certs but then again it’s once every 3 months so It’s not that bad in my book for a working wild card free cert.

 

[ilbarone87]

That was quick! thanks for the explanation. I see there's no easy way to do it, as I thought. I will have a look at NPM and see if it worth the swap.

 

[BobW]

I used npm last year when I had come across it in my search for an alternative to Synology's built-in version. And I was very happy with it until I had to renew my own certificates. Then it turns out that you have to re-link the new Certificate for each subdomain. This can not be done automatically like the built-in version of Synology. Out of frustration I went back to the standard version of Synology. I know it is only once per three months but still I don’t like.

 

[Rusty]

I know it is only once per three months but still I don’t like.

I hear you. I had the same thoughts but considering what it brings to the table decided to stay on it. Also, v3 or NPM has this in the pipeline, so hopefully this will be sorted in the future.

 

[BobW]

I hear you. I had the same thoughts but considering what it brings to the table decided to stay on it. Also, v3 or NPM has this in the pipeline, so hopefully this will be sorted in the future.

I hope v3 will solve this, because you’re right it brings much more to the table.

Maybe this can be done as a workaround for now. If you open the new pem file and then copy its content to the pem file in the nmp-1 folder (fullchain.pem) and do the same for the (privkey.pem) then it should work without having to re-link the subdomains.

I haven't tried it myself yet but in theory it should work.

 

[Rusty]

I haven't tried it myself yet but in theory it should work.

Tried it one day1. Won't work. You have to do the same thing on the DB side. But I didn't want to mess about with it considering that I have no clue (of the top of my head) how the table relations are set, so didn't want to mess things up.

 

[BobW]

Tried it one day1. Won't work. You have to do the same thing on the DB side. But I didn't want to mess about with it considering that I have no clue (of the top of my head) how the table relations are set, so didn't want to mess things up.

Okay that is indeed a shame that it doesn't work that way out of the box. We'll just have to wait and see what the next big update will bring us.

By the way, how did you do that for Bitwarden live sync? Because that was not possible without some kind of hack with the built-in version of Synology. Have you been able to do that through the npm GUI now?

 

[Rusty]

By the way, how did you do that for Bitwarden live sync?

Added advanced elements via UI

location /notifications/hub {
        proxy_pass http://nasIP:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass http://nasIP:80;
    }

ofc with mapped 3012 port and a WEBSOCKET_ENABLED set as true

 

[BobW]

Great! Thanks for sharing! I wasn’t able to figure it out when I was testing nmp last year. So maybe it is a good reason to try it again I stil have the container lying around

 

[Rusty]

Great! Thanks for sharing! I wasn’t able to figure it out when I was testing nmp last year. So maybe it is a good reason to try it again I stil have the container lying around

Bitwarden - LiveSync feature

Activate Bitwarden's live sync feature via websocket on your Synology NAS via Docker

www.blackvoid.club

here is my updated article with that npm solutions as well.

 

[Shoop]

I have also tested NPM and it works as intended but it did not seem to be able to forward the real client IP. Instead all the connections were seen as if they were coming from 172.17.0.1 (docker bridge network gateway) and adding

    location / {
        proxy_connect_timeout 60;
        proxy_read_timeout 60;
        proxy_send_timeout 60;
        proxy_intercept_errors off;
        proxy_http_version 1.1;
        proxy_set_header        Host            $http_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://NAS-IP:BWRS-PORT;
    }

to the advanced config did not solve this issue.
I needed the real IP to be able to use fail2ban for another layer of security.
So I went back to using a custom .conf file in sites-enabled and powered off NPM for now.
@Rusty , were you able to pass the real client IP to BWRS using NPM ?

 

[Rusty]

@Rusty , were you able to pass the real client IP to BWRS using NPM ?

Nope, not as of yet. Guessing that would work without any problems if the container was in the "host" network, but that's not an option with Syno considering its Nginx is already on 80/443.

I don't have the need for realIPs, but I hear you. I did try various custom headers and configurations but atm, still no results. Also, I see that most users that are in bridge with this container have the same problems, but like I said, for me, it's not a problem.

Will post back if and when I figure this out or some changes happen on the NPM docker side. From what I can tell the default conf file for NPM has all the header combinations needed to return the realip but my guess is that the bridge network is the one causing the problems.

 

[BobW]

I can seem to get it to work anymore!?
This is my config setup:

docker run -d \
 --name='npm' \
 -v /volume1/docker/npm/data:/data:rw \
 -v /volume1/docker/npm/letsencrypt:/etc/letsencrypt:rw \
 -v /etc/localtime:/etc/localtime:ro \
 -v /etc/TZ:/etc/timezone:ro \
 --hostname='npm' \
 -p 81:81 \
 -p 5080:80 \
 -p 5043:443 \
 --link mariadb:npm-db \
  --env-file /volume1/docker/npm/.env \
 --restart='always' \
 jc21/nginx-proxy-manager:latest

The container startup good no errors everything seems good. I imported my LE Wildcard Cert also good.
But when I add a subdomain pointing it to a docker container I get a 403 pag.
I have checked everything;
-Firewall
-Router port FFW
-Container port
-etc

But it isn't working! When I revert the domain back to Synology RP it works!

Any thoughts how to solve this or what I'm doing wrong?

 

[one-eyed-king]

Nope, not as of yet. Guessing that would work without any problems if the container was in the "host" network, but that's not an option with Syno considering its Nginx is already on 80/443.

I don't have the need for realIPs, but I hear you. I did try various custom headers and configurations but atm, still no results. Also, I see that most users that are in bridge with this container have the same problems, but like I said, for me, it's not a problem.

Will post back if and when I figure this out or some changes happen on the NPM docker side. From what I can tell the default conf file for NPM has all the header combinations needed to return the realip but my guess is that the bridge network is the one causing the problems.

This is spot on! It is not possible get the real ip with a bridge network.

 

[Rusty]

But when I add a subdomain pointing it to a docker container I get a 403 pag.

Does NPM reverse report “online” status for that host?

If it’s green then reverse configuration is not the problem 99%

 

[one-eyed-king]

Also you might want to check what exactly issues the 403 forbidden error along the access chain. It is either npm/nginx or the target application. You might want to check the npm/nginx logs and the target applications logs.

401 = not authentified
403 = not authorized (as in authentified, but lacks permissions to access the ressource)