BUGs: Gateway+WARP can't block by GroupID, GroupName

I have a basic policy to block unsafe categories/content on the network. Latest WARP client installed.

The only way to enforce the block is to use individual email addresses. Trying to use GroupIDs or Group Name results in the policy not being applied (so i can have it applied to multiple users at once without needing to list every one individually).
I copy paste the GroupID from the group screen into Selector= User Group IDs.

In the Gateway logs it says that access was allowed because there was no policy match.

BUG #2
Creating a DNS policy and using user email in the selector results in the selector having limited choices. If you save the policy and then go back into the selector to change it to Group IDs or Group Names - you can’t because those options are now gone (along with some other options).

1 Like

I can confirm these bugs as well. But I believe this might be a limitation of the free edition vs paid?

I’d also like an option to toggle off and on called “Deny/Block all traffic by default”

Right now I have a policy that blocks tcp and udp protocols - which should not be necessary in the context of a firewall.

More likely you logged in with another account or have an incorrect policy type for the group. Try group ID (azure) or SAML group or…

hi @cscharff

I am not in the wrong account - troubleshooting shows my network access attempts in the logs and I am able to manipulate my access by setting up a block action by using the e-mail selector under the network policies in the same session. I also double checked that the WARP client was in gateway mode as well enrolled in the correct organization.

If I setup the same block access policy but using the User Group ID or User Group Names selectors, they do not work with the Cloudflare groups nor our Azure object IDs. And yes, I have checked whether my account is apart of the both groups as well as ensuring Support Group IDs is turned on under the Azure Authentication entry.

I just tested using an Azure Group Object ID in the User Group ID selector value and that doesn’t work either.

Log out of the Teams account. When you log back in ensure you are using the Azure AD signin and not the email address OTP function.

Check your group information against your-team.cloudflareaccess.com in the Account details section when signed in to confirm the group you are a member of is listed.

Use group ID for the policy.

Cloudflare groups are reusable policy objects applicable to Access policies only. They have no impact on / function in Gateway policies today.

I don’t use OTP at all for the WARP client - used the Azure Login button and entered the correct team (we only have one).

I did check the group id both in Azure AD and in the policy. I’ve tested the Azure authentication and it works fine (the test results enumerate all of my Azure AD groups and the specific group object ID that I used in the policy is showing there as well).

But I did notice that on the the Azure AD authentication settings page it talks about enabling the Support groups function (which in turn enables the Azure Groups selector). The Azure Groups selector is only showing in the Cloudflare Groups and Access Policy selectors - but not under any of the three Gateway Policy selectors.

Is it possible that we cannot use Azure Groups in Gateway Policies yet either?

So just an update to this - The WARP client doesn’t fully log out even when using the logout button when using Azure IdP. I must have logged in and out about 10 times in the client before realizing I could see the IdP results under the App Launcher (.cloudflareaccess.com). None of my groups were actually present in the IdP results.

After noticing the missing groups - I used Microsoft Edge to visit portal.office.com and properly logout of the 365/Windows session, then logged out again on the WARP client. After that, I rebooted, and logged back into the team within WARP. After that, the policies with the Azure group IDs worked and were showing properly in the App Launcher Account page.