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


Recommended Posts

9 hours ago, Jessie said:

aptalca said

You never said what the problem is

 

It doesn't work.

Cannot access https://remote.mydomanename.com.au from the internet. 

Returns "Error 502"  Bad gateway, nginx/1.12.2 on a browser on a computer outside the local network.

(Site can be accessed inside the local network.)

 

 

If it works inside the lan but not outside, the only thing I can think of is that your le is actually not working, but that you somehow set your local dns (router) to redirect to the right ip. 

 

Check your router settings to make sure your port forwarding is correct

Link to comment
7 hours ago, sse450 said:

I finally got nextcloud with letsencrypt running following @CHBMB guide on ls.io with nextcloud.mydomain.com subdomain.

 

I would like to change subdomain from nextcloud.mydomain.com to just cloud.mydomain.com. Does it suffice to change all references of nextcloud.mydomain.com to cloud.mydomain.com in site nginx/site-confs/nextcloud and nextcloud's /config/www/nextcloud/config/config.php.

 

Let's assume that I added cloud as an additional subdomain to letsencrypt docker and fixed DNS record.

 

Do I need to change anything else?

 

 

 

No. 

Link to comment

I think I got my issue resolved with OpenVPN and letsencrypt. Since the letsencrypt uses port 442, I was able to use the OpenVPN port-share feature. 

I was able to vpn-in and still hit the nextcloud.

 

The new problem now is when I am on my wifi and tried to go to my nextcloud, it is very slow. Logging in would take like over a minute. When I tried to enter just the IP address of my unRaid and nextcloud port 444/tcp, it changes to my nextcloud.mydomain.com. 

Link to comment

Could someone please sumaryze what is the purpose of this container?

 

It automatically adds certs and HTTPS acess to all the containers? automatically or you have to configure all the containers manually?

 

It's like Organizr where you access all the containers trought in a secure way if you configure it with SSL certs?

 

Is there a video or some tutorial? I couldn't find anything on youtube

Link to comment
12 hours ago, aptalca said:

 

If it works inside the lan but not outside, the only thing I can think of is that your le is actually not working, but that you somehow set your local dns (router) to redirect to the right ip. 

 

Check your router settings to make sure your port forwarding is correct

Pretty sure Letsencrypt is working ok.

It is also concurrently running 2 x nextcloud dockers on ports 444 and 446.

They are both fine.

 

I also have 3 other servers running sbs and nextcloud.

2 of them are still working because the certificates haven't expired yet, and I haven't had to upgrade letsencrypt to the http method.

Ticking bomb though.  When the certificates expire, sbs will stop as well.

 

The 3rd one, the certificate expired and sbs stopped.  For the short term, I have had to bypass the LE docker and forward port 443 directly to the sbs server.

This means no nextcloud on that site.

 

I'm keen to resolve this before the other 2 sites certificates expire.

 

Back to the problem.  I think that LE is trying to communicate with SBS successfully but SBS is not responding.

That's where I get lost.  I wonder whether the certificate is now different and now not compatible with SBS?

Alternatively I was surprised when I originally set up lets encrypt that it let me reverse proxy to the sbs on port 443.  The same port as the LE docker.

Whether that is no longer possible, not sure.

 

I should point out that SBS as an entity is working fine on the local network. 

It needs to pass through the le docker to provide remote access and to update emails on devices outside the local network. eg emails on phones etc.

 

(Later)  I was able to compare the specs for a certificate on a working sbs system and a non working one.  They look identical.

That points back to something in the LE docker.  (maybe) Probably in the nginx part...

Edited by Jessie
further investigation
Link to comment
5 hours ago, pingmanping said:

I think I got my issue resolved with OpenVPN and letsencrypt. Since the letsencrypt uses port 442, I was able to use the OpenVPN port-share feature. 

I was able to vpn-in and still hit the nextcloud.

 

The new problem now is when I am on my wifi and tried to go to my nextcloud, it is very slow. Logging in would take like over a minute. When I tried to enter just the IP address of my unRaid and nextcloud port 444/tcp, it changes to my nextcloud.mydomain.com. 

I had similar issues before upgrading to v13 of nextcloud.  So if not running v13 yet, try the upgrade.

The change from port 444 to the domain name is expected.  That happens in your nextcloud config.php file.

I also had issues logging in with the android app.  In this case, there is a android beta app which works. (worked for me at least)

 

Link to comment
12 hours ago, L0rdRaiden said:

Could someone please sumaryze what is the purpose of this container?

It's a webserver, NGINX, like apache, but not. It has scripting built in to leverage the free ssl certificates issued by https://letsencrypt.org/

 

You can use it to host your own website, or you can configure it to reverse proxy other sites hosted on your network. Those sites may be your web GUI apps, if they support reverse proxy configurations. Each app may have unique quirks about reverse proxy, so they need to be configured manually on an individual basis. linuxserver.io has some example configurations, and many individual examples have been posted in this thread, or in the threads of the specific apps.

Link to comment
12 hours ago, Jessie said:

Pretty sure Letsencrypt is working ok.

It is also concurrently running 2 x nextcloud dockers on ports 444 and 446.

They are both fine.

 

I also have 3 other servers running sbs and nextcloud.

2 of them are still working because the certificates haven't expired yet, and I haven't had to upgrade letsencrypt to the http method.

Ticking bomb though.  When the certificates expire, sbs will stop as well.

 

The 3rd one, the certificate expired and sbs stopped.  For the short term, I have had to bypass the LE docker and forward port 443 directly to the sbs server.

This means no nextcloud on that site.

 

I'm keen to resolve this before the other 2 sites certificates expire.

 

Back to the problem.  I think that LE is trying to communicate with SBS successfully but SBS is not responding.

That's where I get lost.  I wonder whether the certificate is now different and now not compatible with SBS?

Alternatively I was surprised when I originally set up lets encrypt that it let me reverse proxy to the sbs on port 443.  The same port as the LE docker.

Whether that is no longer possible, not sure.

 

I should point out that SBS as an entity is working fine on the local network. 

It needs to pass through the le docker to provide remote access and to update emails on devices outside the local network. eg emails on phones etc.

 

(Later)  I was able to compare the specs for a certificate on a working sbs system and a non working one.  They look identical.

That points back to something in the LE docker.  (maybe) Probably in the nginx part...

 

If I remember correctly, you posted about your issues with sbs before, but then, you weren't actually reverse proxying your sbs server. You were connecting to it directly but thought you were reverse proxying. 

 

You need to provide more details on your setup. Is sbs running on a separate machine? If so, sbs also running on port 443 is fine, it's a different machine, different ip. If le and sbs are running on the same machine, sharing the same ip and network interface, they cannot both run on port 443.

Link to comment
12 hours ago, Jessie said:

I had similar issues before upgrading to v13 of nextcloud.  So if not running v13 yet, try the upgrade.

The change from port 444 to the domain name is expected.  That happens in your nextcloud config.php file.

I also had issues logging in with the android app.  In this case, there is a android beta app which works. (worked for me at least)

 

I just updated my container, but when I logged in as an admin and it is still showing the version is 12.0.3

Link to comment
I just updated my container, but when I logged in as an admin and it is still showing the version is 12.0.3
As per the first post in the Nextcloud thread you need to update manually. My recommendation would be via the command line

Sent from my LG-H815 using Tapatalk

Link to comment
20 minutes ago, CHBMB said:

As per the first post in the Nextcloud thread you need to update manually. My recommendation would be via the command line

Sent from my LG-H815 using Tapatalk
 

Is this the CLI upgrade you mentioned?

Also, there is an update button in the UI admin settings, can I use that as well?

 

 

 

nextcloud v13 upgrade button.png

Link to comment
4 hours ago, pingmanping said:

I just updated my container, but when I logged in as an admin and it is still showing the version is 12.0.3

Log in as admin

Goto settings and Basic settings (I think)

and there is a update button.

 

Works most of the time.

It is fixable if it fails.

Hint it may time out during step 4 and 5.  Don't leave the page when this happens.

It just means that the program hasn't finished downloading.

Wait 15 mins and press the retry button

If it fails again, wait a little longer.

If it still fails, go to your config.php file and set update to false and you can start again.

 

Another scenario I have encountered is that it downloads the file but doesn't go to the next step.

That's an easy fix as well, but see how you go here first.

 

 

Link to comment
10 hours ago, aptalca said:

 

If I remember correctly, you posted about your issues with sbs before, but then, you weren't actually reverse proxying your sbs server. You were connecting to it directly but thought you were reverse proxying. 

 

You need to provide more details on your setup. Is sbs running on a separate machine? If so, sbs also running on port 443 is fine, it's a different machine, different ip. If le and sbs are running on the same machine, sharing the same ip and network interface, they cannot both run on port 443.

No I was always reverse proxying.

The systems are live and the sbs part can't go down.

It was necessary to bypass the reverse proxy to keep it going.

I only mentioned it to demonstrate that the system only failed when going through the proxy.

 

The sbs machine is a separate machine. Although one of them is  an unraid VM.  Nevertheless, it has it's own Ip address.

 

I had a very in depth look at this problem over the weekend. (without success)

 

I am about to try copying the old letsencrypt files from a working machine to a non working machine and substituting the current certificates.

No idea whether it will work and it won't solve the problem of upgrading certificates.

 

But it might get the system up and running again. 

 

No that didn't work.

The main reason is I don't actually know how to do it.

In the end I tried changing the settings back to TLS-sni but it then attempted to recreate the certificates and failed.

 

Is it possible to obtain the docker that was installed prior to the tls-SNI issue?

I feel that something changed in nginx part of it which will no longer let me reverse proxy to the sbs server.

 

Sigh!!!....

 

Edited by Jessie
update
Link to comment
1 hour ago, Jessie said:

Log in as admin

Goto settings and Basic settings (I think)

and there is a update button.

 

Works most of the time.

It is fixable if it fails.

Hint it may time out during step 4 and 5.  Don't leave the page when this happens.

It just means that the program hasn't finished downloading.

Wait 15 mins and press the retry button

If it fails again, wait a little longer.

If it still fails, go to your config.php file and set update to false and you can start again.

 

Another scenario I have encountered is that it downloads the file but doesn't go to the next step.

That's an easy fix as well, but see how you go here first.

 

 

 

Or just use the command line.  It just works, every single time.

Link to comment
On 3/3/2018 at 7:29 AM, Jessie said:

Change Container port 80 to 81 or 8088. (whichever is not used elsewhere in the unraid server)

 

In your router Forward port 443 to your unraid server

In your router point external port 80 to internal port 81 or 8088 (Which ever you chose in the first line above) and forward to your unraid server.

 

Restart letsencrypt.

 

 

Both were port forwarded before, so I kept port 443 forwarded, and changed the port to port 80 external, to 81 internal, to unraid's ip address, and container port is 80 while host port is 81. I also changed the top url to (mydomain).duckdns.org and the subdomain to www. as was suggested to me

 

image.png.462777db09044a509fcbf4863dfaa49b.png

image.thumb.png.39d3091a005f23f3fc8932b3f63443fc.png

image.png.f1d74c72cd242d45cfd807a1e470b332.png

Link to comment
9 minutes ago, Server1Alpha said:

Both were port forwarded before, so I kept port 443 forwarded, and changed the port to port 80 external, to 81 internal, to unraid's ip address, and container port is 80 while host port is 81. I also changed the top url to (mydomain).duckdns.org and the subdomain to www. as was suggested to me

 

image.png.462777db09044a509fcbf4863dfaa49b.png

image.thumb.png.39d3091a005f23f3fc8932b3f63443fc.png

image.png.f1d74c72cd242d45cfd807a1e470b332.png

So did it work?  What did the logs say?

All being good you should have got a certificate for www.???.duckdns.org

 

Edited by Jessie
Link to comment
6 minutes ago, Server1Alpha said:

image.png.1af1b0eba606ccdfbac0277020a70cf8.png

 

No idea what I am doing wrong I had this working perfectly fine before the update really easily, hate bothering others with issues like this because it's usually something stupid.

I think it is something to do with the ports

to recap in the router

external port              Internal port             host

80                                81                              unraid ip

443                             443                            unraid ip

 

If you ping your domain, does it point to your ip address?

 

Are you sure 81 is not used elsewhere?

Did you try 8088?

(You would have to change 81 to 8088 in the router as well as the template)

 

 

Link to comment
4 hours ago, Jessie said:

I think it is something to do with the ports

to recap in the router

external port              Internal port             host

80                                81                              unraid ip

443                             443                            unraid ip

 

If you ping your domain, does it point to your ip address?

 

Are you sure 81 is not used elsewhere?

Did you try 8088?

(You would have to change 81 to 8088 in the router as well as the template)

 

 

Changed it to internal port 9293 on router, and host port 9293. Pinging the domain pings to my ip, the request times out.

 

Edit: There is a very small chance that my isp has started to block port 80, I will go and double check on that tomorrow.

Edited by Server1Alpha
Link to comment
1 hour ago, Server1Alpha said:

Changed it to internal port 9293 on router, and host port 9293. Pinging the domain pings to my ip, the request times out.

 

Edit: There is a very small chance that my isp has started to block port 80, I will go and double check on that tomorrow.

If the ping doesn't succeed that's ok. It's possible the router is not set to respond.  What is important is that it is looking for the correct address.

I would have thought it would work.

What happens in the log when you restart it?

Has it created a certificate yet?

 

 

Edited by Jessie
Link to comment
On 03. 03. 2018. at 6:18 AM, Living Legend said:

 

I think I have a very similar setup to you.  Nextcloud is done through its own sub domain.  Home Assistant is also done through its own sub domain.  I'm using a duckdns docker and a letsencrypt docker on unRAID.  The only difference is I'm running an MQTT docker, and Home Assistant as a docker as well.  I'm considering going back to my Pi and installing Hass.io so I'm not solely dependent on my server, but to date, everything has run rather smooth.

 

Your point on the  "site-confs" folder makes sense since this isn't a https connection.

 

In my futile efforts the other day I think I skimmed through nearly all of the links you provided.  I also noticed the usage of streams, but did not spend enough time to figure out how to get it working.  I may tinker a little more with it now.

 

Keep me in the loop on your progress.  I'll do the same.

 

Good luck.

 

So... I've "made it" work. Simply copying the conf from this post and adjusting the upstream server, the ssl_certificate, ssl_certificate_key and ssl_dhparam to my locations did the trick. I simply copy-pasted the conf to the nginx.conf file, right after the http config, before the commented out mail config. The thing is, I don' t know how to "bind" it to one of the subdomains I have certs for. As it is now, my mqtt clients connect by using any of the three subdomains the duckdns.org docker is "following" @ port 8883. I don't know if it's possible to "bind" it somehow to a subdomain, I don't have too much time on my hands atm, so I'll probably investigate further sometime in the future. For now, I'm happy all my clients can connect to it. I hope it's secure, since I don't know how to test. :$

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.