Swag and Authelia integration issues

Hi,

I’ve been running Swag in conjunction with Authelia for quite a while with no major issues. However, I recently bought a new Synology NAS so needed to shuffle my configuration across and in doing so i’ve hit some issues.

I initially had problems with Authelia because of a bug where it would try to upgrade the schema used by the MySQL back-end database. I ultimately got around this by replacing the MySQL Container with a PostgreSQL instance instead and since then i’ve been managed to at least hit the Authelia endpoint directly with no issues.

The problem I face now is that in cases where I include the code in my site-conf file for Authelia the site no longer works. Trying to access the site causes a 500 message to be shown and the following error appears in the log file for SWAG:

2023/05/31 21:16:42 [error] 262#262: *565 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: sonarr.*, request: "GET / HTTP/1.1", subrequest: "/authelia/api/verify", host: "sonarr.mydomain.duckdns.org"

The Swag container and the Authelia container are both on the main Synology network and when comparing the setup it looks identical to what I had on the old box and that worked fine.

Anyone got any clues on how to troubleshoot and fix this please? I’m a bit confused as to where the IP of 192.168.1.1 comes from in respect to the client mentioned in the error.

I created a new docker network called authelia_net and recreated the authelia and swag containers so they were both bound to this network. Same issue still unfortunately.

Also tried running both containers with higher priviledges but still get a 500 error thrown when I try to access any server which has the authelia configuration in place.

Did you deploy/create the containers using the Synology UI? If yes, that could be three cause. We support and recommend using docker run or docker compose. Oof you used these, please share the snippet, the proxy conf, and the output of docker exec -it swag ping authelia

Hi,

I did originally just use the Docker interface on the Synology, but I then installed Portainer and when I compared the config I noticed my original NAS was using stacks which meant the images must have been deployed into Docker either use the CLI or (more likely) via Portainer.

I’ve therefore updated my configuration so that Authelia is deployed via Portainer. The spec is shown below.

version: "3.5"

services:
  authelia:
    image: authelia/authelia:4.37.2
    network_mode: "bridge"
    container_name: authelia
    ports:
      - "9091:9091"
    volumes:
      - "/volume1/docker/authelia:/config"
    restart: always
    ```

And sure enough the docker command fails to ping the host by name, so something is amiss:

ash-4.4# docker exec -it swag ping authelia
ping: bad address ‘authelia’


There are some additional environment variables which I added into the Authelia container via the Synology UI, so I think when I get back I need to put those into the above spec.  I also will remove the SWAG container and try to deploy that using Portainer to see if that helps at all, but if you have any more ideas in the meantime then please let me know.

My ability to troubleshoot might be a bit limited over the coming week or so as i'm away from home, but i'm super keen to get this sorted.  For the time being i've just disabled Authelia and the route into SWAG from the outside world, but it would be useful to have it back in place for remote access to some of my home setup.

Portainer and Synology UI have the same issues. I stated explicitly what we support

You are not putting them in a shared custom bridge. If you do it the way we support it will work. If you choose to do what you’re doing, I suggest thoroughly reading the portainer documentation

Thanks for the help. I’m happy to use whatever method of depoyment - just so long as it works. My confusion is largely because i’m pretty sure my previous deployment was done via Portainer so I was hopeful it might work on the new NAS. But, with that said, it’s a different version of DSM so that could also come into play.

Portainer itself had to be put in place with a docker command so i’m familiar with how to do it. Is there any chance I could please ask for some guidance - is there some documentation or a guide which might help get me on the right lines?

Grateful for any help you can link to or offer.

Our readme for every container tells you how to deploy with docker run or with docker compose along with what the meaning of each var is to let you set it properly. Authelia isn’t ours, but if you put swag and authelia in the same docker compose, they will naturally share a custom bridge which allows them to communicate directly within the docker bridge rather than double natting.

this is outdated , but i suggest giving this a read
https://www.linuxserver.io/blog/2020-08-26-setting-up-authelia

Thanks driz.

I’m back from holiday now and updated my deployment to use a docker-compose file. Having done this it looks like the authelia container can be resolved as I now get this response:

ash-4.4# docker exec -it swag ping authelia
PING authelia (172.20.0.2): 56 data bytes
64 bytes from 172.20.0.2: seq=0 ttl=64 time=0.105 ms
64 bytes from 172.20.0.2: seq=1 ttl=64 time=0.123 ms

However, when I try to re-enable the Authelia cofiguration in my site-confs I find that visting the site throws a 500 error and the following in the error.log file:

2023/06/11 12:02:23 [error] 463#463: *26 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: radarr.*, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "radarr.mydomain.duckdns.org"
2023/06/11 12:02:23 [error] 463#463: *26 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: radarr.*, request: "GET / HTTP/2.0", host: "radarr.mydomain.duckdns.org"

I’m not quite sure where the client IP of 192.168.1.1 is coming from; that’s the default gateway for my network. If you have any suggestions on where the issue might be then i’d appreciate some help.

Here are all the causes of a 502

in your case, since you can ping by name but you can’t resolve properly still, I would check the resolver item first, but check all of them either way.