[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

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 

Link to comment
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

Link to comment
4 hours ago, aptalca 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;
    }
    
}

 

Edited by Aurao
Link to comment
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"

Link to comment
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

Link to comment
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 by aptalca
Link to comment
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 by Aurao
Link to comment

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?

Link to comment
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
Link to comment

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 ?

Link to comment

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.

 

Link to comment
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. 

Link to comment
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...

 

Link to comment
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

Link to comment

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!

Link to comment
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.

Link to comment
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 by CHBMB
  • Like 1
Link to comment
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

Link to comment
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!

Link to comment
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 by Anthop
Link to comment
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

Link to comment
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.

Link to comment
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 by CHBMB
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.