Cloudflare Access (You do not have permission) - IP 172.16.x.x Bug

Randomly started getting “Cloudflare Access” - “You do not have permission” error screens today for any apps that require Cloudflare Gateway. These apps are protected using Cloudflare Access.

What is strange is the IP address on the error page seems to be an internal, private Cloudflare IP address (

For some reason, the IP is being redacted in the image, but it is in-fact or (at least always something in the 172.16.x.x range) which is a RFC 1918 private IP.

1 Like

This isn’t a 403 forbidden due to WAF.
This is Cloudflare Teams, Access & Gateway not working properly when you have a Self-Hosted application that has “require Gateway” as one of it’s conditions.

Yes I do have correct credentials, but I can’t even get to the “sign-in page” anymore due to this error. If you look at the error, you’ll see the IP being reported by Cloudflare is their own internal IP address (from a private IP address block (172.16.x.x)). Usually, this page would show the visitors real public IP address. I’m wondering if a new version of Cloudflare Access was pushed up with a regression.

I said private INTERNAL IP address. 172.16.x.x is part of RFC 1918.

I’m still running into this issue and don’t know how to diagnose.
It seems like trying to access the protected app by disabling Cloudflare Warp, then trying to access the app (getting denied but showing my real IP), then re-enabling Warp, fixes it temporarily.

This is now happening on another computer as well.

Both are running MacOS Monterey, with “cloudflared” version 2021.11.0 and latest Cloudflare Warp client.

Did you enable SXGs in your Cloudflare panel?

no I haven’t, but why would SXGs affect Cloudflare Access ? I’m attempting to use Cloudflare Access to authenticate to access an SSH tunnel that is behind Cloudflare Access.

The only thing that sems to be “fixing” it is

  1. Disconnect Warp/Teams client.
  2. Reload the app page (which results in showing the same error page but shows my REAL public IP address).
  3. Reconnect Warp/Teams client.
  4. Refresh the page that was throwing the error.

If I only disconnect/reconnect the Warp/Teams client, and refresh, it doesn’t work.

EDIT: In the meantime, I’ve removed the “Gateway” requirement off my apps because it has been causing too needing of connect/disconnecting from Warp/Teams. Someone at CloudflareTeams, please fix this bug.

Because I had similar issues in the past, one of them was fixed when I disabled SXGs

WARP/Access is a very young product; I have spent a considerable amount of time dealing with small details that break the product entirely.
From my experience, everything is likely fine on Cloudflare side, but due to the lack of proper error reporting, you end up going around in circles over some details that are not properly configured.

I see.
I think a related issue I am also facing is that I am unable to access the Cloudflare Dashboard ( when connecting via Warp/Teams client.
I have to disconnect Warp, refresh the page, then reconnect to Warp for it to work.
My guess is there is an internal IP routing issue with their VPN or something (related to the 172.16.x.x issue above) when you have been connected to Warp for some extended period of time.

Oh… Yeah, I faced that error as well :sweat_smile: It went away by itself. Sometimes it comes back but incognito fixes it.

When I try to access when connected via Warp+Teams after I’ve been connected for a while, I get this error:

I also cannot connect to Teams apps that have “Gateway required” at the same time and get the 172.16.x.x error above. There seems to be an issue with CloudflareWarp when accessing resources protected by Warp. These issues seem to occur at the same time, which makes me think there is some IP address issue internally on the Warp VPN.


This issue seems to be related to using http3 / QUIC
When visiting Cloudflare sites that have Quic enabled via Cloudflare Warp, their IPs sometimes show as a local 172.16.x.x

The solution / workaround seems to be to disable “Experimental Quic support” in Chrome.
In Chrome, visit chrome://flags/#enable-quic

Similar issues have been reported:

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.