Cloudflare Access (You do not have permission) - Tunnel Issue

unfor19 · December 26, 2021, 12:27am

I had issues configuring access to resources when using the Location Gateway.

The requirement - private services meant for internal company use, such as CI/CD portal, Monitoring portal, etc., should be protected behind VPN + Auth.

I’ve already configured Cloudflare authentication with Google WorkSpace; Here’s how I did it Cloudflare Teams and Google Workspace Integration.

All my applications are protected with Google Workspace authentication.

I’m using cloudflared in Kubernetes and trying to access my application from my macOS device, which has WARP client installed. My WARP client is authenticated with my Cloudflare team.

Initially, I’ve set my application with the following Policy Rule

warp: Allow > Include > Gateway
IMPORTANT: You must select Gateway in Device Postures before using it

I logged into https://mydomain.cloudflareaccess.com/ from my macOS, and my application appeared in the App Launcher

The application appears only if I’m connected with the WARP client; otherwise, it’s missing. That is the expected behavior (so far)

Though when hitting it or trying to access it, I got to this page:

Forbidden
You do not have permission to view this page

Ray ID: 6c360458xxxxxxxxxx

IP Address: 5.10.x.x

I recognized the IP Address as it’s the one that was added in Locations > Gateway > mygateway after I hit Add IP. It feels like I don’t have permissions somewhere else because everything is set correctly with my Gateway, app Policy Rule, and WARP client …

I’ve added another Policy Rule that Allows traffic from Emails ending with in mydomain.com. So I ended up with two (2) Policy Rules for my application:

private: Allow >
- Include > Gateway
  IMPORTANT: You must select Gateway in Device Postures before using it
- Include > Emails ending with in mydomain.com

NOTE: I’ve tried adding Emails ending with in to the Require block, because I should it should be AND, but seems like it doesn’t work, though putting as an Include statement does the trick.

The application is now accessible only by end-users running a WARP client, which is authenticated with my Cloudflare Team.

Troubleshooting Tip - To make sure that the WARP client is configured correctly, log into the App Launcher mydomain.cloudflareaccess.com, click on Account, and inspect the User identity; If everything is configured correctly, you should see is_warp=true and is_gateway=true.

{
 ...
  "is_warp": true,
  "is_gateway": true,
  ...
}

Thank you, Cloudflare, for making it happen - I’m dropping my AWS NLB because of that

I’d love to hear tips/recommendations/comments, so feel free to share your thoughts.

nuno.diegues · December 27, 2021, 9:51am

Hello @unfor19 ,

I think what’s confusing you is that there are 2 different ways on how to set up some form of “private network” through Cloudflare:

A) you expose an origin to the Internet, via a publicly resolvable domain name (DNS) — which can even be resolving to a Cloudflare Tunnel in case you do not want the origin to be addressable directly, which is a good practice! — and then you protect this with Cloudflare Access by requiring certain authentication to be provided by users to ensure that they can then access the origin; this works for L7 traffic (HTTP(s)/websocket) “natively”, i.e., “just works” from the user perspective, and also works somewhat for L4 traffic (TCP only) but requires users to rely on “cloudflared access” on their client machines, which wraps the traffic in websocket (and thus pretend it to be L7 traffic); both these go through Cloudflare’s traditional L7 stack
Here is an end to end tutorial for this example: https://developers.cloudflare.com/cloudflare-one/tutorials/ssh

B) you expose private origins with Cloudflare Tunnel (with warp-routing config enabled) only to Teams clients enrolled in the same organization (i.e. those running WARP client enrolled into the organization of your account); in this case, traffic will go through Cloudflare’s Secure Web Gateway, where L7 and L4 filtering rules can be applied; this supports L7 and L4 (TCP and UDP) traffic
Here is an end to end tutorial for this example: https://developers.cloudflare.com/cloudflare-one/tutorials/warp-to-tunnel

Based on your post, I have the feeling that you set up things from both A) and B) together, which does not really work, nor it was ever meant to.

unfor19 · December 27, 2021, 10:23am

Thank you very much for the detailed response, I’ll check out both links and see what fits best for my use case

unfor19 · December 27, 2021, 12:25pm

@nuno.diegues I followed the instructions in https://developers.cloudflare.com/cloudflare-one/tutorials/warp-to-tunnel though now I get the same error Access Forbidden; if I add Include Emails Ending In @mydomain.com, I’m able to login to the website.

Is it even possible to expose a private service with a domain name app.mydomain.com only to Cloudflare, and make it accessible only for authenticated WARP clients? Also, I don’t want users to authenticate with web-browser if they use WARP, it’s double authentication, as WARP is already authenticated with Cloudflare so I’m not sure why users are prompted for logging in when they try to access my apps.

Am I missing something? Do you think I should create a support ticket, or should we keep the discussion here?

cscharff · December 27, 2021, 12:36pm

Warp to tunnel doesn’t use web browser authentication. You’ve got an Access policy of some kind in place instead. You should recheck the warp to tunnel tutorial and the DNS resolution for the resource in question to confirm it resolves to the CIDR range you have put in the tunnel and not the IP address of Cloudflare’s edge (which is what it appears to be doing now).

unfor19 · December 27, 2021, 1:46pm

@cscharff @nuno.diegues

Seems like everything is configured properly, at least according to https://help.teams.cloudflare.com/

The only thing I’m wondering about is - why am I prompted for login if I’m using the WARP client. Also, any idea why the Team Name is N/A?

nuno.diegues · December 27, 2021, 2:41pm

When you access private origins from WARP client → Tunnel origins, you should access the private IP of that origin.

Seems like you are accessing a publicly resolvable DNS, and thus not going via the private network.
I’m guessing you set up your Tunnel both for A) and B) — referring to the use cases I mentioned above.

Note that we’ll soon be making available private DNS resolution too via the private network (see https://blog.cloudflare.com/extending-cloudflares-zero-trust-platform-to-support-udp-and-internal-dns/ ).

That’s a known bug that has been reported internally for fixing. It should display your Teams name (as per what you enrolled into in the Teams client).

cscharff · December 28, 2021, 12:49am

It isn’t. If Warp to Tunnel were being used you wouldn’t be prompted / hit with an Access policy.

If you were using Warp to Tunnel it wouldn’t happen. As it stands there is an Access policy in place whose criteria are not being met / the Warp to Tunnel config you think you have isn’t in place / doing anything.

unfor19 · December 28, 2021, 1:04am

@nuno.diegues @cscharff Thank you very much for your help, that was very helpful.

@nuno.diegues Can’t wait to see “private DNS resolution via private network” in action

system · December 31, 2021, 1:05am

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