I got a quite simple question; if I want to enable http auth, where do I put the users/credentials?

Hey guys I've been trying to get this to work, but was not sucssefull.

I have the following log:

 

And the following config: 

 

Hope you guys can help

6 hours ago, Jaster said:

I got a quite simple question; if I want to enable http auth, where do I put the users/credentials?

The readme covers that

5 hours ago, carlosmorgado said:

Hey guys I've been trying to get this to work, but was not sucssefull.

I have the following log:

 

And the following config: 

 

Hope you guys can help

You have networking or dns issues. The container cannot reach out to letsencrypt servers. Check your dns, turn off pihole or whatever else blocker you may be using.

3 minutes ago, aptalca said:

You have networking or dns issues. The container cannot reach out to letsencrypt servers. Check your dns, turn off pihole or whatever else blocker you may be using.

I don't have any blocker running, and from what I see in my router everything is ok

On 4/17/2020 at 6:14 AM, aptalca said:

Edit the default site conf and comment out the block with listen 80 

 

Also, if you use dns validation, you don't have to forward port 80

Do you mean these lines?

 

# redirect all traffic to https
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;

On 2/29/2020 at 11:51 PM, trurl said:

If you have your own domain, why get duckdns involved at all?

 

The video tutorial shows you how to do it with duckdns, OR how to do it with your own domain. Not both at the same time.

I got duckdns involved as a way to have my dynamic IP automatically update via the duckdns, so the domain would remain updated.

 

This may not be the best way to do this, in which case I'd be keen to know a better way?

On 3/1/2020 at 5:35 PM, aptalca said:

You said you followed the linuxserver troubleshooting guide. So what happened? Did you do the test?

I did follow... but I also tested poorly. I setup port forwarding and was testing it internally and the domain was resolving to the docker default page. I took this to mean it was working, however I got a mate to test externally and he wasn't getting in. It was bizarre because I had plex port forwarding setup and working on the router, so was comfortable with the steps I took.

 

Anyway. I was using the basic ISP-supplied router for this, but I setup a different router (was already planning to do so) and when I re-setup the port forwards, it worked (for both plex and the letsencrypt dockers...).

 

Cheers for replying.

9 hours ago, casperse said:

Do you mean these lines?

 

# redirect all traffic to https
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;

Yup, and the line after that, which closes the the bracket

23 hours ago, aptalca said:

You have networking or dns issues. The container cannot reach out to letsencrypt servers. Check your dns, turn off pihole or whatever else blocker you may be using.

do you have anyother guess?

Edited April 20, 20206 yr by carlosmorgado

4 hours ago, carlosmorgado said:

do you have anyother guess?

Did you confirm it's not dns or networking issues?

9 hours ago, aptalca said:

Did you confirm it's not dns or networking issues?

Yes, I just configured those ports on other services on unraid (for test purposes) and was able to access them from outside the network, using the domain I configured.

Edited April 21, 20206 yr by carlosmorgado

3 hours ago, carlosmorgado said:

Yes, I just configured those ports on other services on unraid (for test purposes) and was able to access them from outside the network, using the domain I configured.

Your issues are with "outgoing" connections, not incoming. That's why I suggested dns

Not a support need, per se, but curious if anyone has tried bypassing http auth on local network(s). I tried modifying the proxy-confs to accomplish this, but I haven't been able to get this to work. Not sure if I'm doing something wrong, or if it just doesn't work with reverse proxy for some reason.

    location / {
	satisfy any;

	# bypass http auth for local IPs
	allow 192.168.0.0/24;
	allow 172.18.0.0/16;
	deny all;

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

...

 

Hi,

 

I'm trying to use the linuxserver nextcloud container with this reverse proxy. Threre is not much needed in terms of configuration, which I have done.

All I get is a 502 from nextcloud

What are the common mistakes and how can I find out what isn't working?

 

I have some other containers just working fine using the reverse proxy, but nextcloud doesn't.

4 hours ago, aptalca said:

Your issues are with "outgoing" connections, not incoming. That's why I suggested dns

So I entered the console of the container and tested the following (this url was the one mentioned in the logs):

 

root@168ecbf2d373:/# curl acme-v02.api.letsencrypt.org 443
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
curl: (7) Couldn't connect to server

 

10 hours ago, Jaster said:

Hi,

 

I'm trying to use the linuxserver nextcloud container with this reverse proxy. Threre is not much needed in terms of configuration, which I have done.

All I get is a 502 from nextcloud

What are the common mistakes and how can I find out what isn't working?

 

I have some other containers just working fine using the reverse proxy, but nextcloud doesn't.

502 means letsencrypt can't reach the service at the specified address and port

11 hours ago, kaiguy said:

Not a support need, per se, but curious if anyone has tried bypassing http auth on local network(s). I tried modifying the proxy-confs to accomplish this, but I haven't been able to get this to work. Not sure if I'm doing something wrong, or if it just doesn't work with reverse proxy for some reason.

    location / {
	satisfy any;

	# bypass http auth for local IPs
	allow 192.168.0.0/24;
	allow 172.18.0.0/16;
	deny all;

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

...

 

That doesn't seem like the correct config for that. In that configuration, http auth is not dependent on the source ip, only general access is. Http auth is requested for every successful connection

10 hours ago, carlosmorgado said:

So I entered the console of the container and tested the following (this url was the one mentioned in the logs):

 

root@168ecbf2d373:/# curl acme-v02.api.letsencrypt.org 443
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
curl: (7) Couldn't connect to server

 

You need to tell curl to follow redirects

7 hours ago, aptalca said:

You need to tell curl to follow redirects

So what I found out is that the network I created with the

docker network create

command doesn't have access to the outside. Now I am not sure how to solve this

Hi Guys,

 

It's been a while, hope you're all well.

 

I currently have this lets encrypt docker container working well with dns validation (cloudflare - non proxy) and am serving a very simple landing page as well as a couple of apps via sub domains.

 

There is one niggling issue that I can't seem to solve that I am hoping someone can help me debug. I cannot get the site to redirect to https. Here is some relevant info from my setup:

 

Ports forwarded on my router to unraid:

router => unraid

80 => 180

443 => 1444

 

The code snippet below from the 'default' file in site-confs is unchanged from the installation and every link I have been to regarding nginx suggests this is the right code to redirect.

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

Now, it appears that the redirect works perfectly from the LAN BUT when I am out and about it does not. I have made sure that the browsers are not caching etc. In fact, I have just demo'd it right now. Phone on the Wifi, go to http://subdomain.domain.com redirects great. Drop the Wifi and repeat, no connection is made and no redirect.

 

I have checked with my ISP and they do not block port 80 and all my port forwards are in there and fine.

 

I am not sure how to go about debugging this. Can anyone help please?

 

EDIT: Issue resolved as per post below - a couple down - ISP actually DO block port 80, despite telling me something different. That was the issue.

Edited April 25, 20206 yr by danioj

I have letsencrypt working flawlessly with several subdomains. However, i want my top domain to reverse proxy into the Heimdall container. If i access my domain now, i get the following:

Welcome to our server

The website is currently being setup under this address.

For help and support, please contact: [email protected].

 

How can i redirect https://example.com to Heimdall?

Something strange happened last and now I find that all of a sudden none of my subdomain reverse proxies are working. I use this container to host three base domain website, all which are still working, a few subfolder reverse proxies, which are all working, and many subdomains off of two of the base domains, none of which are working any more. I didn't change anything with my setup between yesterday and today and my letsencrypt logs don't show anything suspicious. Any idea how I should go about diagnosing what's going on, or what might be causing this problem? 
 

I run pfSense on a standalone box as a firewall and router, so I checked the logs there but also didn't see anything suspicious...

**EDIT**
I figured out what the problem was. My ISP updated my WAN IP address last night and my dynamic DNS updater had only updated the @ hosts of my domains, not the other subdomains. I'll leave this here in case anyone else runs into the same problem. 

Edited April 24, 20206 yr by xthursdayx

19 hours ago, danioj said:

Hi Guys,

 

It's been a while, hope you're all well.

 

I currently have this lets encrypt docker container working well with dns validation (cloudflare - non proxy) and am serving a very simple landing page as well as a couple of apps via sub domains.

 

There is one niggling issue that I can't seem to solve that I am hoping someone can help me debug. I cannot get the site to redirect to https. Here is some relevant info from my setup:

 

Ports forwarded on my router to unraid:

router => unraid

80 => 180

443 => 1444

 

The code snippet below from the 'default' file in site-confs is unchanged from the installation and every link I have been to regarding nginx suggests this is the right code to redirect.

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

Now, it appears that the redirect works perfectly from the LAN BUT when I am out and about it does not. I have made sure that the browsers are not caching etc. In fact, I have just demo'd it right now. Phone on the Wifi, go to http://subdomain.domain.com redirects great. Drop the Wifi and repeat, no connection is made and no redirect.

 

I have checked with my ISP and they do not block port 80 and all my port forwards are in there and fine.

 

I am not sure how to go about debugging this. Can anyone help please?

 

D

Sounds like port 80 forwarding issue

3 hours ago, afsilver said:

I have letsencrypt working flawlessly with several subdomains. However, i want my top domain to reverse proxy into the Heimdall container. If i access my domain now, i get the following:

Welcome to our server

The website is currently being setup under this address.

For help and support, please contact: [email protected].

 

How can i redirect https://example.com to Heimdall?

Check out the preset heimdall subdolder proxy conf. It does exactly that