Jump to content
Fma965

The Complete UnRAID reverse proxy, Duck DNS (dynamic dns) and letsencrypt guide

127 posts in this topic Last Reply

Recommended Posts

I'm not qualified to verify the info, but it sure looks good!  Very nice work!  Hope to see more!

 

I've added it to the Docker section of Guides and Videos.

  • Upvote 1

Share this post


Link to post

Looking good. 

 

Sent from my LG-H815 using Tapatalk

 

 

  • Upvote 1

Share this post


Link to post

Thanks! Hadn't quite managed to get Nextcloud working couple weeks ago when tried, ran through your instructions and was up and running very quickly :)

 

 

  • Upvote 1

Share this post


Link to post

I cant wait to try this when I get home!!!!!  I have been struggling with this for months - sometimes I would make a small step forward, but have only gotten couch potato and sonarr working.  Way excited!!  Thanks!!!!!!

  • Upvote 1

Share this post


Link to post

I understand having secure remote access is the reason to do this but, silly question, what are the downsides to doing so?

Share this post


Link to post

Hi all hope you are finding the guide useful, any questions let me know.

 

Regarding downsides... i don't know really i mean obviously your home ip can be found by nslookup the domain, services are accessible to public (whether you protected them with a password is up to you)

Share this post


Link to post
docker exec -it letsencrypt htpasswd -c /config/nginx/.htpasswd <username>

add: auth_basic_user_file /config/nginx/.htpasswd; to the default file under each service I wanted to protect.

after doing the above, you also need to add

auth_basic "Administrator Login";

auth_basic_user_file /config/nginx/.htpasswd;

in the server config per http://www.tecmint.com/password-protect-web-directories-in-nginx/

  • Upvote 1

Share this post


Link to post
On 2/21/2017 at 4:54 PM, ice pube said:

Do I need to change anything within my dockers? Also can you add the HTpasswd step? 

Not on the actual docker configuration.

 

On 2/21/2017 at 8:15 PM, ChaOConnor said:

docker exec -it letsencrypt htpasswd -c /config/nginx/.htpasswd <username>

add: auth_basic_user_file /config/nginx/.htpasswd; to the default file under each service I wanted to protect.

after doing the above, you also need to add

auth_basic "Administrator Login";

auth_basic_user_file /config/nginx/.htpasswd;

in the server config per http://www.tecmint.com/password-protect-web-directories-in-nginx/

Yea thats what i did.

Share this post


Link to post

I've just added a whole new section to the tutorial with some proxy_pass directives.

Share this post


Link to post

Want any other guides? let me know via reply or pm or email admin[at]cyanlabs.net

Edited by Fma965

Share this post


Link to post

great job, used his guide and was able to get my reverse proxy to work

Share this post


Link to post

Hello Fma965,

thank you for the guide.

I followed it exactly, but still have one issue, I cannot resolve.

 

Following your guide I should be able access my nextcloud server from "https://mysubdomain.duckdns.org/nextcloud"

However I have add another slash at the end "https://mysubdomain.duckdns.org/nextcloud/" to login into my nextcloud server.

 

In the chapter "Fixing Nextcloud" you write:

Quote

3. Replace the following lines

# Path to the root of your installation
root /config/www/nextcloud/;

With this
# Path to the root of your installation
root /config/www;

 

It seems like nextcloud nginx webserver expects /nextcloud/ as web root.

Did I missed something?

Share this post


Link to post

Solved the issue with the help of this guide https://www.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/

As I found out it is possible to use sub-subdomains like "https://cloud.mysubdomain.duckdns.org".

 

No need to change the web configs of the applications any more.

As a bonus I get now A+ instead of A from https://scan.nextcloud.com/

Edited by Forusim

Share this post


Link to post
On 2/21/2017 at 3:15 PM, ChaOConnor said:

docker exec -it letsencrypt htpasswd -c /config/nginx/.htpasswd <username>

add: auth_basic_user_file /config/nginx/.htpasswd; to the default file under each service I wanted to protect.

after doing the above, you also need to add

auth_basic "Administrator Login";

auth_basic_user_file /config/nginx/.htpasswd;

in the server config per http://www.tecmint.com/password-protect-web-directories-in-nginx/

 

Sorry if this is a dumb question, does anyone know why I'm getting a 403 Forbidden after adding .htpasswd access (using these instructions) while I wasn't before? I get the login box and my username/pw is recognized but then I get a 403 Forbidden page. 

 

 

Share this post


Link to post

I completely understand the concept and appeal to be able to securely access your services remotely, but how would this impact local use? I assume you wouldn't be going to your domain (I feel like my router wouldn't allow that) but still access your various services via the traditional methods when on your internal network. If some of the apps (like sonarr, for instance) require changing the URL base, would that just mean I'd have to change the way I locally access sonarr on my network (e.g., internalip:8989/sonarr)?

Share this post


Link to post
On 06/06/2017 at 7:04 PM, Forusim said:

Solved the issue with the help of this guide https://www.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/

As I found out it is possible to use sub-subdomains like "https://cloud.mysubdomain.duckdns.org".

 

No need to change the web configs of the applications any more.

As a bonus I get now A+ instead of A from https://scan.nextcloud.com/

Great, thats just a different way of doing it.

 

On 01/07/2017 at 8:26 PM, zandrsn said:

 

Sorry if this is a dumb question, does anyone know why I'm getting a 403 Forbidden after adding .htpasswd access (using these instructions) while I wasn't before? I get the login box and my username/pw is recognized but then I get a 403 Forbidden page. 

 

 

Logs will be needed.

 

4 hours ago, kaiguy said:

I completely understand the concept and appeal to be able to securely access your services remotely, but how would this impact local use? I assume you wouldn't be going to your domain (I feel like my router wouldn't allow that) but still access your various services via the traditional methods when on your internal network. If some of the apps (like sonarr, for instance) require changing the URL base, would that just mean I'd have to change the way I locally access sonarr on my network (e.g., internalip:8989/sonarr)?

Most routers allow access the same as remotely (can't think what it's called, something to do with loopback) therefore you can just access it at xxx.duckdns.org/sonarr etc.

Share this post


Link to post
I completely understand the concept and appeal to be able to securely access your services remotely, but how would this impact local use? I assume you wouldn't be going to your domain (I feel like my router wouldn't allow that) but still access your various services via the traditional methods when on your internal network. If some of the apps (like sonarr, for instance) require changing the URL base, would that just mean I'd have to change the way I locally access sonarr on my network (e.g., internalip:8989/sonarr)?

I set in my asus/merlin router in the dnsmasq.conf.add on the jffs partition (/jffs/configs/dnsmasq.conf.add). Or you can add it to your router's dnsmasq.conf with your domain name and the local ip formatted like this

# add local addressaddress=/yourserver.example.com/xxx.xxx.xxx.xxx

 

 

Share this post


Link to post

Thanks, all, for clarifying. dmacias, I was curious if I'd have to manually add a dnsmasq entry in merlin, so I appreciate you specifically mentioning that.

 

Last question hopefully--I installed the letsencrypt container, exposed appropriate ports, got the certs for my domain and subdomain... https://internal.ip.of.unraid works fine (albeit the cert doesn't like the url), but I can't get into http://internal.ip.of.unraid:81 ... Does the http not matter since the whole point is we're using https now? Just want to make sure this is by design before I continue on... 

 

Edit: Nevermind. I went ahead and set it up even though I can't access port 80 (actually 81) internally. As long as I reference https locally, I can access all the server apps. Forcing 80 to 443 redirect externally. Thanks again for the writeup!

Edited by kaiguy

Share this post


Link to post

I'm trying to figure out how to reverse proxy my rutorrent docker. This is how my template looks  (See below) and I access the GUI through port 82. I'm not sure how to add a base url so how I access it locally is through http:[server IP]:82  When I go through my duckdns/rutorrent it isn't displaying the rutorrent gui properly.

 

    location /rutorrent {
        include /config/nginx/proxy.conf;
    proxy_bind $server_addr;
        proxy_pass http://[IP]:82/;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Real-IP $remote_addr;   
    auth_basic "Restricted";
    auth_basic_user_file /config/nginx/.htpasswd;
    }

 

RmEjmRG.png

Edited by bobokun

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now