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


Recommended Posts

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

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

 

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

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

  • Thanks 1
Link to comment
6 hours ago, aptalca said:

Sounds like port 80 forwarding issue

I understand why your mind might go there, mine did too. Unless I am blind, it's really not. I am stumped.

 

Any other out there ideas you can suggest for me to chase down?

 

Nope. The official response from the ISP is misinformed (or a downright lie). My ISP does in fact block port 80. Thats the issue. Thanks for the reply anyway.

 

 

Edited by danioj
Link to comment
On 4/22/2020 at 12:53 PM, carlosmorgado said:

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

So I decided to do the configuration with DNS validation and redone deleted the docker image which fixed the connection problem, now my only problem is that I allways get 522 nextcloud

Link to comment
2 hours ago, carlosmorgado said:

So I decided to do the configuration with DNS validation and redone deleted the docker image which fixed the connection problem, now my only problem is that I allways get 522 nextcloud

Did you Google it? It tells you exactly what the issue is

Link to comment

I was wondering if someone would mind casting thier eye over what I have done to be able to resolve dockers via my external app.domain.tld BUT limit access to just client requests from my LAN. 

 

Over in this thread I was investigating how I might do that: 

 

In short, I setup the application via the reverse proxy like any other public facing app (e.g. with DNS to my external site and through reverseproxy). Result, available through http://app.domain.tld as expected, but not desired. I only want it to be accessible via requests from my LAN.

 

So I put this code into the location code block of the app.subdomain.conf file that sits within the proxy-confs folder of my letsencrypt setup.

location / {
  # allow anyone in 192.168.1.0/24
  allow   192.168.1.0/24;
  # drop rest of the world 
  deny    all;
}

The result, I can access https://app.domain.tld from the LAN but NOT the Internet - which returns a 403. Excellent!!!!

 

I just want to make sure that I am not missing some obvious security issue here which would make the app accessible from the internet or worse.

Edited by danioj
Link to comment
19 hours ago, aptalca said:

 

Annotation 2020-04-25 143401.png

It is a good thing you were born with all the answers. 

For the rest of us mortals that are still learning I guess this image (not a link, 'cause that might actually be productive) really might help some. But as it turns out I tried to follow this to the best of my knowledge (apparently your

On 4/25/2020 at 6:36 AM, aptalca said:

Did you Google it? It tells you exactly what the issue is

means "it does not really tell you exactly what to do, but a general direction of what to do, and the rest is on you.") and I still get the same result 522 error, any ideas?

Link to comment
16 hours ago, danioj said:

I was wondering if someone would mind casting thier eye over what I have done to be able to resolve dockers via my external app.domain.tld BUT limit access to just client requests from my LAN. 

 

Over in this thread I was investigating how I might do that: 

 

In short, I setup the application via the reverse proxy like any other public facing app (e.g. with DNS to my external site and through reverseproxy). Result, available through http://app.domain.tld as expected, but not desired. I only want it to be accessible via requests from my LAN.

 

So I put this code into the location code block of the app.subdomain.conf file that sits within the proxy-confs folder of my letsencrypt setup.


location / {
  # allow anyone in 192.168.1.0/24
  allow   192.168.1.0/24;
  # drop rest of the world 
  deny    all;
}

The result, I can access https://app.domain.tld from the LAN but NOT the Internet - which returns a 403. Excellent!!!!

 

I just want to make sure that I am not missing some obvious security issue here which would make the app accessible from the internet or worse.

That's what I do for a couple of things as well. But I also make sure there is additional auth (like http auth) for good measure. I did a bunch of tests on different networks and it seemed to work as intended.

Link to comment
1 hour ago, carlosmorgado said:

It is a good thing you were born with all the answers. 

For the rest of us mortals that are still learning I guess this image (not a link, 'cause that might actually be productive) really might help some. But as it turns out I tried to follow this to the best of my knowledge (apparently your

means "it does not really tell you exactly what to do, but a general direction of what to do, and the rest is on you.") and I still get the same result 522 error, any ideas?

Look, I'm not trying to be rude and I don't claim to have all the answers. In fact, I asked you if you googled it because that's the first thing I do when I have an issue.

 

I posted the picture of the first Google result (highlighted answer) because it tells you exactly what the issue is. I suggest you focus on that rather than get worked up about my post.

 

It tells you "Error 522 indicates that Cloudflare is unable to reach the origin web server and the request times out", which means cloudflare can't connect to your server. I honestly don't know how to word it any clearer.

 

It looks like you turned on caching on cloudflare (which we recommend against), and your server is not accessible. Check your ip, port forwarding, etc.

  • Thanks 1
Link to comment
It looks like you turned on caching on cloudflare (which we recommend against), and your server is not accessible. Check your ip, port forwarding, etc.


Sorry... not trying to interject myself here; apologies.

It’s recommended to turn CF Caching OFF? Would I turn “Caching Level” to “No Query String”, or change bottom drop down to “Respect existing headers” to successfully turn caching off?

9d77906348ca70f269ceb1fe3958aca7.plist


Thanks for everything you do Aptalca
Link to comment

Hey all,

 

Hoping that someone can help me. I have Letsencrypt up and working for a number of dockers. With a Proxynet setup. 

 

I am trying to configure the new Jitsi from Spaceinvader one's setup.   When I get to the point of switching over to the Proxynet for each of the jitsi dockers. The IP addresses appear to drop in and out for the dockers...  This I believe maybe an issue with the proxynet. or perhaps letsencypt.   But I am not sure... 

 

As I wasn't sure if this was a problem with Jitsi or letsencypt I thought it best to ask

 

Link to comment
28 minutes ago, blaine07 said:

 


Sorry... not trying to interject myself here; apologies.

It’s recommended to turn CF Caching OFF? Would I turn “Caching Level” to “No Query String”, or change bottom drop down to “Respect existing headers” to successfully turn caching off?

9d77906348ca70f269ceb1fe3958aca7.plist


Thanks for everything you do Aptalca emoji2.png

To start with, we recommend turning it off. Once you get everything working, you can then experiment with it.

 

I believe with http validation it outright doesn't work because letsencrypt acme server's validation request goes to cloudflare instead of the letsencrypt container (not too sure about it).

 

With dns validation you can get it to work if set correctly. But we don't provide support for that.

 

There are quite a few different settings on cloudflare for proxy and they can be confusing.

Link to comment
To start with, we recommend turning it off. Once you get everything working, you can then experiment with it.
 
I believe with http validation it outright doesn't work because letsencrypt acme server's validation request goes to cloudflare instead of the letsencrypt container (not too sure about it).
 
With dns validation you can get it to work if set correctly. But we don't provide support for that.
 
There are quite a few different settings on cloudflare for proxy and they can be confusing.

Yeah I recently changed from http validation to Cloudflare dns validation. Everything appears to be fine at moment. If I recall I had to turn CF proxy off to get it to validate but turned it back on. I figure once my local certs expire I may have to toggle the proxy back off to get a renewal.

Was more or less just curious as to if it impacted anything, but if it’s working it’d probably be well in my interest to leave it alone LOL
Link to comment
1 hour ago, aptalca said:

Look, I'm not trying to be rude and I don't claim to have all the answers. In fact, I asked you if you googled it because that's the first thing I do when I have an issue.

 

I posted the picture of the first Google result (highlighted answer) because it tells you exactly what the issue is. I suggest you focus on that rather than get worked up about my post.

 

It tells you "Error 522 indicates that Cloudflare is unable to reach the origin web server and the request times out", which means cloudflare can't connect to your server. I honestly don't know how to word it any clearer.

 

It looks like you turned on caching on cloudflare (which we recommend against), and your server is not accessible. Check your ip, port forwarding, etc.

By enable caching do you mean  the orange cloud? 'Cause if so when I disable it I get image.png.7659e85c12d578f75a070aa719fb023c.png 

 

 

I tried enabling strict mode as someone else suggested in another post, same result, even though I am using dns validation and in the guide share some pages ago said I wouldn't need to port forward port 80 I just tried, same result.

Link to comment

I have two Unraid servers. On server one, I have several virtual machines (VMs) running Ubuntu. In one of these, I have Apache and several applications running.

 

On server two, I have several dockers running. These are the typical dockers like Sonarr, Deluge, etc. I also just installed the linuxserver/letsencrypt docker as a reverse proxy. The dockers that I have configured to use the reverse proxy are working as expected. I followed the directions in the video by SpaceInvader.

 

What I would like to do is use this same Letsencrypt docker for my VMs on Unraid server one.

 

I am guessing that I will need to create a new proxy.conf file but have not found anything online that points me to what I should include in that file.

 

Thanks for any help.

 

Frank Hahn

 

Link to comment
3 hours ago, fhahn said:

I have two Unraid servers. On server one, I have several virtual machines (VMs) running Ubuntu. In one of these, I have Apache and several applications running.

 

On server two, I have several dockers running. These are the typical dockers like Sonarr, Deluge, etc. I also just installed the linuxserver/letsencrypt docker as a reverse proxy. The dockers that I have configured to use the reverse proxy are working as expected. I followed the directions in the video by SpaceInvader.

 

What I would like to do is use this same Letsencrypt docker for my VMs on Unraid server one.

 

I am guessing that I will need to create a new proxy.conf file but have not found anything online that points me to what I should include in that file.

 

Thanks for any help.

 

Frank Hahn

 

You have to set the IP and port in the proxy-pass line instead of the variable. So if there is already a proxy-conf you can use, just edit that one.

Link to comment
36 minutes ago, saarg said:

You have to set the IP and port in the proxy-pass line instead of the variable. So if there is already a proxy-conf you can use, just edit that one.

There is a default file found here:

 

 

/mnt/user/appdata/letsencrypt/nginx/site-confs/default

 

It has the variable proxy_pass but it is commented out.

 

There is also a proxy_pass statement in each of the individual *.subdomain.conf.sample files found here:

 

/mnt/user/appdata/letsencrypt/nginx/proxy-confs/

 

Do I modify each of the ones that I have setup? Presently, I have these configured:

deluge.subdomain.conf

jellyfin.subdomain.conf

nzbhydra.subdomain.conf

sonarr.subdomain.conf

 

Each of these have the proxy_pass statement which looks like this:

proxy_pass $upstream_proto://$upstream_app:$upstream_port;

 

So I should edit each of the above files with something like this:

proxy_pass 192.168.100.20:8080;

 

Frank Hahn

Link to comment
2 hours ago, fhahn said:

There is a default file found here:

 

 

/mnt/user/appdata/letsencrypt/nginx/site-confs/default

 

It has the variable proxy_pass but it is commented out.

 

There is also a proxy_pass statement in each of the individual *.subdomain.conf.sample files found here:

 

/mnt/user/appdata/letsencrypt/nginx/proxy-confs/

 

Do I modify each of the ones that I have setup? Presently, I have these configured:

deluge.subdomain.conf

jellyfin.subdomain.conf

nzbhydra.subdomain.conf

sonarr.subdomain.conf

 

Each of these have the proxy_pass statement which looks like this:

proxy_pass $upstream_proto://$upstream_app:$upstream_port;

 

So I should edit each of the above files with something like this:

proxy_pass 192.168.100.20:8080;

 

Frank Hahn

The three lines above that proxy_pass line set the variables. Edit those instead to point to the ip and port instead of the container name and port

Link to comment
14 hours ago, aptalca said:

That's what I do for a couple of things as well. But I also make sure there is additional auth (like http auth) for good measure. I did a bunch of tests on different networks and it seemed to work as intended.

 

Thank you. It's nice to have the benefit of someone else doing the same to give me a little confidence that its ok.

Link to comment
13 hours ago, aptalca said:

The three lines above that proxy_pass line set the variables. Edit those instead to point to the ip and port instead of the container name and port

And here I finally thought I knew a little bit of nginx and you implement a new thing crushing my nginx selfesteem! 😛

Link to comment
14 hours ago, aptalca said:

The three lines above that proxy_pass line set the variables. Edit those instead to point to the ip and port instead of the container name and port

It now looks to be working.


I took one of the sample subdomain.conf files and copied it and named it after the VM that I have setup.


I modified these lines:


set $upstream_app 192.168.100.8; <-- IP address of the VM
set $upstream_port 443;               <-- Port that I want to forward to Apache on the VM
set $upstream_proto https;


90% of my site now works. I have a couple of web pages that revert from https://www.example.com to https://example.com when I click on them but that may be a configuration error on my part. I need to investigate further.


My last question is can I only do a reverse proxy on subdomains? For example, www.example.com? Or can I make it also work for just example.com?

 

I was going to try and modify this line from this:

server_name www.*;

 

to this:

server_name www.*,example.com;

 

Thanks.

 

Frank Hahn

 

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.