Have taken a into this as we’ve been seeing the same issue, in our case we are using -
- Cloudflare Zero Trust (using 2x for failover/load balance)
- Traefik (using 2x for failover/load balance)
- gsad on Docker
The issue for us was that we could sometimes login, get a few pages and then we’d get logged out in a way that is consistent with the various descriptions -
- on this thread
- Token missing or bad. Please login again. · Issue #2973 · greenbone/gsa · GitHub
- Azure Application Gateway, unable to logon · Issue #73 · greenbone/gsad · GitHub
The description on the Azure ticket (73) describes a solution that involves adding the X-Real-IP
header but does not explain why this works.
A hint for us came when we noticed different source (internal) ip-addresses logged when users authenticated - it appears the gsad session is bound with the observed client IP address and when you have a load-balancer in front of gsad
the internal client-address that connects can change which in turn then invalidates the auth session token.
Have taken a look through the gsad code but do not know the code well enough to be able to pinpoint and confirm this - but empirically setting the X-Real-IP address in our setup does indeed resolve the issue.
Several things we tried -
- We tried setting the
X-Real-IP
using a Cloudflare transform rule - does not work out because CF treat this header as protected - We tried using Traefik header manipulation rules - does not work out because Traefik does not do dynamic rewrites
We ended up using a Traefik plugin to rewrite the X-Real-IP
header using the CF-Connecting-IP
header as the input value - this is similar to writing an Nginx rule or applying an upstream load-balancer rule that assigns a X-Real-IP
that does not jump around.
Happy days.