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


Recommended Posts

On 2/11/2018 at 11:45 PM, Jessie said:

The 2 lines above made the external emails work.  (they are in the template above)

 

Prior to the HTTPVAL modification I had port 80 ported to the sbs server.

After the letsencrypt changes, I changed HTTPVAL to true and:-

In the router I pointed 443 to the unraid server.

I also pointed external port 80 to internal port 8088 in the router. 

To get the letsencrypt docker to work, I configured http as 8080 and https as 443.

I wondered if I might have to redirect 8088 back to 80 to the sbs server.  But I don't know how to do that.

 

As an experiment I bypassed the letsencrypt docker and ported 443 back to the sbs server.  Emails worked again.

I then turned off porting on port 80 to the sbs server.  The emails still worked.

 

When I switched back to the letsencrypt docker, I lost external email functionality again.  I also can't access remote.mydomain.com.au which is remote access to the sbs server.

All of this worked before the letsencrypt changes.

In the letsencrypt template 

http set at 8088

https set at 443

HTTPVAL = true

 

You posted this message a month ago, saying that you originally had port 80 forwarded to your sbs server. It was not reverse proxied through le/nginx. Clients accessed it directly through port 80 via router forwarding. 

 

When le required port 80 for validation you changed it and forwarded it to le. That's when your sbs server stopped working (externally). It has nothing to do with nginx or reverse proxy you never reverse proxied it before. 

Link to comment
8 hours ago, aptalca said:

 

You posted this message a month ago, saying that you originally had port 80 forwarded to your sbs server. It was not reverse proxied through le/nginx. Clients accessed it directly through port 80 via router forwarding. 

 

When le required port 80 for validation you changed it and forwarded it to le. That's when your sbs server stopped working (externally). It has nothing to do with nginx or reverse proxy you never reverse proxied it before. 

In SBS server, if you try to go to http://remote.mydomain.com.au, the server will detect the address and rename the url to https://remote.mydomain.com.au.

So the only function of port 80 in sbs is to redirect HTTP:// to HTTPS:// on port 443.

 

So when it worked, sbs might see the http:// on port 80, but then it redirected to HTTPS:// on port 443 which went via the reverse proxy.

 

If you try to go directly to https://remote.mydomain.com.au, port 80 is not involved in the process.

 

There was another issue with the original configuration.  Emails to external devices would time out.  A bit of googling discovered that if you inserted the following lines just before the redirect, all would be good. 

 

proxy_request_buffering off;
proxy_buffering off;

 

I still have 2 servers running this configuration.  They will work until the certificates expire then they will stop.

 

When the changes to LE happened and I had to forward port 80 to internal port 8088 on the Unraid Server, the path through the proxy to SBS stopped at the same time. I incorrectly thought that port 80 was the cause.

 

The loss of port 80 only means that I must use HTTPS://remote.mydomain.com.au.  That's not really an issue from a user perspective.

 

I spent last weekend trying to solve this.  Whilst I now have a better understanding of how this thing works, I am no closer to an answer.

 

Below is a typical entry from the nginx log when it fails.

 

2017/12/24 22:22:31 [error] 357#357: *303 upstream timed out (110: Operation timed out) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: remote.mydomain.com.au, request: "POST /Microsoft-Server-ActiveSync?Cmd=Ping&User=we.local%5Crach&DeviceId=SEC18D91DF70EF08&DeviceType=SAMSUNGSMG930F HTTP/1.1", upstream: "https://192.xxx.xxx.xxx:443/Microsoft-Server-ActiveSync?Cmd=Ping&User=we.local%5Crach&DeviceId=SEC18D91DF70EF08&DeviceType=SAMSUNGSMG930F", host: "remote.mydomain.com.au"

 

 

Edited by Jessie
Link to comment
15 hours ago, Jessie said:

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?

 

 

It's been doing the same thing. Port 80 seems to not be blocked by my isp currently.

Link to comment

Hello all,

 

So I am in the process of securing my sevrer with SSL. Currently I have everything configured with letsencrypt and works. My only problem I seem to have is Emby. It works and it forwards http to https, the cert is good and everything works and loads but it is horribly slow. Not going through Nginx (straight ip+ssl port) it works just as expected except obviously an invalid cert from missing domain. So the problem has to lie within Nginx and/or the reverse proxy. Any help would be greatly appreciated and am wondering if anyone else has been having any issues like this.

 

Here is my reverse proxy(replaced my domain with DOMAIN), I am not using the default but a file in site-confs named emby

##EMBY Server##
server {  
    listen 443 ssl;
    server_name emby.DOMAIN.cc;

    root /config/www;
    index index.html index.htm index.php;

    ssl_dhparam /config/nginx/dhparams.pem;
    
    ###SSL Certificates
    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem; 
    
    ssl_session_timeout 30m;
    ssl_session_cache shared:SSL:50m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

proxy_hide_header X-Powered-By;
add_header X-Xss-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff"  always;
add_header Strict-Transport-Security "max-age=2592000; includeSubdomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header 'Referrer-Policy' 'no-referrer';
add_header Content-Security-Policy "frame-ancestors DOMAIN.cc emby.DOMAIN.cc;";

proxy_hide_header X-Powered-By;
proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

    location / {
		proxy_pass https://192.168.1.2:8446/;
}
}

Here is my default in case that matters, it points to heimdall docker to hold all my links to all installed dockers and apps.

 

## Version 2018/01/29 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default

# listening on port 80 disabled by default, remove the "#" signs to enable
# redirect all traffic to https
server {
	listen 80;
	server_name _;
	return 301 https://$host$request_uri;
}

# main server block
server {
	listen 443 ssl default_server;

	root /config/www;
	index index.html index.htm index.php;

	server_name _;

	# all ssl related config moved to ssl.conf
	include /config/nginx/ssl.conf;

	client_max_body_size 0;

    location / {
        proxy_pass https://192.168.1.2:8445/;
        proxy_max_temp_file_size 2048m;
        include /config/nginx/proxy.conf;
    }
}

 

Edited by Nickglott
Link to comment
On 19/11/2016 at 3:26 AM, ChaOConnor said:

I'm trying to troubleshoot this.  I've installed the docker and used ports 8086 and 444.  When I go to https://unraidIP:444 or http://unraidIP:8086, I get "Unable to Connect".  After a couple of minutes, the docker shuts down.  I went to my "appdata" and locked in the "Log" folder, but nothing is in any of the three folders. 

 

I've deleted the docker and the folder in "appdata" and tried reinstalling.  I've tried different ports, same thing.

 

I'm using duckDNS and I've verified the domain I'm using works.  I've also verified that port 443 on my firewall points to my Unraid server.

 

What am i missing?  Any thoughts?

unraidConfig.png.b0f237fdac38d9433515cdb0f20c40c3.png

 

Hey guys. Same problems here.

 

The script just can't connect to my server. Which is not odd since I can't connect to it not even from my local pc.

My ports on the router are open to 81 and 444 and docker is set to look at 81 and 444.

 

My logs say:

Failed authorization procedure. www.xxx.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.xxx.net/.well-known/acme-challenge/qT7E563QM0hW3TPVVk2THilZL7JlbrexLVzrKaMUTkM: Connection refused, xxx.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://xxx.net/.well-known/acme-challenge/kmRr9YCRmX035P6QuVoqYoESOP45fAptrLyBn8m1uWU: Connection refused

 

 

Browsing to http://192.168.0.250:81 or 444 doesn't do anything and throws out:

192.168.0.250 refused to connect.

 

ERR_CONNECTION_REFUSED

Untitled.png

Edited by gxs
Extra info
Link to comment
17 minutes ago, gxs said:

My ports on the router are open to 81 and 444

 

You need to open 80 and forward to 81 and open 443 and forward to 444

 

EDIT: Just seen your screenshots.

 

Your template is out of date, either look at the github page for the missing parameters, or delete the template and reinstall from CA using a brand new template.  You won't lose any data,

Edited by CHBMB
Link to comment
3 minutes ago, CHBMB said:

 

You need to open 80 and forward to 81 and open 443 and forward to 444

 

EDIT: Just seen your screenshots.

 

Your template is out of date, either look at the github page for the missing parameters, or delete the template and reinstall from CA using a brand new template.  You won't lose any data,

I have installed this docker three times now. Today. How out of date can it be?

 

To clarify... From the CA Apps plugin.

Edited by gxs
Link to comment

Have you had it installed before?

 

Damnit, that's why you shouldn't quote someone and assume you have the "same" problem.  I was looking at the post you quoted.

 

You need to post your docker run command.  Link in my sig.  And check your ISP isn't blocking port 80 and be 110% sure your DNS is correct

Edited by CHBMB
Link to comment

I have also wiped the whole docker, template and all the remains from my server and installed everything from scratch.

 

The odd thing is that I did see some ACME website on port 81 but it defaulted to refused to connect message after another refresh.

Now it seems that port 444 works and port 81 doesn't. Which is odd to say the least.

 

Ok I can officially say that port 444 now works and port forwards just fine:

 

Welcome to our server

The website is currently being setup under this address.

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

 

Port 81/80 rejects the connection but since I'm only after the certificates there probably isn't any point in me fixing things.

Edited by gxs
Link to comment
5 minutes ago, gxs said:

I have also wiped the whole docker, template and all the remains from my server and installed everything from scratch.

 

The odd thing is that I did see some ACME website on port 81 but it defaulted to refused to connect message after another refresh.

Now it seems that port 444 works and port 81 doesn't. Which is odd to say the least.

See my edit before, and chances are if you're finding something odd, it's because you're doing something wrong, or your ISP is blocking port 80 and unless you post your docker run command we can't really help you.

 

If the LE routine doesn't complete, you won't get Nginx coming up so you'll get nothing on port 81 locally.

Link to comment
3 minutes ago, CHBMB said:

See my edit before, and chances are if you're finding something odd, it's because you're doing something wrong, or your ISP is blocking port 80 and unless you post your docker run command we can't really help you.

 

If the LE routine doesn't complete, you won't get Nginx coming up so you'll get nothing on port 81 locally.

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='letsencrypt' --net='bridge' --privileged=true -e TZ="Europe/Budapest" -e HOST_OS="unRAID" -e 'EMAIL'='[email protected]' -e 'URL'='pivk.net' -e 'SUBDOMAINS'='www' -e 'ONLY_SUBDOMAINS'='false' -e 'DHLEVEL'='2048' -e 'VALIDATION'='http' -e 'DNSPLUGIN'='' -e 'PUID'='99' -e 'PGID'='100' -p '81:80/tcp' -p '444:443/tcp' -v '/mnt/user/appdata/letsencrypt':'/config':'rw' 'linuxserver/letsencrypt'

dfb7b4b86d1ea7865c87a4f835aab9b6dfdc8d5537b8b549957560cab5389351

 

And no my ISP is not blocking any ports and it wouldn't explain why I can't even access it locally.

 

LE says that the server is ready.

Edited by gxs
Link to comment
1 minute ago, gxs said:

And no my ISP is not blocking any ports and it wouldn't explain why I can't even access it locally.

 

Yes it would, because if authorisation doesn't occur, nginx doesn't work.

 

So if LE says the server is ready what's the issue? 

 

Restart the container and post the full logs.

Link to comment

The issue is that port 80 doesn't work (port 444 works after the 5th install). Unless it's supposed to not work and reject incoming connections?

 

Brought to you by linuxserver.io
We gratefully accept donations at:
https://www.linuxserver.io/donations/
-------------------------------------
GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
using keys found in /config/keys
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Variables set:
PUID=99
PGID=100
TZ=Europe/Budapest
URL=pivk.net
SUBDOMAINS=www
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
DHLEVEL=2048
VALIDATION=http
DNSPLUGIN=
[email protected]
STAGING=

Backwards compatibility check. . .
No compatibility action needed
2048 bit DH parameters present
SUBDOMAINS entered, processing
Sub-domains processed are: -d www.pivk.net
E-mail address entered: [email protected]
http validation is selected
Certificate exists; parameters unchanged; attempting renewal
<------------------------------------------------->

<------------------------------------------------->
cronjob running on Wed Mar 7 22:52:32 CET 2018
Running certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/pivk.net.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal

-------------------------------------------------------------------------------

The following certs are not due for renewal yet:
/etc/letsencrypt/live/pivk.net/fullchain.pem (skipped)
No renewals were attempted.
No hooks were run.
-------------------------------------------------------------------------------
[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Server ready

Link to comment
Just now, CHBMB said:

OK, so LetsEncrypt is working absolutely fine, so you need to edit the Nginx default file and configure your webserver.  Can't remember what the default config is, but you may need to configure the server responses on port 80.

Ok. Thanks. I'll just leave it be then because it's not really needed for the moment as long as the certificates are working.

 

Thanks for the help CHBMB

Link to comment
15 hours ago, gxs said:

Ok. Thanks. I'll just leave it be then because it's not really needed for the moment as long as the certificates are working.

 

Thanks for the help CHBMB

 

And that's why port 80 is not enabled by default in the nginx site config

 

If you check the site config, it tells you what needs to be done to enable it

Link to comment

I'm trying to use Google DNS, followed directions to the best of my abilities but I get this...

Failed authorization procedure. 777.mystupiddomain.com (dns-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect TXT record "_osh_Dq_e2Ns8E02XDK4ahHa7ZaIn7JEO0N6nGxK5GI" found at _acme-challenge.777.mystupiddomain.com

 

I've now hit the rate limit so be awhile before I can try anything. Damn this is frustrating.

Edited by BrandonG777
Link to comment
On 3/5/2018 at 4:16 AM, sinbrkatetete said:

 

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. :$

 

Hmm.  I'm still not getting it to work.

 

I add the linked conf from the post mentioned.  At first it didn't work and I was met with an error that the directive stream was not acceptable.  I added the below to the very top of the nginx.conf file:

 

load_module /usr/lib/nginx/modules/ngx_stream_module.so;

 

After this, Letsencrypt was able to boot up.

 

But when Owntracks is trying to connect to server.duckdns.org I get the error:

 

Unable to connect to server (32103) - 

java.net.ConnectException: Connection refused

 

Maybe my  configuration is incorrect for the nginx file or owntracks?  My MQTT is running on port 1883 on my server (192.168.1.3) so my nginx.conf addition looks like this:

 

stream {
        upstream mosquitto {
                server 192.168.1.3:1883;
        }

        server {
                listen 8883 ssl;
                proxy_pass mosquitto;

                ssl_certificate /config/keys/letsencrypt/fullchain.pem;
				ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
				ssl_dhparam /config/nginx/dhparams.pem;
        }
}

My Owntracks configuration looks like this:

 

Mode: Private MQTT

Host: server.duckdns.org

Port: 1883

Use WebSockets: "No"

 

Security

TLS: "No"

 

I'm not sure I'm correctly understanding the post where you said:

 

"As it is now, my mqtt clients connect by using any of the three subdomains the duckdns.org docker is "following" @ port 8883."

 

My subdomains like Home Assistant and Next Cloud are not following any port besides the specific port designated to those dockers on my local network.

 

Probably a silly oversight on my part.  I'll keep tinkering with the settings.

 

 

Link to comment
On 3/6/2018 at 5:13 PM, Nickglott said:

Hello all,

 

So I am in the process of securing my sevrer with SSL. Currently I have everything configured with letsencrypt and works. My only problem I seem to have is Emby. It works and it forwards http to https, the cert is good and everything works and loads but it is horribly slow. Not going through Nginx (straight ip+ssl port) it works just as expected except obviously an invalid cert from missing domain. So the problem has to lie within Nginx and/or the reverse proxy. Any help would be greatly appreciated and am wondering if anyone else has been having any issues like this.

 

 

Having the same issue myself. emby is running very slow. Unfortunately I don't have a solution yet.

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.