[Support] Djoss - Nginx Proxy Manager


Djoss

Recommended Posts

6 minutes ago, mattie112 said:

Can you confirm that your backend works when you go to http://192.168.178.103:9981?

Do you have any other hosts configured? Do they work or do they also have problems?

 

http://192.168.178.103:9981 works fine. Other hosts works the only problem is tvheadend

Link to comment
22 minutes ago, platoboos said:

 

http://192.168.178.103:9981 works fine. Other hosts works the only problem is tvheadend

 

I installed "linuxserver/tvheadend" through the CA app store

Then I added a host to NPM

image.png.beffcdced05f55c50e290ad2c82ad94a.png

 

And yeah what can I say, I can now access it:

image.thumb.png.170b595e737d773eed6c769ac94ed884.png

 

So: what is different with your config? It seems to work just fine here.

 

Link to comment

Hi,

 

I created my certificates for my sub domains around 3 months ago and all worked fine, upon renewing them I've getting the below message.

 

image.thumb.png.d74d753d4c9695fb8bc429dd69effeae.png

 

I seem to have this problem constantly and generally reinstalled Nginx seem to fix it but this time it hasn't. Any ideas why this problem is occurring?

 

I've updated Let's entrypt to SWAG and also have the duckdns and NGINX proxy manager installed (The latter is where I'm seeing the error in the logs from).

 

Any help would be greatly appreciated.

 

Thanks in advance.

Link to comment
On 3/1/2021 at 9:33 AM, CarlM007 said:

Hi,

 

I created my certificates for my sub domains around 3 months ago and all worked fine, upon renewing them I've getting the below message.

 

image.thumb.png.d74d753d4c9695fb8bc429dd69effeae.png

 

I seem to have this problem constantly and generally reinstalled Nginx seem to fix it but this time it hasn't. Any ideas why this problem is occurring?

 

I've updated Let's entrypt to SWAG and also have the duckdns and NGINX proxy manager installed (The latter is where I'm seeing the error in the logs from).

 

Any help would be greatly appreciated.

 

Thanks in advance.

 

Same problem. The command to renew is no longer working. You can roll back to the version released before 02/08 or create a new docker with the same configuration.  Both worked for me. I was unsuccessful in using my previous appdata folder. a brandnew install was required.

Link to comment
On 2/12/2021 at 8:48 AM, Djoss said:

I'm not sure to understand the issue with NAT loopback.  It seems to be an easier solution since you don't need to override local DNS... ?

A couple reasons. Firstly as other people have said, speed and keeping things local when you are on your LAN and don't have a need to go out on the internet and expose that traffic (yes I get the loopback doesn't technically get out on the net, but there's a DNS query, and it's generally the principle of things). Secondly, which is what my impediment is, not everyone's router supports NAT loopback. Mine is an ISP supplied router that handles both my internet and TV service running on a fibre connection, and replacing it would require me spending quite a bit more to get a SFP based router that I can put a custom config on to support the TV service, plus getting an additional Access Point. Just not cash that I want to spend right now.

What I'm trying to understand is why you decided to change the ports in the docker container from their defaults. Generally curious as to this decision, because I would have thought it would have been better to leave them on their defaults, and use the CA template to set the "external" ports to something else.

Link to comment
On 2/5/2021 at 5:50 PM, mattie112 said:

You can use my fork for now:

https://hub.docker.com/r/mattie112/docker-nginx-proxy-manager

(which I will delete if/when this gets implemented by Djoss)

 

My fork is 100% the same code except that it listens on 80/443. Here is the diff if you are concerned: https://github.com/jlesage/docker-nginx-proxy-manager/compare/master...Mattie112:default-ports

Thanks @mattie112. I don't use NPM personally, as I set all my stuff up on SWAG before NPM was available, but decided to give it a quick shot after I started helping a couple guys on reddit and was confused as to why it wasn't working. One quick question for you: Why did you choose to leave the WebUI port as 8181 rather then setting it back to 81 as the official container has it? Would it be because the CA template wouldn't support opening directly any more, and you'd have to do an advanced edit to set the port yourself?

Link to comment
On 3/4/2021 at 5:34 AM, Caldorian said:

Thanks @mattie112. I don't use NPM personally, as I set all my stuff up on SWAG before NPM was available, but decided to give it a quick shot after I started helping a couple guys on reddit and was confused as to why it wasn't working. One quick question for you: Why did you choose to leave the WebUI port as 8181 rather then setting it back to 81 as the official container has it? Would it be because the CA template wouldn't support opening directly any more, and you'd have to do an advanced edit to set the port yourself?

 

No reason really, I only care about 80/443 the WebUI port is fine on 8181 but it would also be fine on any other port :)

Link to comment
On 3/1/2021 at 4:25 PM, mattie112 said:

 

I installed "linuxserver/tvheadend" through the CA app store

Then I added a host to NPM

image.png.beffcdced05f55c50e290ad2c82ad94a.png

 

And yeah what can I say, I can now access it:

image.thumb.png.170b595e737d773eed6c769ac94ed884.png

 

So: what is different with your config? It seems to work just fine here.

 

 

I resolved my problem. I change the docker network settings for other networks to "yes"

 

thanks

Bildschirmfoto vom 2021-03-07 10-59-03.png

Link to comment

Been using this for some time and once I got over some initial setup issues, has work well for 6-12 months. Now it seems to be broken. In looking through the last several pages, it seems to be broken for other folks as well.

I am getting the dreaded "internal error" when I try to setup a proxy host.

I have removed the docker and appdata as there seemed to be issues there and felt starting clean would be good. It cleared many of the errors that were there.

One of the posts mentions that on port forwarding on your your router that you should now be using 8080 and 4443 (instead of 1880 and 18443) - Is this correct?

And if so - where do you swap in 8080 and 4442?

  • Just on your router port forward settings?
  • In the docker setup settings?
  • Both?

 

Thanks!!

EDIT: Now have it working.

I am on CloudFlare and forgot to make it "DNS ONLY" rather thn the Proxy Service. I would assume it is better to run the proxy service for the extra protection?

Still curious on what ports one should be using in the docker.

I moved to 8080 and 4442?


 

Edited by TexasDave
Link to comment

Hi,

 

I am having difficulties setting up NPM so that my ombi docker can be accessed publicly.

 

Problem: When trying to resolve requests.mydomain.ca I get ERR_CONNECTION_TIMED_OUT

 

My setup:

Registrar - Google domain (mydomain.ca). The only DNS record is an A record (mydomain.ca > My.Public.IP)

Cloudflare - (Changed Google DNS settings to Cloudflare's name servers). Created an A record in Cloudflare (requests.mydomain.ca > My.Public.IP)

Ombi docker is setup on InternalIP:3579

NPM - Docker ports 1880/18443 - My ISP is seemly blocking port 80/443 so I created the SSL certificate using Cloudflare API token DNS challenge for *.mydomain.ca. Created a proxy host for requests.mydomain.ca with the destination internalIP:3579 and the SSL from *.mydomain.ca and ACCESS Public

UnRAID Network Setting - I have tried NPM and Ombi both on Network Type: Bridge and together on their own custom network

Router - forwarded ports 80/443 to 1880/18443 and tried forwarding 1880 to 1880/18443 to 18443

 

MISC:

- whatsmydns.net shows that the DNS is working

- I can ping My.Public.IP

 

What's interesting is that I was able to setup public access to my Ombi docker by exactly following spaceinvaderone's video "How to Setup and Configure a Reverse Proxy on unRAID with LetsEncrypt & NGINX" with using ONLY subdomains provided by duckdns and all I want to do is use my own domain.

 

Is what I am trying to do impossible with port 80/443 blocked by my ISP? I get the same error using https://requests.mydomain.ca:18442


Not sure if there is something I am missing but I have sunk countless hours on this. Any help would be appreciated.

 

Thanks.

Edited by corradojeff
Additional details.
Link to comment
On 3/2/2021 at 5:49 PM, rukiftw said:

 

Same problem. The command to renew is no longer working. You can roll back to the version released before 02/08 or create a new docker with the same configuration.  Both worked for me. I was unsuccessful in using my previous appdata folder. a brandnew install was required.

 

Thanks for the above, I rolled back to before 02/08 and it did the trick. Cheers :)

Link to comment
On 3/3/2021 at 11:18 PM, Caldorian said:

What I'm trying to understand is why you decided to change the ports in the docker container from their defaults. Generally curious as to this decision, because I would have thought it would have been better to leave them on their defaults, and use the CA template to set the "external" ports to something else.

The main reason was to avoid using privileged ports.  This allows nginx to not run as root.

Link to comment

Hi there,

 

Hoping this is the right place to report issues.. if not, please redirect as needed. Also, sorry for the long post.

 

TL;DR: Bitwarden on NPM results in 'unexpected error' on login. Bitwarden on SWAG results in no issues.

 

SETUP:

Host OS: Unraid 6.9.1

Containers with issues: Bitwarden (via docker-compose) and NginxProxyManager

 

I've spent this weekend trying to migrate from SWAG to NPM (mainly for testing, but having a UI to do most of the NGINX work is nice too). All my containers work, except Bitwarden... this one keeps failing intermittently. I've also implemented Authelia with NPM following https://github.com/ibracorp/authelia and that works too.

 

I've been unable to use Bitwarden_rs with my Unraid server (see https://github.com/dani-garcia/bitwarden_rs/issues/1071), but have had SWAG work with my Bitwarden install (via docker-compose) without issue for several months. 

 

After setting up my Bitwarden instance under NPM, I am able to authenticate using Authelia, which redirects to the public Bitwarden address I have setup, but after attempting to login, it fails for 'unexpected error has occurred'. I've tried digging through the bitwarden-mssql, bitwarden-admin and bitwarden-nginx logs for errors, but none appear. If I turn off NPM and swap back to SWAG, I can log in without error.

 

Configs:

 

SWAG:-

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name bitwarden.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 128M;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    # include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        # include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden-nginx;
        set $upstream_port 8080;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
	
	location /admin {
		return 404;
	}

    location /notifications/hub {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden-nginx/;
        set $upstream_port 8080;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }

    location /notifications/hub/negotiate {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden-nginx;
        set $upstream_port 8080;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
	
}

 

NPM:-

 

image.png.dade9ec5a1d77b792341767699b8c6cd.png

 

image.png.bff0533050e5c33ffd89be5fe02e4df0.png

 

location /authelia {
internal;
set $upstream_authelia http://192.168.1.100:9091/api/verify;
proxy_pass_request_body off;
proxy_pass $upstream_authelia;    
proxy_set_header Content-Length "";

# Timeout if the real server is dead
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
client_body_buffer_size 128k;
proxy_set_header Host $host;
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr; 
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Uri $request_uri;
proxy_set_header X-Forwarded-Ssl on;
proxy_redirect  http://  $scheme://;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 4 32k;

send_timeout 5m;
proxy_read_timeout 240;
proxy_send_timeout 240;
proxy_connect_timeout 240;
}

location / {
set $upstream_app bitwarden-nginx;
set $upstream_port 8080;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;

location /notifications/hub {
set $upstream_app bitwarden-nginx/;
set $upstream_port 8080;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}

location /notifications/hub/negotiate {
set $upstream_app bitwarden-nginx;
set $upstream_port 8080;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}

auth_request /authelia;
auth_request_set $target_url https://$http_host$request_uri;
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
error_page 401 =302 https://<auth.domain.com>/?rd=$target_url;

client_body_buffer_size 128k;

proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

send_timeout 5m;
proxy_read_timeout 360;
proxy_send_timeout 360;
proxy_connect_timeout 360;

proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;
proxy_set_header Accept-Encoding gzip;
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_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Uri $request_uri;
proxy_set_header X-Forwarded-Ssl on;
proxy_redirect  http://  $scheme://;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 64 256k;

set_real_ip_from 192.168.1.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

}

 

I've tried cycling SSL, HSTS and HTTP2 on and off with no difference to the outcome. I can also access the local IP of Bitwarden and login without error while NPM is configured, which makes me think this is specifically an NPM problem. Happy to be corrected.

 

Any help would be appreciated. Thanks for reading.

 

EDIT: The 'auth.domain.com' is normally filled in, but has been substituted for posting purposes (is normally auth.<mydomain>.<mydomain>)

 

EDIT2: After many hours of pulling my hair out, finally resolved the issue.

 

Turns out the configs between SWAG and NPM are defined slightly differently. In SWAG, the bitwarden-nginx port is pointed to 8080, however in NPM it needed to be pointed to my custom port that was defined during the docker-compose... Now it works without issue!

 

Edited by evakq8r
Fixed
Link to comment
On 1/4/2021 at 4:56 AM, CorneliousJD said:

I'm tight on time right now but hope this helps. If not let me know - can work to gather more info later.

 

 

Primary domain.com setup in NPM which hosts Organizr -- this should be perfectly straight forward.

image.png.7112c2d565b1cc1cab4d165b9dda0c3e.png

 

Next is custom locations. - first part is for organizr auth - you can ignore this part if you don't want it, and focus on the /web part at the bottom.

NOTE the HTTPS part on my /web -- I needed this to get it to work correctly, and it HAD to be /web too, /plex didn't work for me here at all.

 

image.thumb.png.c24f0fa75ea90604371c5553b36a6254.png

 

Organizr SSO settings.

image.png.3be487ae977ad60556dbcfd107d963aa.png

 

Media/Plex tab settings.

 

image.thumb.png.4f10df6482b4c131eca6587cb2520549.png

 

Happy to try and help more if this doesn't do it for you - but replicate this exactly first and if it's still erroring out let me know. 

 

 

 

I finally manage to get back to this and happy to say it works now thanks to you. i really appreciate it!

thanks so much!

Link to comment

Hi everyone 

 

I have been using NPM for a while it's running great for when I specifically assign a domain per IP:PORT.

 

One of the features I was looking for but couldn't find or don't know how to do on NPM yet, is when I have more than one server or IP that I want to balance them. 

 

To explain, lets say 192.168.1.2, 192.168.1.3 and 192.168.1.4 are a kubernetes group with kub.example.com domain and any kub.example.com and *.kub.example.com requests should be forwarded to the cluster.

 

Does anyone know how? 

 

Thanks in advance. 

Link to comment
3 hours ago, mosaati said:

Hi everyone 

 

I have been using NPM for a while it's running great for when I specifically assign a domain per IP:PORT.

 

One of the features I was looking for but couldn't find or don't know how to do on NPM yet, is when I have more than one server or IP that I want to balance them. 

 

To explain, lets say 192.168.1.2, 192.168.1.3 and 192.168.1.4 are a kubernetes group with kub.example.com domain and any kub.example.com and *.kub.example.com requests should be forwarded to the cluster.

 

Does anyone know how? 

 

Thanks in advance. 

I don't think this option exists in NPM but you can inject your own nginx config so perhaps you can do it manually?

http://nginx.org/en/docs/http/load_balancing.html

Link to comment
22 minutes ago, mattie112 said:

I don't think this option exists in NPM but you can inject your own nginx config so perhaps you can do it manually?

http://nginx.org/en/docs/http/load_balancing.html

Thanks for the reply.

 

Yeah it's not available out of the box yet. I tried different combinations in the advanced tab but nothing worked so far. I thought I might ask maybe someone had tried and found the correct syntax.

Link to comment

Anyone get Overseerr working with NPM and Cloudflare?

I have Ombi and a few others working fine with NPM and CF but cannot seem to get Overseer to work. I get a 502 error. Setup in NPM seems to be all good.

I am sure it is a trvial thing that I did for my other services but cannot figure it out....

They have instructions for SWAG and Nginx- does anything jump out from this link?

https://docs.overseerr.dev/extending-overseerr/reverse-proxy-examples
 

EDIT: I fixed it. Typo in Nginx Proxy Manager Setup. Extra  "one" in my IP. I knew it was something stoopid. Thanks!

Edited by TexasDave
  • Haha 1
Link to comment

Has anyone managed to get this working with the Full (Strict) SSL Cert option on Cloudfare?

 

I've created an Origin Server key and certificate with the relevant *.mywebsite.com and mywebsite.com headers.

 

I've then uploaded that to Nginx Proxy Manager as a custom cert and then selected my proxy hosts to use it. I've also selected to force SSL but I keep getting:

 

Error 525

SSL handshake failed

Host error

 

What happened?

Cloudflare is unable to establish an SSL connection to the origin server.

 

I followed all the instructions on Cloudfare's website and there does not seem to be any other steps. Not sure why it doesn't work.

 

The "Flexible" setting on Cloudfare works but I want to make use of the cert that they offer for free, so visitors get end-to-end encryption.

 

EDIT: Also very important to mention that the "Force SSL" option on Nginx Proxy Manager causes an infinite redirect error when used in parallel with Cloudfare's "Always HTTPS" mode... cost me at least 5 hours of troubleshooting thanks to that... Not sure which is best to use but I've opted to keep it off on NPM and on, on Cloudfare.

Edited by plantsandbinary
Link to comment
25 minutes ago, plantsandbinary said:

Has anyone managed to get this working with the Full (Strict) SSL Cert option on Cloudfare?

 

I've created an Origin Server key and certificate with the relevant *.mywebsite.com and mywebsite.com headers.

 

I've then uploaded that to Nginx Proxy Manager as a custom cert and then selected my proxy hosts to use it. I've also selected to force SSL but I keep getting:

 

Error 525

SSL handshake failed

Host error

 

What happened?

Cloudflare is unable to establish an SSL connection to the origin server.

 

I followed all the instructions on Cloudfare's website and there does not seem to be any other steps. Not sure why it doesn't work.

 

The "Flexible" setting on Cloudfare works but I want to make use of the cert that they offer for free, so visitors get end-to-end encryption.

 

EDIT: Also very important to mention that the "Force SSL" option on Nginx Proxy Manager causes an infinite redirect error when used in parallel with Cloudfare's "Always HTTPS" mode... cost me at least 5 hours of troubleshooting thanks to that... Not sure which is best to use but I've opted to keep it off on NPM and on, on Cloudfare.

consider watching   about half way through goes through setting it up 

 

Link to comment

Thanks mate but I actually followed that exact video and still got the error I mentioned :(

 

EDIT: Got it all sorted except for this:

 

Quote

EDIT: Also very important to mention that the "Force SSL" option on Nginx Proxy Manager causes an infinite redirect error when used in parallel with Cloudfare's "Always HTTPS" mode... cost me at least 5 hours of troubleshooting thanks to that... Not sure which is best to use but I've opted to keep it off on NPM and on, on Cloudfare.

 

... anyway most of my problems were due to running my containers on different virtual networks...

Edited by plantsandbinary
Link to comment

There appears to be a bug in this package: If I use the "br0" interface for the connection, i.e. the container obtains its own IP address from the DHCP server/router in the network in which unraid lives, the http/https ports that I specify are ignored. The default values, e.g. 8080, are used, which is bad in case you just want ot use normal http/https behaviour (but with its own ip) and your router doesn't allow portforwarding to another port.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.