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

[Picha]

5 hours ago, dcreager said:

My ngnix.conf had the 

include /etc/nginx/conf.d/*.conf;

inside the http block,   I moved it to outside at the beginning and all worked fine

Thanks, this solved the problem

[Outlawtorn]

On 1/23/2023 at 7:36 AM, dcreager said:

My ngnix.conf had the 

include /etc/nginx/conf.d/*.conf;

inside the http block,   I moved it to outside at the beginning and all worked fine

Thanks solved my issues as well!

[Gragorg]

My swag is no longer working nothing on my end was changed and my log is spamming

 

nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3

 

Any help would be great.

[DayspringGaming]

I'm getting the same error as well. So now all of those specific containers that use it are broken.

[vw-kombi]

Strangely, I am not getting any of these issues and I update each time it asks.

I take a deep breath each time, but it alwats starts fine.

I installed swag about 6 months ago using the ibracorp youtube video.

These are up there with spaceinvaders for 'education'.

There must be something in spaceinvaders setup.

Maybe re-create with the ibracorp guide ?

I also added some extra stuff - geoblocking, custom jails etc.

Edited January 25 by vw-kombi

[alturismo]

30 minutes ago, Gragorg said:

Any help would be great.

 

28 minutes ago, DayspringGaming said:

I'm getting the same error as well. So now all of those specific containers that use it are broken.

 

guys, may just look some posts above yours for a solution, in the future, when you may look at your docker logs from swag you will prolly see the messages which files are outdated and should be updated, consider it from time to time then this wouldnt have happened ...

 

and as some of us (including me) do custom stuff in their files we dont want them to be replaced automatically, so yes, a wanted behaviour ...

[alturismo]

18 minutes ago, vw-kombi said:

I installed swag about 6 months ago using the ibracorp youtube video.

 

Just now, alturismo said:

in the future, when you may look at your docker logs from swag you will prolly see the messages which files are outdated and should be updated

 

i think its almost 1 year now when the change was done ...  so you can imagine how often others are checking their logs

 

well, as the solution was pointed few posts above we also see how much time for a lookup was invested  no offense, just wondering from time to time when i lookup and see its standing there ...

[Gragorg]

18 minutes ago, alturismo said:

well, as the solution was pointed few posts above we also see how much time for a lookup was invested  no offense, just wondering from time to time when i lookup and see its standing there ...

I replaced both the ssl.conf and nginx.conf files with the sample ones however I seem to get the same results.  The 3 subdomain.conf files I use I believe only had the server name changed.  Its been a long time so am a bit lost.

[Gragorg]

Ok thanks I didn't realize there was more than the two files to change.  Changed all them in the outdated list and seem to be good.  Thanks

[Soulflyzz]

11 hours ago, Gragorg said:

My swag is no longer working nothing on my end was changed and my log is spamming

 

nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3

 

Any help would be great.

Hello,

 

I am having this same issue and I have found a temp solution.

I went into the condole and deleted that file that was crashing the system. Then rebooted swag.

everything came back online and is working for about 24 hours then that file came back and broke it again.

 

have you or anyone sound a cause or solution to this issue yet?

 

***Before anyone spams me I have found the solution by continued reading in this tread.

Delete if wanted or keep as a reference on please read before you post.

Edited January 25 by Soulflyzz

[shaunvis]

For the life of me I can't get. SWAG and Cloudflare working again.

 

I just set this up this morning and had it working. I had one subdomain, sonarr. And I was and to connect just fine. Then I added another subdomain sonarr,plex and I restarted the container & it fails to get a cert now. I believe when I got it working earlier I had to turn off SSL on  Cloudflare. But that doesn't work now. Nothing works it seems. 

 

I get:

"Certbot failed to authenticate some domains (authenticator: dns-cloudflare). The Certificate Authority reported these problems:"

And:

"

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-cloudflare. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-cloudflare-propagation-seconds (currently 10 seconds).

Some challenges have failed."

 

Any ideas? I"m banging my head against a wall here because I feel like I'm missing something simple

 

[Gragorg]

21 hours ago, Soulflyzz said:

have you or anyone sound a cause or solution to this issue yet?

For me there was a chart in the swag log with all the files that were outdated (around 8 files for me).  I replaced them all with the new sample files.  I was using 3 .conf files that I had to edit to match my old server names from when I set it up.  Do you have a list of out dated files in the log?  You will likely have to restart Swag to see them as my log was spamming an error.

[tvd1]

On 1/22/2023 at 12:32 PM, nraygun said:

Confirming this worked for me too. Not sure I needed to replace both, but I did anyway and Swag and Nextcloud are both back and up and running.

For noobs like me, here's what I did:

1. Stop the Swag container

2. Go to the /mnt/appdata/swag folder

3. Rename your ssl.conf to ssl.conf.old and nginx.conf to nginx.conf.old (just in case we to restore them)

4. Copy ssl.conf.sample to ssl.conf and nginx.conf.sample to nginx.conf

5. Start the container and you should be good.

Thanks for this, i'm back up and running now too.  (though my files were in /mnt/user/appdata/swag/nginx/ )

 

One odd thing, one of my web facing apps continued to work, even though its on the same proxy network as swag. I must have it misconfigured?

[Cpt. Chaz]

On 1/22/2023 at 11:32 AM, nraygun said:

Confirming this worked for me too. Not sure I needed to replace both, but I did anyway and Swag and Nextcloud are both back and up and running.

For noobs like me, here's what I did:

1. Stop the Swag container

2. Go to the /mnt/appdata/swag folder

3. Rename your ssl.conf to ssl.conf.old and nginx.conf to nginx.conf.old (just in case we to restore them)

4. Copy ssl.conf.sample to ssl.conf and nginx.conf.sample to nginx.conf

5. Start the container and you should be good.

 

For anyone experiencing this issue (for noobs, it doesn't matter if you still have this container called letsencrypt, directory structure is still the same), this is exactly the fix for it. Although it's worth pointing out these .conf files are in the nginx sub-folder for this container, so the full path is:

/mnt/user/appdata/swag/nginx

inside this folder, you'll find the nginx.conf and ssl.conf files. if you're using the terminal, use these commands:

mv nginx.conf nginx.conf.bak
mv ssl.conf ssl.conf.bak

Then start the container. Step 4 above is unnecessary, when you start the container it'll generate new/updated .conf files. Thanks to @BigBoyMarky for pointing this out for all of us!

Edited January 30 by Cpt. Chaz
typo

[dehein2]

Hi all,

 

since the last update ( a week ago) a have the issue that swag stops working every night. SO each morning i have to manually restart the container and it works just fine again. I replaced the conf and ssl file as described above after having the same issue.

 

Here's the latest error.log

2023/01/29 15:09:15 [crit] 417#417: *2403 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/29 17:24:29 [crit] 417#417: *3074 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/29 19:08:12 [crit] 417#417: *3552 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/30 01:40:04 [crit] 419#419: *5074 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://192.168.2.200:443/remote.php/dav/files/dehein/", host: "nextcloud.myserver.com"
2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://[1234:1234:1234:1234::5]:443/remote.php/dav/files/dehein/", host: "nextcloud.myserver.com"
2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://192.168.2.200:443/502.html", host: "nextcloud.myserver.com"
2023/01/30 08:51:41 [error] 417#417: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 1245:1234:21:123:402:5123:1234:4123, server: nextcloud.*, request: "PROPFIND /remote.php/dav/files/dehein/ HTTP/1.1", upstream: "https://[1234:1234:1234:1234::5]:443/502.html", host: "nextcloud.myserver.com"
2023/01/30 14:16:07 [crit] 419#419: *1532 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/30 15:28:52 [crit] 420#420: *1932 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/30 19:08:12 [error] 417#417: *2987 vault could not be resolved (3: Host not found), client: 1245:1234:21:123:402:5123:1234:4123, server: vault.*, request: "GET / HTTP/1.1", host: "vault.myserver.com"
2023/01/30 19:08:12 [error] 417#417: *2987 vault could not be resolved (3: Host not found), client: 1245:1234:21:123:402:5123:1234:4123, server: vault.*, request: "GET / HTTP/1.1", host: "vault.myserver.com"
2023/01/30 21:44:36 [crit] 417#417: *3459 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/30 22:08:55 [crit] 420#420: *3561 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443
2023/01/31 09:26:17 [crit] 419#419: *323 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 1245:1234:21:123:402:5123:1234:4123, server: [::]:443

 

Thanks helping

Edited January 31 by dehein2

[akshunj]

On 1/23/2023 at 3:08 PM, Picha said:

Thanks, this solved the problem

confirming same here. Solved the problem for me

[rutherford]

Is this important from the SWAG log?

Quote

/config/nginx/geoip2.conf exists.
        Please migrate to https://github.com/linuxserver/docker-mods/tree/swag-maxmind

 

[alturismo]

37 minutes ago, rutherford said:

Is this important from the SWAG log?

Quote

well, more or less self explaining ...

 

where you using geoblocking ? the "old" version was configured in geoip2.conf which is deprecated, so either you migrate to maxmind or in case you never used it anyway, just wipe the file to get rid of this message.

[flyize]

How do I prevent SWAG from handing out an SSL certificate when someone visits my IP address?

 

If someone views that cert, they can then see the domains its being used for and attempt to access them. I know 'security through obscurity' isn't great, but its at least another step for an attacker to have to take...

 

edit: Answered my own question by adding this to the default.conf for NGINX

 

ssl_reject_handshake on;

 

Edited February 8 by flyize

[Cybernaut]

Hi Folks.  I apologize it this has already been addressed.  I've been searching for a couple hours, and frankly, I haven't read this 238 page thread.

I started receiving emails saying my letsencrypt certs are about to expire.  Delving into it, it looks like the last log I have in the appdata/swag/log/letsencrypt folders is dated 11/23/22 (below).  It looks like the cron job is no longer running?

Appreciate any help.

cronjob running on Wed Nov 23 02:08:00 MST 2022
Running certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/my.domain.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
  /etc/letsencrypt/live/my.domain/fullchain.pem expires on 2023-02-13 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 

[Gragorg]

I am trying to get Swag on my primary server to open containers on my backup server which is in the same subnet. Does anyone have an example of how I would edit conf files to achieve this?  I assume I don’t need to run a second instance of Swag on my backup server?

[JonathanM]

5 hours ago, Gragorg said:

I am trying to get Swag on my primary server to open containers on my backup server which is in the same subnet. Does anyone have an example of how I would edit conf files to achieve this?  I assume I don’t need to run a second instance of Swag on my backup server?

Change proxy_pass https://192.168.XXX.XXX:XXXX; to the address that works to access the container from a desktop on the LAN.

[Gragorg]

16 hours ago, JonathanM said:

Change proxy_pass https://192.168.XXX.XXX:XXXX; to the address that works to access the container from a desktop on the LAN.

Thanks. I’ll give it a try this weekend. 

[Ninoslav]

Any idea why each swag update breaks my remote jellyfin? Out of the 5 files mentioned in the screenshot, only one I edited was jellyfin.subdomain.conf

 

I have 2 servers and both died so I tried this. On the first one I replaced all files with new ones starting from the bottom and it was dead until all 5 were replaced with samples and old ones renamed to old. On the second one I started from the top and as soon as I replaced first two authelia server was back online. On that 2nd server I still have warning about /config/nginx/proxy.conf, /config/nginx/proxy-confs/jellyfin.subdomain.conf and /config/nginx/site-confs/default.conf but jellyfin works just fine.

 

Is there something I need to do so swag update doesnt mess it up each time? 
 

[vurt]

If I have .htpasswd for password protection, is there a way to whitelist a specific url so it can be accessed without password? I want KOReader to browse my ebooks at https://calibre-web.mydomain.net/opds .

Edited February 12 by vurt