Cloudflareaccess.com redirect loop

Zero Trust Access
1

Hi,

Issue: While trying to authenticate using the Access feature that is a part of Cloudflare Zero Trust, a redirect loop occurs, resulting in ERR_TOO_MANY_REDIRECTS.

Setup:
Traefik and cloudflared are installed as part of a kubernetes cluster within TrueNAS Scale. Traefik basically acts as a broker for cloudflared. That is, all of my hostname entries point to the same origin service URL, just with different sub-domains:

Internet → Cloudflare → cloudflared client → Traefik → Services

Details:
The problem seems very similar to this post.

Connecting to all of my services externally works fine, the issue only lies with the Access feature. When connecting to a sub-domain that is protected by Access, after logging in at the Cloudflare prompt an infinite redirect loop occurs. I have both the standard OTP option and Google Account OAuth enabled, and the issue occurs when using either.

The following requests can be observed within the Network logging on Chrome after clicking “Sign In”:

  1. https://TEAM_NAME.cloudflareaccess.com/cdn-cgi/access/callback
  2. https://TEAM_NAME.com/cdn-cgi/access/authorized?nonce=…
  3. https://TEAM_NAME.com/index.html?t=1674885157863
  4. https://TEAM_NAME.cloudflareaccess.com/cdn-cgi/access/login/DOMAIN_NAME.com?kid=…

which then loops between 2-4 before eventually failing at an attempt of 2 with HTTP 404.

I tested this feature out after initially setting up my domain with just the OTP option and it worked fine. While I can’t be sure, uncannily enough I think it might be after I added Google Account OAuth like in the linked post (but to be clear it happens when attempting to use either auth method).

Configuration:

  • Traefik set to forward ‘web’ to ‘websecure’ (so I believe http to https)
  • Hostname settings for tunnel are only exposed via HTTPS (443), so the above shouldn’t matter
  • SSL/TLS setting for my domain is set to ‘Full (Strict)’
  • Traefik serves a valid SSL certificate for my domain and its wildcards with Cloudflare as the CA
  • No TLS Verify is enabled for each tunnel hostname as I don’t care about the encryption between cloudflared and Traefik and want to use my own cert so that its valid locally
  • The Cookie Settings for each application that matches each hostname are set as: ‘Strict’, ‘HTTP Only’ , and ‘Enable Binding’ cookie

After authenticating, if I manually get out of the loop by just reentering the original domain into the URL bar and hitting go, I am able to successfully get to the page while authenticated. So the authentication works, its just the redirect back that fails.

Unlike in the other post, changing my team name did not help anything, and clearing ALL cookies on a given client did not either. Though, I didn’t try removing the Google Account OAuth provider before changing my team name like the other poster implied because in the end that’s the main provider I need to use.

Happy to provide more details, but I basically just learned how to setup everything within the past 2-3 weeks so I’m not sure what else is relevant and am pretty stuck.

Have no idea what to make of this.

1 Like
2

Seems like you can’t edit posts (at least I can’t), which is annoying but obviously the first statement is supposed to say “while” not “why”.

Also wanted to add that I have looked through the general tips/docs on solving redirect loops but almost all of them aren’t relevant as they are referring to either having SSL/TLS on the “Flexible” setting, or having HTTPS → HTTP redirects on the origin server, neither of which I’m doing. The others didn’t seem to apply to my situation either.

3

Well, I found a solution: https://community.cloudflare.com/t/redirect-loop-when-using-access-app-launcher/266339/5

After reading through the documentation: https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/#cookie-settings

I still don’t fully understand the implications of changing the SameSite attribute from Strict to Lax, though it seems like it’s mostly ok.

The linked Mozilla documentation notes the following:

image
image807×217 19.1 KB

I’m a complete novice with this so I could be completely wrong, but I imagine this is why the Lax setting is required:

When the redirect is sending you from the cloudflareaccess.com address back to the origin I guess the Cookie that should have been created from logging in is checked for; however, when the SameSite attribute is set to Strict, this cookie is not visible and as such the client is still seen as unauthenticated and so it’s redirected back to cloudflareaccess.com. Then, since the cookie was created by the cloudflareaccess.com domain, when you arrive back at the auth page it can see the cookie it just created, recognizing that the client is already authenticated, and as such simply tries to forward them to the original request at the origin… resulting in the loop.

To summarize, with SameSite set to ‘Strict’:

  1. Client tries to access exampledomain.com
  2. Cloudflare forwards the request to the to exampleteam.cloudflareaccess.com
  3. User authenticates with Access
  4. An authorized session cookie, tied to exampledomain.com, is created.
  5. Cloudflare access then redirects the client back to exampledomain.com
  6. exampledomain.com doesn’t see the cookie that was just created because the client was coming from exampleteam.cloudflareaccess.com, which is not a first-party context (different domain)
  7. Not knowing the client has been authenticated, exampledomain.com redirects the client back to exampleteam.cloudflareaccess.com to login
  8. exampleteam.cloudflareaccess.com sees the existing session cookie, skips authentication, and redirects the client back to the original requested site, exampledomain.com

There is the of course a loop between steps 6 and 8.

To summarize, with SameSite set to ‘Lax’:

  1. Client tries to access exampledomain.com
  2. Cloudflare forwards the request to the to exampleteam.cloudflareaccess.com
  3. User authenticates with Access
  4. An authorized session cookie, tied to exampledomain.com, is created.
  5. Cloudflare access then redirects the client back to exampledomain.com
  6. exampledomain.com can see the session cookie because although it was created on exampleteam.cloudflareaccess.com, the client is navigating to the origin site, and thus the cookie is sent
  7. The origin site knows the user is authenticated and the page loads

I would appreciate if someone could comment on whether or not my understanding of this is correct.

Additionally, you would think this is something that would be more blatantly noted in the Cloudflare documentation; that you are able to essentially brick access to your origin using a setting that is within Access itself. It does state:

When not to use SameSite

Do not enable SameSite restrictions if you have additional sites or applications that rely on a specific application’s authorization cookie.

Though I don’t think this is referring to this scenario, or if it is then IMO it’s misleading. It sounds like it matters for some external factor (i.e. how you’re own application is setup) and doesn’t affect first-party cloudflare services. In other words, I wouldn’t have assumed that this statement applies to Access itself, though again I am new to this.

I’d figure there should be a warning/note block somewhere on that page that states you can’t have the SameSite attribute set to “Strict” if you’re using Access, unless there’s some other way to do it (maybe with CORS?), in which case it should note that.

Since the interactions between your domain and cloudflareaccess.com are both handled by Cloudflare when using the tunnel, and therefore don’t actually involve the origin server at all (since the domain is proxied to the tunnel), I would have initially assumed something like this wouldn’t be possible and would be seamlessly handled by Cloudflare. I do understand though that Cloudflare can’t change fundamental HTTP security factors. Obviously exampledomain.com and exampleteam.cloudflareaccess.com are different domains, even if their interactions are handled by the same entity.

1 Like
4

Thank you so much for this post, and your analysis. We were having the same issue, and I don’t think using Lax would have occurred to me.

1 Like