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


Recommended Posts

It looks like one of the last updates to SWAG changed the behaviour so that it will only read in nginx/site-confs files if they have .conf in the filename, which broke redirection to my radarr/sonarr subdomains (I was getting the default swag homepage instead).  I looked at an old backup of my SWAG appdata folder and noticed that in the update, it had replaced my previous 'default' file with 'default.conf' and a sample file.  See the log entries below that led me to look into that:

 

**** The following active confs have different version dates than the samples that are shipped. ****
**** This may be due to user customization or an update to the samples. ****
**** You should compare the following files to the samples in the same folder and update them. ****
**** Use the link at the top of the file to view the changelog. ****
/config/nginx/nginx.conf
/config/nginx/ldap-server.conf
/config/nginx/authelia-location.conf
/config/nginx/authelia-server.conf
/config/nginx/ssl.conf
/config/nginx/proxy.conf
/config/nginx/site-confs/default.conf

 

I have a subdomain called "services" that points to my radarr/sonarr sites.  The filename to redirect to those sites was named 'services' with no filetype extension.

 

The fix for me was simple, and just required that I rename that file to 'services.conf' so that it would read the file, and a restart of the docker to pick up the change.

Edited by nsutherland
Link to comment

Ihave this setup, I am using google domains with CNAME's setup there. I can access using my custom hostnames remotely, but when I am connected to the local network things intermittently do not work. Overseer gives a "you are offline" error, radarr and sonarr gives a "site cannot be reached" Acessing locally via IP adress works perfectly, so does connecting via phone with hostnames. However as soon as I connect to local network I can no longer access from that device using the host name.

 

Any ideas where I should start?

Link to comment

i'm getting a wrong certificate when i'm trying to access my cloud (secured with swag/duckdns).

had some problems in the past (duckdns gave back wrong ip address), so i tried to log into duckdns.org:

image.png.957355b885028aab514dcde312caffa0.png

 

am i missing something or is something wrong with duckdns?

Link to comment

I have uninstalled and installed again swag and I found the following error:

 

Requesting a certificate for *.xxx.duckdns.org
Hook '--manual-auth-hook' for xxx.duckdns.org ran with output:
 OKsleeping 60

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
  Domain: xxx.duckdns.org
  Type:   dns
  Detail: DNS problem: SERVFAIL looking up TXT for _acme-challenge.xxx.duckdns.org - the domain's nameservers may be malfunctioning

Hint: The Certificate Authority failed to verify the DNS TXT records created by the --manual-auth-hook. Ensure that this hook is functioning correctly and that it waits a sufficient duration of time for DNS propagation. Refer to "certbot --help manual" and the Certbot User Guide.

ERROR: Cert does not exist! Please see the validation error above. Make sure your DUCKDNSTOKEN is correct.

I have checked the Duckdnstoken several time and it is correct. The duckdns docker is working correctly (checked through duckdns page [IP is correctly checked in duckdns webpage]).

 

Any idea?

 

Thankyou very much

Link to comment

My swag has stopped working since a few days back here. My configs are still located in /nginx/site-confs/default.conf

 

I can see in the default.conf.sample that there is a new comment header:

## Version 2022/10/03 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/nginx/site-confs/default.conf.sample

 

What do I need to know here to get this working again? I am an absolute noob here when it comes to these settings. Swag have been working flawless though for 2 years. Just stopped here a couple of days back and the date in the header here above seems to be when "something new" happened here.

 

Anyone knows and have similar issues?

 

Link to comment

Anybody have a guide on how to get authentik working with swag?  Ive tried using the config files for nginx proxy manager for it to no avail.  I've been using swag for years but Authentik seems to be the new big SSO solution and I dont think it works with swag.  All guides written for it involve either NPM, Traefik or Caddy.  Seems like SWAG is old news now :( ?

Edited by 007craft
  • Like 1
Link to comment
On 10/5/2022 at 1:21 AM, cnorin said:

My swag has stopped working since a few days back here. My configs are still located in /nginx/site-confs/default.conf

 

I can see in the default.conf.sample that there is a new comment header:

## Version 2022/10/03 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/nginx/site-confs/default.conf.sample

 

What do I need to know here to get this working again? I am an absolute noob here when it comes to these settings. Swag have been working flawless though for 2 years. Just stopped here a couple of days back and the date in the header here above seems to be when "something new" happened here.

 

Anyone knows and have similar issues?

 

Make sure that your configuration files such as default.conf, etc all have the .conf extension and all should be good. Recent change.

Link to comment
22 minutes ago, 007craft said:

Anybody have a guide on how to get authentik working with swag?  Ive tried using the config files for nginx proxy manager for it to no avail.  I've been using swag for years but Authentik seems to be the new big SSO solution and I dont think it works with swag.  All guides written for it involve either NPM, Traefik or Caddy.  Seems like SWAG is old news now :( ?

Share your config files and edit out what you don't want shown eg. blah.domain.com

Link to comment

Sure:
 

## Version 2022/09/08
# make sure that your dns has a cname set for navidrome and that your navidrome container is not using a base url

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name music.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

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

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.1.102;
        set $upstream_port 4533;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
		
		    # authentik-specific config
		auth_request        /outpost.goauthentik.io/auth/nginx/;
		error_page          401 = @goauthentik_proxy_signin;
		auth_request_set $auth_cookie $upstream_http_set_cookie;
		add_header Set-Cookie $auth_cookie;
    	auth_request_set $authentik_username $upstream_http_x_authentik_username;
        auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
        auth_request_set $authentik_email $upstream_http_x_authentik_email;
        auth_request_set $authentik_name $upstream_http_x_authentik_name;
        auth_request_set $authentik_uid $upstream_http_x_authentik_uid;
		proxy_set_header X-authentik-username $authentik_username;
        proxy_set_header X-authentik-groups $authentik_groups;
        proxy_set_header X-authentik-email $authentik_email;
        proxy_set_header X-authentik-name $authentik_name;
        proxy_set_header X-authentik-uid $authentik_uid;
		
    }
	
	 location /outpost.goauthentik.io {
        proxy_pass          http://auth.mydomain.com/outpost.goauthentik.io/;
        # ensure the host of this vserver matches your external URL you've configured
        # in authentik
        proxy_set_header    Host $host;
        proxy_set_header    X-Original-URL $scheme://$http_host$request_uri;
        add_header          Set-Cookie $auth_cookie;
        auth_request_set    $auth_cookie $upstream_http_set_cookie;

        # required for POST requests to work
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }

    # Special location for when the /auth endpoint returns a 401,
    # redirect to the /start URL which initiates SSO
    location @goauthentik_proxy_signin {
        internal;
        add_header Set-Cookie $auth_cookie;
        return 302 /outpost.goauthentik.io/start?rd=$request_uri;
        # For domain level, use the below error_page to redirect to your authentik server with the full redirect path
        # return 302 https://auth.mydomain.com/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
    }
}



Checking my Nginx errors log I get:
 

2022/10/09 16:09:10 [error] 315#315: *7 auth request unexpected status: 301 while sending to client, client: 192.168.1.1, server: music.mydomain.com, request: "GET / HTTP/2.0", host: "music.mydomain.com"



...when I try to goto the site.  If I comment out the auth_request line, the config works just fine.  But of course Im trying to get this working WITH authentik.

 

If I actually goto http://auth.mydomain.com/outpost.goauthentik.io  it gives me a page but says

{ "Message": "no app for hostname", "Host": "192.168.1.102:9001", "Detail": "Check the outpost settings and make sure '192.168.1.102:9001' is included." }

So Im not sure if I need to change something in Authentik or in Swag.

Edited by 007craft
Link to comment

My docker image got corrupted and was in read only mode. I deleted it, restarted docker services, and re-installed apps. Deleting the docker image wiped out proxynet, so I created it again and had to go into the applications that used it and re-enable it.

 

Since then, I get the "your connection isn't private" error. I'm using pfsense, and the configuration is fine. It's my domain hosted on cloudflare. What could be the problem?

 

Solved: I decided to delete the app and appdata folder and start from scratch. I copied the content of appdatae elsewhere. With the new installation up, I copied back my proxy.conf files. I added my cloudflare account. Swag restarted and shutdown unexpectedly. On the restart, everything was back up and running.
 

error.png

Edited by Mlatx
Link to comment

Been running my server for about 4 years. Originally with Let's encrypt, then migrated to swag. Swag has been supplying my proxy for Overseerr, Vaultwarden, Guacamole, and Nextcloud for this whole time without issue. Now I can't access anything from outside my network. Everything works fine through http on my network.
I use duckdns and the logs show updates to IP every 5 minutes as usual.
I tried reinstalling swag and noticed a new template is now being used. This was not an issue as it was pretty self explanatory and I input all of the same information that I used previously.
The logs for swag show everything is working properly. Certs are valid, subdomains are loaded correctly, no sign of issue from swag.
My original installation was from Spaceinvaderone's video. With that being a little dated now, I'm not sure if any other configuration is needed other than the proxy-conf files that I configured specific to my containers.
I haven't seen any responses from the linuxserver guys in a while, so I'm wondering if anyone has any insight as to why it's not working? Any help would be appreciated and I'll supply any additional information you may need to troubleshoot.
Thanks in advance.
The unraid community has been awesome and I really think Unraid is a great product.

Typing that just reminded me that I recently updated Unraid to 6.10. Not sure it's related, but definitely a variable to consider.
Thanks again

Sent from my LE2117 using Tapatalk

Link to comment
  • 2 weeks later...

I'm not sure when it happened (somewhat recently though) or what happened but all of my reverse proxy apps that I've setup with swag and duckdns are throwing an SSL cert error of NET::ERR_CERT_AUTHORITY_INVALID (see attached image).  I had this setup and working on Emby and Nextcloud for a long time but recently saw that accessing those resulted in it just using HTTP.

 

I've attached a diagnostics file for review.  The logs for swag look clean and the certs look to be in good standing and not expired.  I'm at a loss at the moment as to where to look next so any help would be greatly appreciated.

ssl.jpg

tower-diagnostics-20221028-1643.zip

Edited by snowborder714
Link to comment

Hello forum.  I want to add the preconfigured proxyconf file 'sonarr.subdomain' to my SWAG manager.  However, when I rename to sonarr.subdomain.conf and reboot, SWAG does not see the conf file in logs..  Am I missing a step??

 

**Forgot to mention that I have SWAG configured using the 'linuxserver/mods:swag-auto-proxy' docker mod.  Can the preconfigured Nginx templates be used while using auto-proxy?

 

Thanks

 

image.thumb.png.46d4d1527d6b63e4c46a69f0ad49342d.png

Edited by cpthook
Link to comment

Hi,

 

Since updating my swag setup (updating the docker container and regenerating config file from samples) I can't use Onlyoffice in Nextcloud.

Documentserver.mydomain.net works, I get the welcome page. On Nextcloud Onlyoffice administration page, everything works too. But when I open a file I get this error :

https://rehost.diberie.com/Picture/Get/f/97332

When investing using Chrome F12 function, here is what I get:

https://rehost.diberie.com/Picture/Get/f/97331

First I thought it was an X Frame option that was causing the problem but removing the header from my nginx conf file didn't solve it. When I inspect the blocked content it doesn't show any "same origin" header so I don't think the problem is from that setting.

https://rehost.diberie.com/Picture/Get/f/97330

 

Here is my documentserver.subdomain.conf file:

## Version 2022/09/08
# Make sure that your dns has a cname set for onlyoffice named "documentserver"
# Make sure that the onlyoffice documentserver container is named "documentserver"

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name documentserver.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

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

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app documentserver;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }
}

 

Can anyone help me? I can provide extra info if needed. Thanks.

Edited by spiderben25
Link to comment

I have a situation I've found several mentions of, but haven't been able to untangle a solution.

 

Have SWAG container running on Unraid and working great. It's using a custom docker network, router forwards public IP to unraid ip port 1443 (which is used by swag container).

 

The issue is when accessing sites through swag internally. Because swag uses unraid's IP but with port 1443, if I use local dns to point the unraid IP, I just get the unraid interface rather than whichever address swag would have sent me. I can of course use local dns to get the desired site by manually specifying the port (i.e. calibre.example.com:1443)

 

I've read about NAT reflection, but it seems like there must be a way to get this working without routing all internal traffic through the router.

 

How can I get my domain pointing to swag internally?

Link to comment
On 10/28/2022 at 5:26 PM, snowborder714 said:

I'm not sure when it happened (somewhat recently though) or what happened but all of my reverse proxy apps that I've setup with swag and duckdns are throwing an SSL cert error of NET::ERR_CERT_AUTHORITY_INVALID (see attached image).  I had this setup and working on Emby and Nextcloud for a long time but recently saw that accessing those resulted in it just using HTTP.

 

I've attached a diagnostics file for review.  The logs for swag look clean and the certs look to be in good standing and not expired.  I'm at a loss at the moment as to where to look next so any help would be greatly appreciated.

ssl.jpg

tower-diagnostics-20221028-1643.zip 188.35 kB · 0 downloads

 

I ended up removing swag and all associating files and just setting it all up again.  It's back to having a working SSL cert and everything resolving via HTTPS.

Link to comment
  • 2 weeks later...

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.