syniex Posted May 25, 2018 Share Posted May 25, 2018 I'm having problems with setting up the https to work, Always getting "ERR_CONNECTION_REFUSED" but inside the lan i can access the domain with port 444. I did port forwarding from 443 to 444 on my Router, but always getting connection refused on unraid syslog i see this error: "2018/05/25 13:26:44 [error] 6731#6731: *47077 connect() to unix:/var/tmp/letsencrypt.sock failed (111: Connection refused) while connecting to upstream, client: 172.27.224.3, server: , request: "GET /dockerterminal/letsencrypt/ws HTTP/1.1", upstream: "http://unix:/var/tmp/letsencrypt.sock:/ws"" any help will be appreciated Quote Link to comment
Aurao Posted May 25, 2018 Share Posted May 25, 2018 16 hours ago, aptalca said: You need to create a new server block for the second domain the same way you create new server blocks for subdomains. Look at the cp subdomain example and replicate it what is the CP example? I'm not seeing it in my appdata files Quote Link to comment
aptalca Posted May 25, 2018 Share Posted May 25, 2018 37 minutes ago, Aurao said: what is the CP example? I'm not seeing it in my appdata files In your default site config: https://github.com/linuxserver/docker-letsencrypt/blob/master/root/defaults/default#L54 Quote Link to comment
Aurao Posted May 26, 2018 Share Posted May 26, 2018 (edited) 4 hours ago, aptalca said: In your default site config: https://github.com/linuxserver/docker-letsencrypt/blob/master/root/defaults/default#L54 I'm not making much sense of that to be honest. I don't know what the location would be even after looking at that. To say that my code knowledge is mediocre would be an exaggeration. this is my site-conf (also below) https://pastebin.com/ZLVDceq5 ----------------------------------------- upstream backend { server 192.168.1.105:19999; keepalive 64; } server { listen 443 ssl default_server; listen 80 default_server; root /config/www; index index.html index.htm index.php; server_name nextcloud.domainA.com; ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'NO IDEA IF THIS IS IMPORTANT SO I DELETED IT'; ssl_prefer_server_ciphers on; client_max_body_size 0; location domainB.com/sonarr { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:8989/sonarr; } location /radarr { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:7878/radarr; } location /sabnzbd { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:8081/sabnzbd; } #PLEX location /web { # serve the CSS code proxy_pass http://192.168.1.105:32400; } # Main /plex rewrite location /plex { # proxy request to plex server proxy_pass http://192.168.1.105:32400/web; } #OMBI CONTAINER location /ombi { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:3579/ombi; } if ($http_referer ~* /ombi/) { rewrite ^/dist/([0-9\d*]).js /ombi/dist/$1.js last; } location /plexpy { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:8181/plexpy; } location /nextcloud { include /config/nginx/proxy.conf; proxy_pass https://192.168.1.105:444/nextcloud; } } Edited May 26, 2018 by Aurao Quote Link to comment
Hoanh Posted May 26, 2018 Share Posted May 26, 2018 On 5/24/2018 at 1:11 PM, Pducharme said: anyone has a working config for a Nextcloud Reverse proxy with NGINX? (Lets'Encrypt Docker). My apache docker died yesterday like everyone else that tried to restart it. I moved all my other Reverse proxies with much effort, but the NextCloud one doesnt want. Also, what are in your working config file of Nextcloud itselft (not just the NGINX config). Thanks I have the same situation like you. followed this one. It works perfectly for my case. https://cyanlabs.net/tutorials/the-complete-unraid-reverse-proxy-duck-dns-dynamic-dns-and-letsencrypt-guide/ And don't forget to enable nat reflection and automatic outbound "Pfsense system / advanced / nat, enable nat reflection and automatic outbound" Quote Link to comment
aptalca Posted May 26, 2018 Share Posted May 26, 2018 8 hours ago, Hoanh said: I have the same situation like you. followed this one. It works perfectly for my case. https://cyanlabs.net/tutorials/the-complete-unraid-reverse-proxy-duck-dns-dynamic-dns-and-letsencrypt-guide/ And don't forget to enable nat reflection and automatic outbound "Pfsense system / advanced / nat, enable nat reflection and automatic outbound" There is a built in site config for nextcloud: https://github.com/linuxserver/docker-letsencrypt/blob/master/README.md#site-config-and-reverse-proxy Quote Link to comment
aptalca Posted May 26, 2018 Share Posted May 26, 2018 (edited) 13 hours ago, Aurao said: I'm not making much sense of that to be honest. I don't know what the location would be even after looking at that. To say that my code knowledge is mediocre would be an exaggeration. this is my site-conf (also below) https://pastebin.com/ZLVDceq5 ----------------------------------------- upstream backend { server 192.168.1.105:19999; keepalive 64; } server { listen 443 ssl default_server; listen 80 default_server; root /config/www; index index.html index.htm index.php; server_name nextcloud.domainA.com; ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'NO IDEA IF THIS IS IMPORTANT SO I DELETED IT'; ssl_prefer_server_ciphers on; client_max_body_size 0; location domainB.com/sonarr { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:8989/sonarr; } location /radarr { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:7878/radarr; } location /sabnzbd { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:8081/sabnzbd; } #PLEX location /web { # serve the CSS code proxy_pass http://192.168.1.105:32400; } # Main /plex rewrite location /plex { # proxy request to plex server proxy_pass http://192.168.1.105:32400/web; } #OMBI CONTAINER location /ombi { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:3579/ombi; } if ($http_referer ~* /ombi/) { rewrite ^/dist/([0-9\d*]).js /ombi/dist/$1.js last; } location /plexpy { include /config/nginx/proxy.conf; proxy_pass http://192.168.1.105:8181/plexpy; } location /nextcloud { include /config/nginx/proxy.conf; proxy_pass https://192.168.1.105:444/nextcloud; } } You can't put in a domain name in a location directive like that. Location is for subfolders, server block and server name are for domain names. For handling two domains differently, you need to create two server blocks, one will have server name of domain A and the other will have domain B Look at that cp example I linked to. It is a second server block where the server name is set to a different subdomain (cp.*). You can change that to domain B It's not really coding. It's a basic nginx config. If you're still confused, there are plenty of how tos and guides online about how the different sections in the nginx site config work EDIT: also if you have no idea what something does, rule of thumb is, don't delete it. Everything in that default config is put there for a reason. Deleting things randomly is a recipe for breakage. And don't put random text in places without commenting them out. Nginx will try to interpret it as actual settings and will error out. Edited May 26, 2018 by aptalca Quote Link to comment
Aurao Posted May 26, 2018 Share Posted May 26, 2018 (edited) 40 minutes ago, aptalca said: You can't put in a domain name in a location directive like that. Location is for subfolders, server block and server name are for domain names. For handling two domains differently, you need to create two server blocks, one will have server name of domain A and the other will have domain B Look at that cp example I linked to. It is a second server block where the server name is set to a different subdomain (cp.*). You can change that to domain B It's not really coding. It's a basic nginx config. If you're still confused, there are plenty of how tos and guides online about how the different sections in the nginx site config work EDIT: also if you have no idea what something does, rule of thumb is, don't delete it. Everything in that default config is put there for a reason. Deleting things randomly is a recipe for breakage. And don't put random text in places without commenting them out. Nginx will try to interpret it as actual settings and will error out. thank you, my issue has been that i have been following tutorials but they dont really tell you why you are doing something and only how to do it. That has put me in limbo. I'll look into some guides Edited May 26, 2018 by Aurao Quote Link to comment
ICDeadPpl Posted May 27, 2018 Share Posted May 27, 2018 Does reverse proxying nzbGet, Sonarr, Radarr, etc, affect connectivity from outside of the LAN and third party apps? Thinking of mobile apps (NzbManager & Nzb360) and Usenet indexing sites, which allow clicking and submitting a post to NzbGet via a button. Which authorization method should one use? The app's built in ones, or have Nginx manage it? Quote Link to comment
CHBMB Posted May 27, 2018 Share Posted May 27, 2018 Does reverse proxying nzbGet, Sonarr, Radarr, etc, affect connectivity from outside of the LAN and third party apps? Thinking of mobile apps (NzbManager & Nzb360) and Usenet indexing sites, which allow clicking and submitting a post to NzbGet via a button. Which authorization method should one use? The app's built in ones, or have Nginx manage it?NZB360 works fine with a reverse proxy using nginx auth Quote Link to comment
dalben Posted May 28, 2018 Share Posted May 28, 2018 I have an issue where when this docker stops and restarts (nightly backup, etc) the port forwarding from my router (USG using the LSIO Unifi Docker) no longer works. I have to restart the Unifi container/controller for the port forwarding to work. Does anyone else have this combo of containers and experiencing the same problem ? Quote Link to comment
Gog Posted May 28, 2018 Share Posted May 28, 2018 I'm trying to setup the reverse proxy for Tautulli. I'm posting here since I'm using the "standard" tautulli template. I can kick it to the other forum if you prefer. I hadn't touched the letsencrypt setup in a while so I reverted nginx\site-confs\default and nginx\nginx.conf to the default setup I got from the repo and moved my old default settings in proxy-confs subfolder and subdomain config files. Clean and easy setup, kudos on that one. I followed the instructions in nginx\proxy-confs\_readme and was able to get sonarr working with the samples as is. Tautulli on the other hand behaves a bit wonky. Disclaimer: tautulli reverse proxy never worked before, it's a new setup. All that to say that https://example.com/tautulli gets redirected to https://_/tautulli/ (that's in in chrome, can't be displayed in IE) while https://example.com/tautulli/home works. In letsencrypt error.log I see this: 2018/04/28 00:15:28 [error] 375#375: *105 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: pc_IP, server: _, request: "HEAD /tautulli/index HTTP/1.1", upstream: "http://internal_IP:8181/tautulli/index", host: "example.com", referrer: "https://example.com/tautulli/restart" http://internal_IP:8181/tautulli/index gets resolved to http://internal_IP:8181/tautulli/home when not going through the proxy. Everything else seems fine until I try to register the android app. When I register from http://internal_IP:8181/tautulli/settings#tab_tabs-android_app, everything works. If I register from https://example.com/tautulli/settings#tab_tabs-android_app, no dice, the device is not registered and doesn't work. Anyone has a clue? Thanks. Quote Link to comment
aptalca Posted May 28, 2018 Share Posted May 28, 2018 19 minutes ago, Gog said: I'm trying to setup the reverse proxy for Tautulli. I'm posting here since I'm using the "standard" tautulli template. I can kick it to the other forum if you prefer. I hadn't touched the letsencrypt setup in a while so I reverted nginx\site-confs\default and nginx\nginx.conf to the default setup I got from the repo and moved my old default settings in proxy-confs subfolder and subdomain config files. Clean and easy setup, kudos on that one. I followed the instructions in nginx\proxy-confs\_readme and was able to get sonarr working with the samples as is. Tautulli on the other hand behaves a bit wonky. Disclaimer: tautulli reverse proxy never worked before, it's a new setup. All that to say that https://example.com/tautulli gets redirected to https://_/tautulli/ (that's in in chrome, can't be displayed in IE) while https://example.com/tautulli/home works. In letsencrypt error.log I see this: 2018/04/28 00:15:28 [error] 375#375: *105 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: pc_IP, server: _, request: "HEAD /tautulli/index HTTP/1.1", upstream: "http://internal_IP:8181/tautulli/index", host: "example.com", referrer: "https://example.com/tautulli/restart" http://internal_IP:8181/tautulli/index gets resolved to http://internal_IP:8181/tautulli/home when not going through the proxy. Everything else seems fine until I try to register the android app. When I register from http://internal_IP:8181/tautulli/settings#tab_tabs-android_app, everything works. If I register from https://example.com/tautulli/settings#tab_tabs-android_app, no dice, the device is not registered and doesn't work. Anyone has a clue? Thanks. In tautulli settings, did you check "enable http proxy" and "enable https"? If so, don't. Also, did you modify the tautulli proxy conf file to put in the internal ip? You weren't supposed to modify it at all. Only set the http root and restart the tautulli container, then rename the conf file and restart letsencrypt. That's all. Quote Link to comment
Gog Posted May 28, 2018 Share Posted May 28, 2018 1 hour ago, aptalca said: In tautulli settings, did you check "enable http proxy" and "enable https"? If so, don't. Also, did you modify the tautulli proxy conf file to put in the internal ip? You weren't supposed to modify it at all. Only set the http root and restart the tautulli container, then rename the conf file and restart letsencrypt. That's all. I had changed "enable http proxy" but not https. The only change I did on the proxy conf file was to remove the comments before the authentication parameters. I did a fresh tautulli reinstall just to be sure. That got rid of the weird https://_/tautulli/ but the android app is still not connecting. I guess I'm due for a fresh letsencrypt container too. Good thing that the new way of storing config makes that easy. I'll be back... Quote Link to comment
Gog Posted May 28, 2018 Share Posted May 28, 2018 Well, I reinstalled everything and now I feel like a fool. It seems the Tautulli app doesn't support the basic authentication that I was enabling... Quote Link to comment
aptalca Posted May 29, 2018 Share Posted May 29, 2018 2 hours ago, Gog said: Well, I reinstalled everything and now I feel like a fool. It seems the Tautulli app doesn't support the basic authentication that I was enabling... Oh yeah, the tautulli mobile app doesn't support other auth methods. I had to switch to the built in authentication in tautulli Quote Link to comment
Anthop Posted June 1, 2018 Share Posted June 1, 2018 I'm working on my first unRAID setup, but am stuck getting the Let's Encrypt docker to work properly. I've been following a few tutorials (namely the CyanLabs), but I seem to be missing a step or something. I'm using the Let's Encrypt docker provided by linuxserver. Please redirect me if this is not the correct place to post. I get the following errors in the Docker log: Performing the following challenges: http-01 challenge for skybox.mydomain.org Waiting for verification... Cleaning up challenges Failed authorization procedure. skybox.mydomain.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://Paravati.local:443/.well-known/acme-challenge/T5M9XzFvy-wl_UkG9dspNJ6oUcg-7DVm6X8YnBEYt8Y: Error getting validation data IMPORTANT NOTES: - The following errors were reported by the server: Domain: skybox.mydomain.org Type: connection Detail: Fetching https://Paravati.local:443/.well-known/acme-challenge/T5M9XzFvy-wl_UkG9dspNJ6oUcg-7DVm6X8YnBEYt8Y: Error getting validation data It looks like the issue is two fold: It looks like Nginx is redirecting my requests to Paravati.local:443, for some reason. I'm not sure if this is the intended behavior. I confirmed this by issuing a GET command via curl to https://skybox.mydomain.org over the Internet (not the same LAN) and getting back a 302 response that takes me to https://paravati.local:443. Paravati.local:443 is the unRAID GUI, and it doesn't appear that the ACME challenge files/keys are actually hosted here. anthop@NATSUKI-3:~$ curl -kv https://skybox.mydomain.org * Rebuilt URL to: https://skybox.mydomain.org/ * Trying XXX.XXX.XXX.XXX... * TCP_NODELAY set * Connected to skybox.mydomain.org (XXX.XXX.XXX.XXX) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /home/anthop/anaconda3/ssl/cacert.pem CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: O=Self-signed; OU=unRAID; CN=Paravati.local * start date: May 29 06:58:56 2018 GMT * expire date: May 26 06:58:56 2028 GMT * issuer: O=Self-signed; OU=unRAID; CN=Paravati.local * SSL certificate verify result: self signed certificate (18), continuing anyway. > GET / HTTP/1.1 > Host: skybox.mydomain.org > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 302 Moved Temporarily < Server: nginx < Date: Fri, 01 Jun 2018 00:59:37 GMT < Content-Type: text/html < Content-Length: 154 < Connection: keep-alive < Location: Main < <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> <hr><center>nginx</center> </body> </html> * Curl_http_done: called premature == 0 * Connection #0 to host skybox.mydomain.org left intact I'm running unRAID 6.5.2. Paravati is the name of the unRAID tower. I have the Let's Encrypt docker running on ports 1080 and 1443 (and port forwarding is enabled on the router to those locations). I'm not entirely clear if I'm supposed to be touching the Nginx config file, but none of the tutorials have mentioned needing to do this, so I'm wondering if I'm missing something obvious. Any help would be greatly appreciated! Quote Link to comment
psm321 Posted June 1, 2018 Share Posted June 1, 2018 On 3/22/2018 at 11:40 PM, psm321 said: Are there by chance any hooks in the startup of the container to run a custom user script? I need to patch the certbot rfc2136 plugin with some hacks to get it to work with my DNS provider (I don't understand my hacks well enough to actually submit upstream). I figure I'll probably need to build my own container layer on top, but wanted to check before going ahead with that. I just wanted to bump this once before working on a custom container as I'm coming up on renewal. Sorry if I missed a reply somewhere, didn't find one in a quick search. Quote Link to comment
CHBMB Posted June 1, 2018 Share Posted June 1, 2018 (edited) 11 hours ago, psm321 said: I just wanted to bump this once before working on a custom container as I'm coming up on renewal. Sorry if I missed a reply somewhere, didn't find one in a quick search. There's a way to do so, but it's unsupported, so once you do so, you're on your own. Scripts in this directory are run at startup So you could map like this -v '/mnt/cache/appdata/letsencrypt/60-customscript:'/etc/cont.init.d/60-customscript' Scripts in that directory are run in numerical/alphabetical order. Edited June 1, 2018 by CHBMB 1 Quote Link to comment
CHBMB Posted June 1, 2018 Share Posted June 1, 2018 17 hours ago, Anthop said: I'm working on my first unRAID setup, but am stuck getting the Let's Encrypt docker to work properly. I've been following a few tutorials (namely the CyanLabs), but I seem to be missing a step or something. I'm using the Let's Encrypt docker provided by linuxserver. Please redirect me if this is not the correct place to post. I get the following errors in the Docker log: Performing the following challenges: http-01 challenge for skybox.mydomain.org Waiting for verification... Cleaning up challenges Failed authorization procedure. skybox.mydomain.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://Paravati.local:443/.well-known/acme-challenge/T5M9XzFvy-wl_UkG9dspNJ6oUcg-7DVm6X8YnBEYt8Y: Error getting validation data IMPORTANT NOTES: - The following errors were reported by the server: Domain: skybox.mydomain.org Type: connection Detail: Fetching https://Paravati.local:443/.well-known/acme-challenge/T5M9XzFvy-wl_UkG9dspNJ6oUcg-7DVm6X8YnBEYt8Y: Error getting validation data It looks like the issue is two fold: It looks like Nginx is redirecting my requests to Paravati.local:443, for some reason. I'm not sure if this is the intended behavior. I confirmed this by issuing a GET command via curl to https://skybox.mydomain.org over the Internet (not the same LAN) and getting back a 302 response that takes me to https://paravati.local:443. Paravati.local:443 is the unRAID GUI, and it doesn't appear that the ACME challenge files/keys are actually hosted here. anthop@NATSUKI-3:~$ curl -kv https://skybox.mydomain.org * Rebuilt URL to: https://skybox.mydomain.org/ * Trying XXX.XXX.XXX.XXX... * TCP_NODELAY set * Connected to skybox.mydomain.org (XXX.XXX.XXX.XXX) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /home/anthop/anaconda3/ssl/cacert.pem CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: O=Self-signed; OU=unRAID; CN=Paravati.local * start date: May 29 06:58:56 2018 GMT * expire date: May 26 06:58:56 2028 GMT * issuer: O=Self-signed; OU=unRAID; CN=Paravati.local * SSL certificate verify result: self signed certificate (18), continuing anyway. > GET / HTTP/1.1 > Host: skybox.mydomain.org > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 302 Moved Temporarily < Server: nginx < Date: Fri, 01 Jun 2018 00:59:37 GMT < Content-Type: text/html < Content-Length: 154 < Connection: keep-alive < Location: Main < <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> <hr><center>nginx</center> </body> </html> * Curl_http_done: called premature == 0 * Connection #0 to host skybox.mydomain.org left intact I'm running unRAID 6.5.2. Paravati is the name of the unRAID tower. I have the Let's Encrypt docker running on ports 1080 and 1443 (and port forwarding is enabled on the router to those locations). I'm not entirely clear if I'm supposed to be touching the Nginx config file, but none of the tutorials have mentioned needing to do this, so I'm wondering if I'm missing something obvious. Any help would be greatly appreciated! You need to port forward 443 externally to 1443 on your Unraid server Quote Link to comment
psm321 Posted June 1, 2018 Share Posted June 1, 2018 8 minutes ago, CHBMB said: There's a way to do so, but it's unsupported, so once you do so, you're on your own. Scripts in this directory are run at startup So you could map like this -v '/mnt/cache/appdata/letsencrypt/60-customscript:'/etc/cont.init.d/60-customscript' Scripts in that directory are run in numerical/alphabetical order. Perfect, thanks! Quote Link to comment
Anthop Posted June 1, 2018 Share Posted June 1, 2018 (edited) 10 minutes ago, CHBMB said: You need to port forward 443 externally to 1443 on your Unraid server skybox.mydomain.org:443 is port forwarded to paravati:1443 at the router. I have the following port forwards in place: external:80 -> paravati:1080 external:443 -> paravati:1443 The issue occurs because Nginx is sending back an HTTP redirect response that sends me to paravati:443, an address that doesn't even exist outside of the LAN. Edited June 1, 2018 by Anthop Quote Link to comment
CHBMB Posted June 1, 2018 Share Posted June 1, 2018 1 minute ago, Anthop said: The issue occurs because Nginx is sending back an HTTP redirect response that sends me to paravati:443, an address that doesn't even exist outside of the LAN. That's not the case as Nginx in the container isn't started until after the certificate process has occured Quote Link to comment
Anthop Posted June 1, 2018 Share Posted June 1, 2018 2 minutes ago, CHBMB said: That's not the case as Nginx in the container isn't started until after the certificate process has occured Then perhaps the script mistakenly assumes the certificate process completed successfully? I am definitely getting a response from Nginx via curl, if you look at my original post. That server is up. I get responses from 1443, even hitting this port from the local machine. Quote Link to comment
CHBMB Posted June 1, 2018 Share Posted June 1, 2018 (edited) 7 minutes ago, Anthop said: Then perhaps the script mistakenly assumes the certificate process completed successfully? I am definitely getting a response from Nginx via curl, if you look at my original post. That server is up. I get responses from 1443, even hitting this port from the local machine. But you're not getting certificates, it's failing the validation stage, it's trying to hit your domain name and instead getting redirected to the unraid webui. I'll let @aptalca comment further on this as he's the expert, but I'm pretty sure (almost certain) the issue is with your local setup rather than the container and my money is on your port forwarding. Did come across someone recently with similar issues who needed to restart his router before it worked. Everything I see in those logs looks like 443 externally is getting forwarded to 443 on your Unraid server. EDIT: Also bear in mind Unraid's webui is running on Nginx as well. Edited June 1, 2018 by CHBMB Quote Link to comment
Recommended Posts
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.