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


Recommended Posts

2 minutes ago, aptalca said:

I guarantee cloudflare is a better option than your current dns provider. Do yourself a favor, get a free account, point your nameservers there and do dns validation with wildcard

thanks i will look into that. but i would have to move my domain (no ddns) there in order to get a certificate, wouldn't i?

Link to comment
thanks i will look into that. but i would have to move my domain (no ddns) there in order to get a certificate, wouldn't i?
No, you shouldn't. I'm using Google domains for my registrar and have it pointing to cloudflare for dns

Sent from my HD1905 using Tapatalk

Link to comment
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:image.thumb.png.1ca81911c5cc0363bbc6f35ce9ac8c5c.png

 

And the following config: image.thumb.png.b12e93e015dc7e021f52ed4fab9eadc5.png

 

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.

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

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

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

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

  • Thanks 1
Link to comment
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

Link to comment

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;

...

 

Link to comment

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.

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

 

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

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

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

Link to comment

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


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: me@example.com.

 

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

Link to comment

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 by xthursdayx
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.