Having issues setting up Access Rules

Zero Trust Access
1

I’ve set up a couple cloudflared tunnels, and I’m starting to dial in the layers of security I want with them, but I’m having trouble getting the results I want. I feel like I’m close, and just need a nudge.

Application #1, Dashy Dashboard dash.example.url:
I want to be allowed to access my dashboard if accessing from my Home IP, I want to be allowed to access Dashy from my mobile device/laptop if I’m connected to WARP for my account.

Application #2, NGINX website, site.example.com:
I want to make this accessible for everyone, but since it’s hosted on my small infrastructure, I would like to have a Cloudflare Challenge, like a Email Pin to prevent lots of traffic. I only expect 5 unique visitors a month, give or take. This one is working, except I would like to allow access to it for testing from my home IP, I keep getting OTP challenges.

My attempts to get these done haven’t been successful so far, and I think it’s self inflicted. For Dashy, it seems that no matter what IP I am using, I get the Cloudflare Email OTP challenge and I can’t seem to wrap my head around the WARP access (maybe that part isn’t doable).

Default Allow rules has my IP address allowed and OTP allowed, like I’ve seen in tutorials, but I can’t see where to select “Bypass” for the IP address, I only have “include”, “exclude”, and “require”. None of these seem to be the settings I’m looking for, and I am not sure where to add WARP client access, if that is even possible. I don’t want to break the NGINX application when I set up the dashboard. Any help figuring out the best way to set this up would be appreciated. I think I’m just missing something small in the documentation. Thanks in advance.

4

Welcome to the Cloudflare Community!

This documentation page is helpful in setting these up:

When you add things to Include, it’s OR between all of them. For example, if you include your IP Address and OTP, it’s saying either match and you get access, except you need to go through some authentication flow to get an identity. If your IP matched, any email would work, regardless if you had an Emails selector as well.

For detecting WARP, you want to use the Gateway Client posture: Using WARP posture checks with Cloudflare Access
(As that guide outlines, you do not want to use the WARP Posture).

Bypass is an action, at the top of the policy

image
image1086×267 10.2 KB

With Tunnels, you want to use Service Auth over Bypass generally.

The actions are very distinct and important to understand:
Allow: allows a user with an identity to access an application. They can match an IP include rule, but they would still have to go through email otp/the configured IdPs you have.

Bypass: Skip the access flow, go back to normal zone/domain security

Service Auth: Still an Access flow, just without an identity.

Tunnels have a security mechanism under each public hostname’s advanced settings => Access to verify the Access JWT (proof you passed through Access), only Allow and Service Auth issue this JWT, and thus Bypass is not recommended.

I believe the easiest way to do this would be two Service Auth Policies, one including your IP, one including Gateway.

You can use an Allow action with Include: Everyone

Let me know if any of that needs more clarification! ZT Policies can be confusing.

1 Like
5

Thank you for the response, it’ll take a minute for me to absorb the details that you included (and I really appreciate those details). I’ll play around with my settings again using your tips, and I’ll come back and let you know if I need anymore clarification for the IP/WARP/Gateway settings. Sometimes you just need to get your terms right, then it’s easier to search for your answers.

As far as the “Allow Everyone” policy, reading into the differences between “Bypass”, “Service Auth” and “Allow”, can I use a Service Auth for Everyone? Then I could have the email challenge for visitors, but not tied to an account identity?

6

Everyone would go straight through to the application without entering their email. Service Auth is no identity, no IdP (identity provider) login (which includes emails). Allow, Include Everyone with Email IdP = everyone enters their email and is allowed in. Allow is always going to put you through an identity flow, although you can configure the exact identity providers, and requirements to pass the policy based on their resolved identity and other factors. Service Auth, Include Everyone = Everyone instantly gets access. Hopefully, that makes sense, there’s nothing you would gain from having an email challenge without an identity if it was possible, other then less users/consumed seats I suppose, but you get 50 on free, which is plenty if you only get 5 unique visitors a month.

Although if it is worth mentioning, it certainly isn’t really meant to be used that way, functionally Access is supposed to be used for employee auth, and each user being an employee/auth’d user. But if you are sure you will have less then 50 unique users a month/not consume all of your seats, then I don’t see anything wrong with it.

I missed it in my first reply, but for your nginx website wanting to skip for your own IP, you’d just want a service auth policy including your own IP, along with the allow.