[Request/Done] Let's Encrypt Container


rix

Recommended Posts

Hey aptalca. Sorry to bother you again  :o : I've noticed that fail2ban is not starting for me.

 

* Starting authentication failure monitor fail2ban
* Socket file /var/run/fail2ban/fail2ban.sock is present
...fail!
*** Running 

 

After manually executing in ssh:

docker exec -it Nginx-Letsencrypt rm -rf /var/run/fail2ban/fail2ban.sock

 

It works again. Would you add a line that removes the file in question before starting fail2ban?  ::):D

* Starting authentication failure monitor fail2ban
...done.

Link to comment

Hey aptalca. Sorry to bother you again  :o : I've noticed that fail2ban is not starting for me.

 

* Starting authentication failure monitor fail2ban
* Socket file /var/run/fail2ban/fail2ban.sock is present
...fail!
*** Running 

 

After manually executing in ssh:

docker exec -it Nginx-Letsencrypt rm -rf /var/run/fail2ban/fail2ban.sock

 

It works again. Would you add a line that removes the file in question before starting fail2ban?  ::):D

* Starting authentication failure monitor fail2ban
...done.

There already is a line for that. Are you using the latest version? Did you modify it?

Link to comment

I have the same issue

 

After this command it's OK to start

docker exec -it Nginx-letsencrypt rm -rf /var/run/fail2ban/fail2ban.sock

 

And Stop - Start...  it's fail

* Starting authentication failure monitor fail2ban
* Socket file /var/run/fail2ban/fail2ban.sock is present
...fail!

Link to comment

I have the same issue

 

After this command it's OK to start

docker exec -it Nginx-letsencrypt rm -rf /var/run/fail2ban/fail2ban.sock

 

And Stop - Start...  it's fail

* Starting authentication failure monitor fail2ban
* Socket file /var/run/fail2ban/fail2ban.sock is present
...fail!

 

Does that happen every time you restart the container? Because that would suggest a deeper issue. During a successful stop of the container, fail2ban should stop safely and remove the socket. I only had the socket present issue when docker crashed on my server and had to be killed, so fail2ban was not stopped gracefully.

 

As far as failing to delete the socket, I was able to reproduce the bug and it will be fixed in the next update.

 

EDIT: New update pushed

Link to comment

Thanks again for this awesome container!

 

Like you mentioned, dhparams is easy, just replace the local file yourself and you're good to go.

 

I added an environment variable for DHLEVEL=4096, but /config/nginx/dhparams.pem was not updated.  Is it just a matter of deleting that file?  Will that invalidate anything else?

 

Unfortunately, letsencrypt does not handle adding or removing urls graciously (yet). So this container does not support it (in fact, if you modify the variables later on and let it renew through cron, it might break the whole thing).

 

What you can do is, delete the etc/letsencrypt folder in your config location (it contains the keys) and then restart the container with the new url settings. The old certs will simply be discarded. You will still get e-mail notifications about them expiring (You can optionally revoke them in command line before deleting them but it's complicated).

 

I'd like to try officially revoking my cert so I can add subdomains, does this command look right?

 

/defaults/letsencrypts.sh revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem

 

There are other .pem files in that dir, so I need to revoke all of them?

Link to comment

 

 

Thanks again for this awesome container!

 

Like you mentioned, dhparams is easy, just replace the local file yourself and you're good to go.

 

I added an environment variable for DHLEVEL=4096, but /config/nginx/dhparams.pem was not updated.  Is it just a matter of deleting that file?  Will that invalidate anything else?

 

Just delete the dhparams.pem file, set the environment variable and restart the container

 

Unfortunately, letsencrypt does not handle adding or removing urls graciously (yet). So this container does not support it (in fact, if you modify the variables later on and let it renew through cron, it might break the whole thing).

 

What you can do is, delete the etc/letsencrypt folder in your config location (it contains the keys) and then restart the container with the new url settings. The old certs will simply be discarded. You will still get e-mail notifications about them expiring (You can optionally revoke them in command line before deleting them but it's complicated).

 

I'd like to try officially revoking my cert so I can add subdomains, does this command look right?

 

/defaults/letsencrypts.sh revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem

 

There are other .pem files in that dir, so I need to revoke all of them?

 

You would use the actual letsencrypt-auto.sh script, not the renewal script that I wrote. Other than that it looks right. You just need to revoke the cert.pem

Link to comment

Thanks again for this awesome container!

 

Like you mentioned, dhparams is easy, just replace the local file yourself and you're good to go.

 

I added an environment variable for DHLEVEL=4096, but /config/nginx/dhparams.pem was not updated.  Is it just a matter of deleting that file?  Will that invalidate anything else?

 

Just delete the dhparams.pem file, set the environment variable and restart the container

 

That worked perfectly :)

 

Unfortunately, letsencrypt does not handle adding or removing urls graciously (yet). So this container does not support it (in fact, if you modify the variables later on and let it renew through cron, it might break the whole thing).

 

What you can do is, delete the etc/letsencrypt folder in your config location (it contains the keys) and then restart the container with the new url settings. The old certs will simply be discarded. You will still get e-mail notifications about them expiring (You can optionally revoke them in command line before deleting them but it's complicated).

 

I'd like to try officially revoking my cert so I can add subdomains, does this command look right?

 

/defaults/letsencrypts.sh revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem

 

There are other .pem files in that dir, so I need to revoke all of them?

 

You would use the actual letsencrypt-auto.sh script, not the renewal script that I wrote. Other than that it looks right. You just need to revoke the cert.pem

 

I think I revoked it:

root@961bb43e07bd:/defaults# ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
root@961bb43e07bd:/defaults#

 

But after restarting the container, the log shows:

deciding whether to renew the cert(s)
Existing certificate is still valid for another 68 day(s); skipping renewal.

 

And the old cert still works.  Can you tell what I'm missing?

 

Link to comment

Thanks again for this awesome container!

 

Like you mentioned, dhparams is easy, just replace the local file yourself and you're good to go.

 

I added an environment variable for DHLEVEL=4096, but /config/nginx/dhparams.pem was not updated.  Is it just a matter of deleting that file?  Will that invalidate anything else?

 

Just delete the dhparams.pem file, set the environment variable and restart the container

 

That worked perfectly :)

 

Unfortunately, letsencrypt does not handle adding or removing urls graciously (yet). So this container does not support it (in fact, if you modify the variables later on and let it renew through cron, it might break the whole thing).

 

What you can do is, delete the etc/letsencrypt folder in your config location (it contains the keys) and then restart the container with the new url settings. The old certs will simply be discarded. You will still get e-mail notifications about them expiring (You can optionally revoke them in command line before deleting them but it's complicated).

 

I'd like to try officially revoking my cert so I can add subdomains, does this command look right?

 

/defaults/letsencrypts.sh revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem

 

There are other .pem files in that dir, so I need to revoke all of them?

 

You would use the actual letsencrypt-auto.sh script, not the renewal script that I wrote. Other than that it looks right. You just need to revoke the cert.pem

 

I think I revoked it:

root@961bb43e07bd:/defaults# ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
root@961bb43e07bd:/defaults#

 

But after restarting the container, the log shows:

deciding whether to renew the cert(s)
Existing certificate is still valid for another 68 day(s); skipping renewal.

 

And the old cert still works.  Can you tell what I'm missing?

You have to delete the certs after revoking them. Revoking does nothing to the local cert file. It only tells the remote server not to validate it anymore. If the revoke is successful, when you refresh the browser (may have to clear the cache),  it says there is an error with the certificate.

 

My script only checks for the expiration date coded in the local cert, which does not change after revoking. So, delete the domain.url folder as well as the keys folder under config and restart

Link to comment

Unfortunately, letsencrypt does not handle adding or removing urls graciously (yet). So this container does not support it (in fact, if you modify the variables later on and let it renew through cron, it might break the whole thing).

 

What you can do is, delete the etc/letsencrypt folder in your config location (it contains the keys) and then restart the container with the new url settings. The old certs will simply be discarded. You will still get e-mail notifications about them expiring (You can optionally revoke them in command line before deleting them but it's complicated).

 

I'd like to try officially revoking my cert so I can add subdomains, does this command look right?

 

/defaults/letsencrypts.sh revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem

 

There are other .pem files in that dir, so I need to revoke all of them?

 

You would use the actual letsencrypt-auto.sh script, not the renewal script that I wrote. Other than that it looks right. You just need to revoke the cert.pem

 

I think I revoked it:

root@961bb43e07bd:/defaults# ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
root@961bb43e07bd:/defaults#

 

But after restarting the container, the log shows:

deciding whether to renew the cert(s)
Existing certificate is still valid for another 68 day(s); skipping renewal.

 

And the old cert still works.  Can you tell what I'm missing?

You have to delete the certs after revoking them. Revoking does nothing to the local cert file. It only tells the remote server not to validate it anymore. If the revoke is successful, when you refresh the browser (may have to clear the cache),  it says there is an error with the certificate.

 

My script only checks for the expiration date coded in the local cert, which does not change after revoking. So, delete the domain.url folder as well as the keys folder under config and restart

 

It looks like browsers may not realize the cert was revoked:

  https://community.letsencrypt.org/t/revoked-certs-not-showing-as-revoked-in-browsers/11531

 

So I renamed /config/etc to /config/etc.revoked and restarted the container.  Works perfectly.  Thanks!

Link to comment

Thank you very much for the last (giant & awesome) update.

 

I am deeply satisfied looking at this:

 

Hi rix,

 

Would you mind describing what changes you made to the nginx config in order to get that A+ rating from ssllabs.com?

 

So far I have disabled TLS1 by modifying this line in nginx.conf:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

to:

ssl_protocols TLSv1.1 TLSv1.2;

 

With that change I get top marks at https://discovery.cryptosense.com , but ssllabs isn't quite at 100%.  I am running the current version of aptalca's docker, with DHLEVEL set to 4096.

 

Update: I followed the tips here:

  https://mozilla.github.io/server-side-tls/ssl-config-generator/

to remove TLS 1.1:

ssl_protocols TLSv1.2;

and redue the ciphers to:

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

 

I'm up to 100/100/90/90, at the expense of compatibility with older browsers I don't care about.  Still looking for 100/100/100/100

Link to comment

Unfortunately, letsencrypt does not handle adding or removing urls graciously (yet). So this container does not support it (in fact, if you modify the variables later on and let it renew through cron, it might break the whole thing).

 

What you can do is, delete the etc/letsencrypt folder in your config location (it contains the keys) and then restart the container with the new url settings. The old certs will simply be discarded. You will still get e-mail notifications about them expiring (You can optionally revoke them in command line before deleting them but it's complicated).

 

I'd like to try officially revoking my cert so I can add subdomains, does this command look right?

 

/defaults/letsencrypts.sh revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem

 

There are other .pem files in that dir, so I need to revoke all of them?

 

You would use the actual letsencrypt-auto.sh script, not the renewal script that I wrote. Other than that it looks right. You just need to revoke the cert.pem

 

I think I revoked it:

root@961bb43e07bd:/defaults# ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/[domain name]/cert.pem
root@961bb43e07bd:/defaults#

 

But after restarting the container, the log shows:

deciding whether to renew the cert(s)
Existing certificate is still valid for another 68 day(s); skipping renewal.

 

And the old cert still works.  Can you tell what I'm missing?

 

It looks like browsers may not realize the cert was revoked:

  https://community.letsencrypt.org/t/revoked-certs-not-showing-as-revoked-in-browsers/11531

 

 

You may have to clear the browser cache. I believe they cache the certificates for a short period of time (do shift F5 or ctrl F5 while on the site and it should pick up the new certs)

Link to comment

This thing is awesome now that I got it working. Turns out you just have to forward the ports on the router correctly.... I feel dumb as I haven't made that mistake in forever.

 

Anyway, Madsonic.... Anyone get this to work? Should I turn off SSL in the docker? Maybe I'll try that next

 

Link to comment

Does anyone reverse proxy the unraid GUI? Could you even do that?

 

I got this setup and going (sickrage was more annoying to get right than this entire docker!).

 

Just wondering which apps I should bother to reverse proxy instead of using my VPN and accessing the unraid GUI/dockers that way.

Link to comment

Does anyone reverse proxy the unraid GUI? Could you even do that?

 

I got this setup and going (sickrage was more annoying to get right than this entire docker!).

 

Just wondering which apps I should bother to reverse proxy instead of using my VPN and accessing the unraid GUI/dockers that way.

Anything that let's you set a url prefix is very easy to do with simple path proxy.

 

Unraid gui does not let you do that so you may have to look into setting up a separate subdomain which is a little more complicated.

 

I'm using sabnzbd, couchpotato, sonarr, plexwatch, plexpy, plexrequests and some of the dockergui based containers like calibre with the basic url prefix method.

Link to comment
On 4/21/2016 at 7:57 AM, 00b5 said:

Does anyone reverse proxy the unraid GUI? Could you even do that?

 

There are a couple of interesting bits to get it working:

1. It needs its own url, such as unraid.yourdomain.url (the unraid interface does not run in a directory, such as yourdomain.url/unraid )

 

2. You don't want to expose unraid's authentication to the internet, let nginx handle the authentication instead (that way fail2ban can lock out failed authentication attempts).  That is a little tricky, because that means nginx has to know how to login to unraid.  This article explains the concept:

  http://shairosenfeld.blogspot.com/2011/03/authorization-header-in-nginx-for.html

 

 

Building on aptalca's setup:

  https://lime-technology.com/forum/index.php?topic=43696.msg437353#msg437353

 

I moved the SSL certificate info into /config/nginx/proxy.conf so it could be used in multiple server blocks.  And I moved the auth_basic commands into /config/nginx/auth.conf for the same reason.

 

With that out of the way, this will proxy the unraid interface:

server {
  listen 443 ssl;
  server_name unraid.yourdomain.url;
  include /config/nginx/ssl.conf;

  location / {
    include /config/nginx/auth.conf;
    include /config/nginx/proxy.conf;
    proxy_pass http://[unraid ip here]/;
    
    # unraid logs do not work if buffering is enabled
    proxy_buffering off;
    
    # see http://shairosenfeld.blogspot.com/2011/03/authorization-header-in-nginx-for.html
    proxy_set_header Authorization "Basic a2luZzppc25ha2Vk"; #just a sample

    # If you are proxying unRAID 6.4+, uncomment the following lines to support WebSockets
    # proxy_set_header Upgrade $http_upgrade;
    # proxy_set_header Connection "upgrade";
  }
}

 

 

Edited by ljm42
add support for WebSockets in unRAID 6.4+
Link to comment

Does anyone reverse proxy the unraid GUI? Could you even do that?

 

I got this setup and going (sickrage was more annoying to get right than this entire docker!).

 

Just wondering which apps I should bother to reverse proxy instead of using my VPN and accessing the unraid GUI/dockers that way.

 

There are a couple of interesting bits to get it working:

1. It needs its own url, such as unraid.yourdomain.url (the unraid interface does not run in a directory, such as yourdomain.url/unraid )

 

2. You don't want to expose unraid's authentication to the internet, let nginx handle the authentication instead (that way fail2ban can lock out failed authentication attempts).  That is a little tricky, because that means nginx has to know how to login to unraid.  This article explains the concept:

  http://shairosenfeld.blogspot.com/2011/03/authorization-header-in-nginx-for.html

 

I believe some parts of the unraid gui also use websockets (tailing LOGs, VNC console). Websockets through nginx is possible, but another tricky thing to do. https://www.nginx.com/blog/websocket-nginx/

I could be wrong though, at least those two things wont work for me with a standard reverse proxy.

 

And to your question of what application you may want to put behind the proxy instead of using vpn. In my case, I count how many diffrent users/devices are accessing the app. Its more easy to  provide https access, than installing 10+ vpn clients with diffrent users.

But since I am the only one accessing unraid and do so only from 1-2 devices, putting the unraid gui behind the proxy (with all its features) seems overkill.

 

But keep in mind, you could use the LE certs for a web VPN. Not for the auth. but it should work for the encryption. (as seen HERE)

Haven't found a vpn solution that can import the cert in intervals though.

Link to comment

Would you mind describing what changes you made to the nginx config in order to get that A+ rating from ssllabs.com?

 

Update: I followed the tips here:

  https://mozilla.github.io/server-side-tls/ssl-config-generator/

to remove TLS 1.1:

ssl_protocols TLSv1.2;

and redue the ciphers to:

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

 

I'm up to 100/100/90/90, at the expense of compatibility with older browsers I don't care about.  Still looking for 100/100/100/100

First of all, aptalca example is already very good, to want more is more like a sport...

 

There are a few things at some points in the config and 100/100/100/100 needs certificate pinning, which is overkill to be honest.

I see it more from an educational view, so its fun and you learn alot.

 

a) The folowing line blacklists all "bad" cyphers. It looks cleaner, but unless you know whats left, you have no idea what cypher you are using :) (I don't, but if its all 100% its safe I guess ^^)

ssl_ciphers HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128; 

b) You also need 384bit+ ECDH

ssl_ecdh_curve secp384r1;

c) Certificate and Public Key Pinning

TL;DR: you put the signed fingerprint of at least TWO certs into you site, so even if a cert. contains the right domains AND is generally trustworthy, the browser won't accept it if the hash is not found in the header. As of now, I think only chrome actually checks it.

proxy_set_header Public-Key-Pins 'pin-sha256="79xH6q4gKV/LQ1LPmI67/hkuNxMB+J6YbCQJWrdavOw="; pin-sha256="Ox0UeNDINSfUUFCkKw0vvnYprdL/Ep7bzb8wDl36ByA="; max-age=15768000; includeSubdomains';

So I have 2 Certificates for my domain, one is LIVE, the other is offline.

 

Chrome has a store per domain for these hashes and it only gets refreshed once the site correctly loads, so you can't just renew the cert, because a client that was on your site before that renewal won't accept the new cert, because the hash was not available last time... before removing the old cert, ALL your clients need to visit your site to get the new one. That may be a Problem with the 90day certs...

You could use the hash from the LE cert wich lives longer, but that would mean, every cert that comes from LE and has your domain is valid, which counters the idea of pinning...

 

This container cant and probably won't for a long time (if ever) be able to keep 2 (or more) seperate certs, for the same domain, live and offline and rotate their hashes into your proxy.conf every ~45 days (or less)...

While it defenitly COULD be done not even I dare to propose such a feature to aptalca  8) (no sane person would like to support such a mechanism and only chrome actually cares, so it does not add much)

Link to comment

This thing is awesome now that I got it working. Turns out you just have to forward the ports on the router correctly.... I feel dumb as I haven't made that mistake in forever.

 

Anyway, Madsonic.... Anyone get this to work? Should I turn off SSL in the docker? Maybe I'll try that next

 

Well, less beer in the system helped. Actually I just installed clean with binhex's madsonic and saw that I could get it to work. Then switched everything back over. Piece of cake and this letsencrypt docker works great!

Link to comment

First of all, aptalca example is already very good, to want more is more like a sport...

 

There are a few things at some points in the config and 100/100/100/100 needs certificate pinning, which is overkill to be honest.

I see it more from an educational view, so its fun and you learn alot.

 

I agree, I think aptalca's defaults provide very good security as well as backwards compatibility.  But since this is a home server where I control all the clients, I don't have to worry about pesky things like backwards compatibility :)

 

I agree with your comments about certificate pinning, it doesn't seem compatible with LE.

 

Thanks for your tips!  With your help, I have now achieved full A+ 100/100/100/100 at ssllabs.  Woot!

 

For anyone following along, use this as a starting point:

  https://lime-technology.com/forum/index.php?topic=43696.msg437353#msg437353

 

And then change these lines:

ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128;

And add this one:

ssl_ecdh_curve secp384r1;

 

You'll also want to delete your /config/nginx/dhparams.pem file and set the DHLEVEL Docker environment variable to 4096, then restart the docker.

 

Note: if you have these settings and are only getting an A and not an A+, it is probably because your site is password protected.  To get "credit" for HSTS, your site has to return valid data and not a password prompt.

Link to comment

I believe some parts of the unraid gui also use websockets (tailing LOGs, VNC console). Websockets through nginx is possible, but another tricky thing to do. https://www.nginx.com/blog/websocket-nginx/

I could be wrong though, at least those two things wont work for me with a standard reverse proxy.

 

Good point, I hadn't tried yet. I can confirm they do not work with the setup I mentioned above.  Despite the documentation, adding this didn't help:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Has anyone else been able to get this working?

 

Link to comment

I believe some parts of the unraid gui also use websockets (tailing LOGs, VNC console). Websockets through nginx is possible, but another tricky thing to do. https://www.nginx.com/blog/websocket-nginx/

I could be wrong though, at least those two things wont work for me with a standard reverse proxy.

 

Good point, I hadn't tried yet. I can confirm they do not work with the setup I mentioned above.  Despite the documentation, adding this didn't help:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Has anyone else been able to get this working?

From what I understand, you need to specify the correct port of your application, in the proxy_pass.

But it may not even be websockets, it just makes sense from what see and read.

 

For example, VNC runs on ports from 5900 ongoing. (random each time you start the vm, unless you set it in the vm config)

I do not know how the "log" part works, but I think you could look through the source code of the unraid gui...

The little "pop-ups" when you pull a docker, upgrade a plugin and so on are also not working, because they are just a -tail of the console.

 

A decent way to start would be HERE.

 

*EDIT: Btw, this topic is almost 2 years old, and it seems aptalca event got his opinion on it ;) (use vpn...) But that was before LetsEncrypt.

Link to comment

I believe some parts of the unraid gui also use websockets (tailing LOGs, VNC console).

 

I found the solution for unraid's logs, you need to disable proxy buffering:

proxy_buffering off;

I updated my post:

https://lime-technology.com/forum/index.php?topic=43696.msg465800#msg465800

 

For VNC, proxying the Guacamole docker might be the way to go:

  http://guac-dev.org/doc/gug/proxying-guacamole.html#proxying-with-nginx

 

But since I am the only one accessing unraid and do so only from 1-2 devices, putting the unraid gui behind the proxy (with all its features) seems overkill.

 

I agree VPN is best.  I haven't decided if I'm going to keep this on long term, but it is pretty impressive.

Link to comment

Just added this docker with default settings (and advanced settings). The docker will not start. Also, there are no logs that have been recorder. I attempt to start and it stops immediately. Any suggestions?

Can you post a screenshot with your settings?

 

Does it let you hit create and actuator create the container?

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.