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


Recommended Posts

2 hours ago, munit85 said:

This was my problem as well. I don't know why, but once the changes propagated everything worked. 

 

thanks.

The way you set up your a record and cnames is correct. You just need to make sure that the a record remains up to date. You can use a docker image like ddclient to update it, or some routers can also do it.

 

If you're doing dns validation, look into getting a wildcard cert and then you only need to create one cname for "*" without the quotes and you'll be good. Between the a record and that wildcard cname, your domain and all subdomains will be covered.

  • Like 1
Link to comment

ok, being dumb here, have searched and tried configs for over 1 hr now...

 

does anyone have a working bitwarden config for subdomain w/docker on a seperate proxeynet

 

my others work just fine, but this one is making me pull out what hair i have left

 

help pls

 

Myk

  • Like 1
Link to comment
ok, being dumb here, have searched and tried configs for over 1 hr now...
 
does anyone have a working bitwarden config for subdomain w/docker on a seperate proxeynet
 
my others work just fine, but this one is making me pull out what hair i have left
 
help pls
 
Myk
There's a blog post on our site where I posted s working config.

Sent from my Mi A1 using Tapatalk

Link to comment
6 hours ago, CHBMB said:

There's a blog post on our site where I posted s working config.

Sent from my Mi A1 using Tapatalk
 

this is what I am trying to use already from the blog post, but am getting bad gateway :(

 


# make sure that your dns has a cname set for bitwarden

server {
    listen         80;
    server_name    bw.*;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name bitwarden.*;

    include /config/nginx/ssl.conf;
    set $upstream_bitwarden bitwarden;
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;

    location / {
        proxy_pass http://$upstream_bitwarden:8343;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /notifications/hub {
        proxy_pass http://$upstream_bitwarden:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass http://$upstream_bitwarden:8343;
    }
}

 

Link to comment
1 hour ago, MyKroFt said:

this is what I am trying to use already from the blog post, but am getting bad gateway :(

 



# make sure that your dns has a cname set for bitwarden

server {
    listen         80;
    server_name    bw.*;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name bitwarden.*;

    include /config/nginx/ssl.conf;
    set $upstream_bitwarden bitwarden;
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;

    location / {
        proxy_pass http://$upstream_bitwarden:8343;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /notifications/hub {
        proxy_pass http://$upstream_bitwarden:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass http://$upstream_bitwarden:8343;
    }
}

 

Your server names aren't matching for 80 and 443, bw vs bitwarden

Link to comment
17 hours ago, aptalca said:

The way you set up your a record and cnames is correct. You just need to make sure that the a record remains up to date. You can use a docker image like ddclient to update it, or some routers can also do it.

 

If you're doing dns validation, look into getting a wildcard cert and then you only need to create one cname for "*" without the quotes and you'll be good. Between the a record and that wildcard cname, your domain and all subdomains will be covered.

excellent. I set my subdomains to "wildcard" in the container and set cloudflare cname to * and it seems to be working. 

 

Thanks a lot.

Link to comment

Please please ..... 

 

- letsencrypt running on static ip on my lan 192.168.13.11 . 

- all settings are default - I put my dynamic DNS name in the domain name field.

- router port forwarded 9999 to 80 at 192.168.13.11

- confirmed dynamic dns service forwards to my IP because I have other ports forwarded no problem. But want to replace all my port forwarding with letsencrypt

- sonarr, for instance running on 192.168.13.45:8989

- I have set base URL in sonarr to /sonarr and restarted

- I have not touched proxy.conf

 

on one machine - win10/chrome returns a 404 in top left corner of the screen

on another machine - win10/chrome returns "site cannot be reached"

 

I'm so confused. My nginx.conf file looks like this but of course it's wrong... I have another 8 dockers I want to set up the same - some don't have a base URL setting such as deluge - is it possible to help with that as well?

 

server {

server_name _;

        location ^~ /sonarr {
            # enable the next two lines for http auth
            #auth_basic "Restricted";
            #auth_basic_user_file /config/nginx/.htpasswd;

            # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf
            #auth_request /auth;
            #error_page 401 =200 /login;

            #include /config/nginx/proxy.conf;
            #resolver 192.168.13.45 valid=30s;
            #set $upstream_sonarr sonarr;
            proxy_pass http://192.168.13.45:8989;
        }

        location ^~ /sonarr/api {
            #include /config/nginx/proxy.conf;
            #resolver 192.168.13.45 valid=30s;
            #set $upstream_sonarr sonarr;
            proxy_pass http://192.168.13.45:8989;
        }

}

Link to comment
52 minutes ago, tiwing said:

Please please ..... 

 

- letsencrypt running on static ip on my lan 192.168.13.11 . 

- all settings are default - I put my dynamic DNS name in the domain name field.

- router port forwarded 9999 to 80 at 192.168.13.11

- confirmed dynamic dns service forwards to my IP because I have other ports forwarded no problem. But want to replace all my port forwarding with letsencrypt

- sonarr, for instance running on 192.168.13.45:8989

- I have set base URL in sonarr to /sonarr and restarted

- I have not touched proxy.conf

 

on one machine - win10/chrome returns a 404 in top left corner of the screen

on another machine - win10/chrome returns "site cannot be reached"

 

I'm so confused. My nginx.conf file looks like this but of course it's wrong... I have another 8 dockers I want to set up the same - some don't have a base URL setting such as deluge - is it possible to help with that as well?

 

server {

server_name _;

        location ^~ /sonarr {
            # enable the next two lines for http auth
            #auth_basic "Restricted";
            #auth_basic_user_file /config/nginx/.htpasswd;

            # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf
            #auth_request /auth;
            #error_page 401 =200 /login;

            #include /config/nginx/proxy.conf;
            #resolver 192.168.13.45 valid=30s;
            #set $upstream_sonarr sonarr;
            proxy_pass http://192.168.13.45:8989;
        }

        location ^~ /sonarr/api {
            #include /config/nginx/proxy.conf;
            #resolver 192.168.13.45 valid=30s;
            #set $upstream_sonarr sonarr;
            proxy_pass http://192.168.13.45:8989;
        }

}

Start from the beginning. Forget about the reverse proxy. Forward port 80 on your router to port 80. Check the docker log, make sure cert is retrieved. Then check the landing page

Edited by aptalca
Link to comment

Am really trying here :(  /banging head on desk

 

changed the offending line to:  server_name    bitwarden.*;

 

and now I am getting timeouts :(

 

current conf file

 


# make sure that your dns has a cname set for bitwarden

server {
    listen         80;
    server_name    bitwarden.*;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name bitwarden.*;

    include /config/nginx/ssl.conf;
    set $upstream_bitwarden bitwarden;
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;

    location / {
        proxy_pass http://$upstream_bitwarden:8343;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /notifications/hub {
        proxy_pass http://$upstream_bitwarden:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass http://$upstream_bitwarden:8343;
    }
}

 

Link to comment
2 hours ago, MyKroFt said:

Am really trying here :( /banging head on desk

 

changed the offending line to:  server_name    bitwarden.*;

 

and now I am getting timeouts :(

 

current conf file

 



# make sure that your dns has a cname set for bitwarden

server {
    listen         80;
    server_name    bitwarden.*;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name bitwarden.*;

    include /config/nginx/ssl.conf;
    set $upstream_bitwarden bitwarden;
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;

    location / {
        proxy_pass http://$upstream_bitwarden:8343;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /notifications/hub {
        proxy_pass http://$upstream_bitwarden:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /notifications/hub/negotiate {
        proxy_pass http://$upstream_bitwarden:8343;
    }
}

 

 

Looks like you are running letsencrypt on a custom bridge from the config you posted. Then you need to change the port from 8343 to 80 as letsencrypt talks to bitwarden internally using the the custom docker bridge

 

The second thing I'm not sure about, as nginx is black arts for me. I think you need to set the include and resolver line in each location. I'm sure aptalca or any other nginx guru will correct me if I'm wrong. 

 

Here is my working bitwarden proxy conf. 

 

server {
    listen         80;
    server_name    bitwarden.*;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name bitwarden.*;
  
    include /config/nginx/ssl.conf;
    client_max_body_size 128M;

    location / {
	include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
		set $upstream_bitwarden bitwarden;
        proxy_pass http://$upstream_bitwarden:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
  
    location /notifications/hub {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_bitwarden bitwarden;
        proxy_pass http://$upstream_bitwarden:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
  
    location /notifications/hub/negotiate {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_bitwarden bitwarden;
        proxy_pass http://$upstream_bitwarden:80;
    }
}

 

Edited by saarg
Adding proxy conf
Link to comment
# make sure that your dns has a cname set for sonarr and that your sonarr container is not using a base url
  server {
  listen 80;
  server_name bw.*;
  return 301 https://$server_name$request_uri;
  }


server {
    listen 443 ssl;
    server_name bw.*;
    
#   add_header X-Content-Type-Options nosniff;
#   add_header X-XSS-Protection "1; mode=block";
#   add_header Referrer-Policy same-origin;

    include /config/nginx/ssl.conf;
    client_max_body_size 0;

 
    location / {
#       auth_basic "Restricted";
#       auth_basic_user_file /config/nginx/.htpasswd;
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_bitwarden bitwarden;
        proxy_pass http://$upstream_bitwarden:80;
        proxy_set_header Host $host;
#       proxy_ssl_server_name on;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
#       proxy_headers_hash_bucket_size 512;
    }
    
#   location /notifications/hub {
#       proxy_pass http://10.10.20.50:3012;
#       proxy_set_header Upgrade $http_upgrade;
#       proxy_set_header Connection "upgrade";
#   }
    
#   location /notifications/hub/negotiate {
#       proxy_pass http://10.10.20.50:8343;
#   }

  
}

tempsnip.thumb.png.fbd45da6ddcd8a3d7a057103a6b2a837.png

 

Can someone please help. I cannot get pass the loading page from my web browser using reverse proxy. Logging in via webUI and connecting with my bitwarden on my phone works correctly. 

 

I notice a error in log file whenever I try access my bw subdomain
Capture.PNG.a48e224f0e893ed74a7dc138d8fae723.PNG

 

Edited by bulletjie
Link to comment
16 minutes ago, CHBMB said:

@bulletjie Did you look at the post immediately above yours?!

Yes I did, and since my post I enabled the additional lines and included the  include and resolver lines as per the previous post but no luck. Bitwarden seems to work as when sync from my phone and using the webUI but I cannot get past the spinning wheel when trying to log in using the domain name. Could it be a firewall issue? I use pfsense btw.

 

 

Link to comment
21 hours ago, aptalca said:

Start from the beginning. Forget about the reverse proxy. Forward port 80 on your router to port 80. Check the docker log, make sure cert is retrieved. Then check the landing page

removed the docker, deleted appdata, and repulled. there are no logs..!! (in the /log folder). port 80 is forwarded to the right IP:80... "This site can’t be reached". There has to be something so basic that I'm missing.

Link to comment
4 hours ago, tiwing said:

removed the docker, deleted appdata, and repulled. there are no logs..!! (in the /log folder). port 80 is forwarded to the right IP:80... "This site can’t be reached". There has to be something so basic that I'm missing.

The log from the docker page, the sheet icon to the right of the container. 

Link to comment

Due to change of ISP, I had to change my static IP in Cloudflare DNS records. As soon as I did that, my collabora and nextcloud stopped working together. I am receiving errors in NC and documents don't open. I checked NC/Collabora forums and found that this error is related to the invalid certificates. I feel that it is related to the letsencrypt certificates as issued for the old IP. 

 

My question is, is there a way to force renewing certificates?

 

Thanks

Link to comment
2 minutes ago, sse450 said:

Due to change of ISP, I had to change my static IP in Cloudflare DNS records. As soon as I did that, my collabora and nextcloud stopped working together. I am receiving errors in NC and documents don't open. I checked NC/Collabora forums and found that this error is related to the invalid certificates. I feel that it is related to the letsencrypt certificates as issued for the old IP. 

 

My question is, is there a way to force renewing certificates?

 

Thanks

You shouldn't need to if it's only your IP address that's changed.

To elaborate, your certificate is issued based on your domain name.  IP address doesn't come into it.  For instance, I have a dynamic IP address, I don't need to get new certificates every time my IP address changes.

Have you got cloudflare caching switched on?  If so, turn it off.

Without a bit more info about error messages around certs it's difficult to help, but I think you're barking up the wrong tree.

Edited by CHBMB
Link to comment
20 hours ago, CHBMB said:

Without a bit more info about error messages around certs it's difficult to help, but I think you're barking up the wrong tree.

I don't know where the correct tree is :) Hence, asking for help.

 

Today, I did a very useful test. Currently, both ISPs, the old and the new, have connection at the same location. I reversed back to the old ISP and changed the IP number to that of old ISP at Cloudflare DNS settings. Collabora is again started working nicely.

 

So, it looks it is related to the new ISP connection. If it is nothing to do with letsencrypt certs, then what could it be? Router (pfSense) is the same with forwarded ports 80 and 443 to 81 and 443, respectively.

 

Thanks for your support.

 

More Info on my setup:

1. I use your collabora and linuxserver's nextcloud and letsencrypt dockers.

2. Nextcloud and collabora are setup as subdomains. Setup procedure as per your guide.

3. I use wildcard with Cloudflare plugin in Letsencrypt settings.

4. NC: 15.0.5, Collabora: 4.0.2, Letsencrypt: Latest LS docker, Collabora Plugin NC: 3.2.4

4. The error in NC log is as below:

Error	PHP	Undefined offset: 0 at /config/www/nextcloud/lib/private/AppFramework/Http.php#150		2019-03-21T12:20:17+0300
Error	PHP	Cannot declare class GuzzleHttp\Handler\CurlFactory, because the name is already in use at /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php#15		2019-03-21T12:20:17+0300
Error	richdocuments	GuzzleHttp\Exception\ConnectException: cURL error 28: Connection timed out after 5001 milliseconds (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)		2019-03-21T12:20:17+0300

Someone had solved this problem by stating "Solved! it was an expired certificate for the loolwsd server." (https://github.com/nextcloud/server/issues/11278). That's why I wanted to force renew the certs.

Edited by sse450
Added info on my setup.
Link to comment
3 hours ago, CHBMB said:

Use your old ISP and go to whatismyip.com and post the results here, then do the same but using your new ISP.

Old ISP:

Your Public IPv4 is: 176.88.224.xxx

Your IPv6 is: Not Detected

Your Local IP is: 10.10.30.30

 

New ISP:

Your Public IPv4 is: 78.188.71.yyy

Your IPv6 is: Not Detected

Your Local IP is: 10.10.30.30

 

Note: If I use the old ISP but without revising the IP in Cloudflare settings, I get exactly the same errors in NC.

Note2: Related NC docker nginx log entry: 2019/03/21 14:49:35 [error] 314#314: *15995 upstream sent invalid status "0" while reading response header from upstream, client: 172.17.0.1, server: _, request: "GET /index.php/apps/richdocuments/settings/check HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com:443"

Note3: Perhaps, port 80 is blocked by the new ISP. I temporarily forward port 80 to a webpage on the same Unraid. And checked it using some web tools. Not blocked.

Note4: Re-installed LE docker from scratch. Renewed certificates but the problem persists. Frustrated. Kill me.

Edited by sse450
Notes added.
Link to comment

If I may, I am setting up an S3 Compatible (Minio) container and would like to use Letsencrypt to generate the certs. I found another docker online (not Linuxserver) that states:

 

-This image runs certbot under the hood to automate issuance and renewal of letsencrypt certificates.

-Initial certificate requests are run at container first launch, once the image responds on a specified health check url.

-Then certificates validity is checked at 02:00 on every 7th day-of-month from 1 through 31, and certificates are renewed only if expiring in less that 28 days, preventing from being rate limited by letsencrypt.

-Issued certificates are made available in the container's /certs directory which can be mounted on the docker host or as a docker volume to make them available to other applications.

 

So far everything is working great with the Linuxserver container (huge thank you by the way). Am just wondering how the container handles auto renewing the existing certs.

 

Thanks for a great container!

 

-MW

Link to comment
5 hours ago, mfwade said:

If I may, I am setting up an S3 Compatible (Minio) container and would like to use Letsencrypt to generate the certs. I found another docker online (not Linuxserver) that states:

 

-This image runs certbot under the hood to automate issuance and renewal of letsencrypt certificates.

-Initial certificate requests are run at container first launch, once the image responds on a specified health check url.

-Then certificates validity is checked at 02:00 on every 7th day-of-month from 1 through 31, and certificates are renewed only if expiring in less that 28 days, preventing from being rate limited by letsencrypt.

-Issued certificates are made available in the container's /certs directory which can be mounted on the docker host or as a docker volume to make them available to other applications.

 

So far everything is working great with the Linuxserver container (huge thank you by the way). Am just wondering how the container handles auto renewing the existing certs.

 

Thanks for a great container!

 

-MW

I'm just wondering why you read the other image's readme and even quoted it here, but you didn't read our image's readme. All of what you quoted is also in our readme in different words

Link to comment

Please accept my apologies. I missed this section in the readme... 

 

"Certs are checked nightly and if expiration is within 30 days, renewal is attempted. If your cert is about to expire in less than 30 days, check the logs under /config/log/letsencrypt to see why the renewals have been failing. It is recommended to input your e-mail in docker parameters so you receive expiration notices from letsencrypt in those circumstances."

 

Thanks again for all the hard work. It is truly appreciated!

 

-MW

Link to comment
3 minutes ago, mfwade said:

Please accept my apologies. I missed this section in the readme... 

 

"Certs are checked nightly and if expiration is within 30 days, renewal is attempted. If your cert is about to expire in less than 30 days, check the logs under /config/log/letsencrypt to see why the renewals have been failing. It is recommended to input your e-mail in docker parameters so you receive expiration notices from letsencrypt in those circumstances."

 

Thanks again for all the hard work. It is truly appreciated!

 

-MW

No worries. Let us know if we can improve the docs so they are clearer

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.