I run a small Docker Swarm setup with Traefik and Authelia for authentication, along with several services such as Immich, HedgeDoc, and others.
I am currently trying to integrate OAuth2 properly with HedgeDoc. My domain auth.example.com points via internal DNS to the Swarm (swarm:443 / swarm:80). However, containers running inside the Swarm cannot simply reach the host IP from within their network. DNS resolution works, but the host does not respond. From what I understand, this is a security feature of Docker itself.
My current workaround is to add an extra_hosts entry to the HedgeDoc Docker Compose configuration:
extra_hosts: - “auth.example.com:10.10.10.10”
I manually determine the Traefik IP beforehand, but that IP changes whenever the Swarm is rebooted because container IP addresses are assigned dynamically. As a result, I would have to update the extra_hosts entry every time i reboot the machine. Assigning static IP addresses does not seem to be supported in this scenario.
I am not sure what the cleanest solution would be to make the OAuth2 callbacks work properly. I have exactly the same issue with Immich.
Paperless was much easier because it simply accepts authentication headers and does not rely on OAuth2 login buttons with redirects.
Directly connecting to authelia:9091 is also not an option, since Authelia itself does not provide HTTPS and rejects anything that does not communicate with it over HTTPS through the reverse proxy.
Does anyone have a solution for this without heavily restructuring the setup or disabling Docker’s default security restrictions?
In your setup incoming traffic should reach Traefik, which then uses a middleware to forward auth to authelia and redirect to the original domain name that should end up in Traefik again.
If the services are exposed to the internet, your internal names won’t work. Then all domain names would need to point to your public ip.
Can you rephrase this please? I miss why this would be relevant information here.
I am not aware of such limitation. What is true though, is that containers can not communicate with containers that don’t share a network with them.
Whenever a swarm task is started, it will create a new container based on the configuration of the swarm service. There is no way to asign fixed ip addresses for swarm tasks or its service vip. You might want to look at the service vip , which potentially could have a static ip (I don’t recall if it does). It is always present, unless the service uses the endpoint_mode: dnsrr. But I have no idea why you would even want to do that…
It turns out that I had previously added iptables rules to prevent containers from reaching services through the host’s own IP address (effectively blocking this kind of loopback/hairpin access). As a result, connections from a Docker Swarm container to its host’s IP were being dropped. I probably added those rules for security reasons, which actually makes sense in hindsight.
That explains why the “outside route” wasn’t working.
Thanks for the reply anyway. Sometimes simply discussing a problem online is enough to point you in the right direction and help you find the solution yourself.