Serious Discussion Evaluation of Cloudflare Zero Trust Free plan after using it for 3,5 months

[LinuxFan58]

I was inspired to use Cloudflare Free plan due to the positive posts of @SeriousHoax @rashmi and @Marko :). I am using the free plan (no credit card info needed).

We had an discussion about the user friendliness of ZT, which I am not going to repeat. The UI has so many options, that you need to find your way for just using the Zero Trust DNS firewall policies. When you found the setting in the user interface it is really easy to create policies. I created policies based on security categories. content categories, domains and resolved IP continent and resolved IP location (click on the picture below) which you can define using AND plus OR logic with drop down menu's to select categories and (list) values.

What I really like about Cloudflare that you can use your own block screen and add a policy specific sentence, so you exactly which policy caused the block (of course you can also check the logs in the ZT console, but I like this feature, see picture for explanation how easy it is to add a policy specific sentence to the block page)

I went all out and specified 10 policies. As a precaution I had set Allow exceptions for critical services (work and home banking related). The order determines the precedence, so policy number 8 takes precedence over policy number 9 and 10. This is handy, because in policy 10 I block resolved IP country geo locations except Europe and 5 Eyes countries, but in 8 I have blocked Belarus and Russian Federation (both on TLD and resolved IP address geo location).

After playing around for 3,5 months I am only seeing blocks from policy number 4 (known bad) and 7 (newly seen) and occasionally from 5 and 8 (only when playing with links from OpenPhish and URL hause).

The benefit of Cloudflare is IMO the option to block on resolved IP address GEO continent and country. This allows to block additional content categories (like file and photo sharing content categories) which I have not yet encountered a block or false positive.

Picture of policy using resolved IP location continent and country, allowing Europe (not selected in continent list) and 5 Eyes Countries (added AND not in Country Codes of US, CA, UK, AU, NZ)

Picture of policy using regexpattern (blocking CRINK countries and TLD's with punycode in it (and also CRINK country code TLD's)

I know rule 8 (partly), 9 and 10 are only effective when the bad-guys don't use a Content Delivery Network with server hubs in the whitelisted resolved IP geo locations.

According to latest data nearly 80% of the "advanced" attacks from well known adversaries use trusted services (bypassing rules 9 and 10). Reversely 80% of the unsophisticated attacks are delivered locally (that is why rule 8 often trigger block screens when playing with URLhaus links).

I used ChatGPT and Leo AI to help me construct the policies and check whether I did not make logic makes mistakes. I also asked AI whether rules 8, 9 and 10 made any sense and AI confirmed that those rules did not protect in absolute manner, but shaved of attack surface which did not hurt in any way (because it is processed on DNS servers and does not cause FP's).

It is also possible to add adblock filters using @SeriousHoax Github automation.

 

[Bot]

I was inspired to use Cloudflare Free plan due to the positive posts of @SeriousHoax @rashmi and @Marko :). I am using the free plan (no credit card info needed).

We had an discussion about the user friendliness of ZT, which I am not going to repeat. The UI has so many options, that you need to find your way for just using the Zero Trust DNS firewall policies. When you found the setting in the user interface it is really easy to create policies. I created policies based on security categories. content categories, domains and resolved IP continent and resolved IP location (click on the picture below) which you can define using AND plus OR logic with drop down menu's to select categories and (list) values.

View attachment 297130

What I really like about Cloudflare that you can use your own block screen and add a policy specific sentence, so you exactly which policy caused the block (of course you can also check the logs in the ZT console, but I like this feature, see picture for explanation how easy it is to add a policy specific sentence to the block page)
View attachment 297131

I went all out and specified 10 policies. As a precaution I had set Allow exceptions for critical services (work and home banking related). The order determines the precedence, so policy number 8 takes precedence over policy number 9 and 10. This is handy, because in policy 10 I block resolved IP country geo locations except Europe and 5 Eyes countries, but in 8 I have blocked Belarus and Russian Federation (both on TLD and resolved IP address geo location).
View attachment 297132
After playing around for 3,5 months I am only seeing blocks from policy number 4 (known bad) and 7 (newly seen) and occasionally from 5 and 8 (only when playing with links from OpenPhish and URL hause).

The benefit of Cloudflare is IMO the option to block on resolved IP address GEO continent and country. This allows to block additional content categories (like file and photo sharing content categories) which I have not yet encountered a block or false positive.

Picture of policy using resolved IP location continent and country, allowing Europe (not selected in continent list) and 5 Eyes Countries (added AND not in Country Codes of US, CA, UK, AU, NZ)
View attachment 297133
Picture of policy using regexpattern (blocking CRINK countries and TLD's with punycode in it (and also CRINK country code TLD's)
View attachment 297134

I know rule 8 (partly), 9 and 10 are only effective when the bad-guys don't use a Content Delivery Network with server hubs in the whitelisted resolved IP geo locations.

According to latest data nearly 80% of the "advanced" attacks from well known adversaries use trusted services (bypassing rules 9 and 10). Reversely 80% of the unsophisticated attacks are delivered locally (that is why rule 8 often trigger block screens when playing with URLhaus links).

I used ChatGPT and Leo AI to help me construct the policies and check whether I did not make logic makes mistakes. I also asked AI whether rules 8, 9 and 10 made any sense and AI confirmed that those rules did not protect in absolute manner, but shaved of attack surface which did not hurt in any way (because it is processed on DNS servers and does not cause FP's).

It is also possible to add adblock filters using @SeriousHoax Github automation.

Cloudflare Zero Trust DNS policies can definitely reduce exposure on the free plan, but I would be careful not to overstate what those geo/IP-based rules can do.

What makes sense here

• Blocking by security categories, content categories, and known domains is practical and easy to justify.
• Using policy logic with AND/OR conditions can be effective once the UI is understood.
• On the DNS layer, these controls are relatively low overhead, so they usually do not create the same kind of system impact as endpoint tools.

Where caution is needed

Rules based on resolved IP continent or resolved IP location are more of a coarse filtering layer than a strong security control.

• CDNs, reverse proxies, cloud hosting, and anycast can make IP geolocation unreliable as a signal.
• Threat actors can host on trusted infrastructure or compromise legitimate services.
• A domain may resolve differently over time, so geo-based decisions can be inconsistent.
• DNS filtering only affects name resolution. It does not inspect the actual content, payload, or behavior after connection.

So the general idea that such rules may shave off some attack surface is reasonable, but they should be treated as a minor supplemental layer, not a meaningful primary defense.

About false positives

I would not say they “do not cause FPs” in an absolute sense.

• Geo/IP-based DNS policies can block legitimate services that use infrastructure outside your expected regions.
• Some SaaS platforms, CDNs, update servers, and regional endpoints may resolve to locations you did not intend to restrict.
• The risk may be acceptable in a hardened setup, but it is still a false-positive risk.

A more precise way to phrase it would be that DNS-side filtering is generally lightweight, while false positives depend on how aggressive the policy conditions are.

Practical takeaway

Your approach is sensible if it is framed like this:

• Use security-category and domain-based rules as the main DNS filtering layer.
• Treat continent/location-based rules as optional hardening.
• Expect bypasses through trusted services, CDNs, and major cloud platforms.
• Validate blocked events over time so you can see whether the geo rules provide useful signal or just extra noise.

About the adblock part

If someone wants to add third-party filter lists or GitHub-based automation, that can be useful, but it is worth remembering:

• List quality matters more than list quantity.
• Aggressive filters can break sites or services.
• Community-maintained lists can change over time, so periodic review is important.

Conclusion

Cloudflare Zero Trust Free is a solid option for DNS-layer hardening, especially for category and domain-based controls. The geo/IP rules are not useless, but they are best viewed as limited hardening with some bypass and false-positive potential, not as a strong standalone security layer.

 

[LinuxFan58]

Rules based on resolved IP continent or resolved IP location are more of a coarse filtering layer than a strong security control.

• CDNs, reverse proxies, cloud hosting, and anycast can make IP geolocation unreliable as a signal.
• Threat actors can host on trusted infrastructure or compromise legitimate services.
• A domain may resolve differently over time, so geo-based decisions can be inconsistent.
• DNS filtering only affects name resolution. It does not inspect the actual content, payload, or behavior after connection.

So the general idea that such rules may shave off some attack surface is reasonable, but they should be treated as a minor supplemental layer, not a meaningful primary defense.

That is what I posted (see below). It is also the reason they are mentioned last with lowest priority as rule 9 and 10. What @Bot i(question 1) is the use of parroting it again as a warning, see below?

I know rule 8 (partly), 9 and 10 are only effective when the bad-guys don't use a Content Delivery Network with server hubs in the whitelisted resolved IP geo locations.

I also asked AI whether rules 8, 9 and 10 made any sense and AI confirmed that those rules did not protect in absolute manner, but shaved of attack surface which did not hurt in any way (because it is processed on DNS servers and does not cause FP's).

Also you (@Bot) seem to forget (question2) that I am not likely targeted by advanced attacks (of which 80% use trusted services to hide in plain sight). I am likely targetted by low sohisticated scams and fraud phishing attempts of which 80% does not use trusted services (simply because targeted consumers don't notice and it costs them to much money in regard to the money they earn per scam or fraud).

Edit about the FP's, I should mention that we use a free VPN on phones and tablet while on holiday, so NO FP's should BE practically no FP's

 

[Bot]

That is what I posted (see below). It is also the reason they are mentioned last with lowest priority as rule 9 and 10. What @Bot i(question 1) is the use of parroting it again as a warning, see below?

I understand your point.

If your post already made it clear that rules 8, 9, and 10 are lower-priority, limited-value hardening rules, then repeating the same limitation as a warning does not add much.

What the useful distinction would be

Instead of restating your caveat, the more useful addition would have been to refine it a bit:

• Those rules are not pointless, but their value is situational.
• They are better seen as exposure reduction than true threat detection.
• Their real-world usefulness depends heavily on the type of traffic, the region, and how often legitimate services use foreign or CDN-backed infrastructure.
• They may still create false positives in some setups, even if the DNS-layer overhead is negligible.

So, to answer your question directly

If the limitation was already clearly acknowledged in your post, then repeating it mainly serves as emphasis or clarification for other readers, not as a correction of your reasoning.

That means the warning itself was not really necessary for you, because you had already framed those rules cautiously.

Bottom line

Your original description already showed the right level of caution. The only worthwhile follow-up would be adding nuance about possible false positives and the limited, context-dependent value of geo/IP-based DNS rules.

 

[Marko :)]

Cloudflare Zero Trust is awesome! I'm on free plan that requires card and I primarily use it for ad blocking and blocking malicious websites. What I'm not fan is the way it is designed (primarily targeted for business users and the dashboard isn't average user friendly); it's worth to mention it surpasses NextDNS, Control D and similar services in some areas.

The biggest con: there isn't a functionality that would let you simply import blocklists so you have to use GitHub to send blocklist through API to your account. While it is one-time thing, it's fairly complicated to set up for an average user. After that, the only thing left is to copy your DoH/DoT domain and start using it on your devices.

At one point, I did have an issue where it stopped filtering and cleared DNS logs from the dashboard once, but it happened only once and never again. Sometimes this still boggles my mind, however, considering filtering never stopped again, I bet it was Rethink DNS app I was using at that time simply misbehaving and suddenly starting to resolve DNS requests by using reserve, hard-coded DNS servers. I'm using AdGuard app as my DNS client and everything works exceptionally well.

Regarding cleaned DNS logs, it was something on their side (as they were transitioning from old dashboard to a new one) and I got confirmation from other forum members they had the same issue. After hearing this, I'm 100% convinced that was separate issue not connected to the one already mentioned.

Another thing I'd like to point out is relatively bad and almost non-existent support for free users. There used to be a simple way of contacting Cloudflare support agents if something isn't right; with every update to the dashboard it's getting more and more difficult to contact them. In fact, lately, if you need any help, you're sent to Cloudflare Community forum where you might (or as in most times) you won't find/get an answer.

 

[SeriousHoax]

Good to hear your positive experience and it's the same for me. Luckily I didn't face any hiccup like @Marko :) as everything has been smooth for me. Though query logging is not the best, we're already getting a lot for free.

Regarding your source country, continent rule, as we discussed before your idea about it is not correct. Here source IP means your own IP aka the client IP. Here the client is you. The source IP from which your DNS is queried. So adding it to your rule is not doing anything.
I think this rule is present for business users who for example, have set static IPs for a specific employee devices and they create specific rules for those source IPs/client only. Like, let's say the manager's PC will be able to access a certain company server while everybody else will be denied.

So for your case, the resolved IP-related rules should be all you need.
Here's an example. My PC send a DNS query for the ESET AV update server. Here the source IP is my public IPv4 address, country code is BD as you can see. While resolved IP is a IPv6 address for the ESET server with country code SK (Slovakia) as ESET is a Slovakian company.

So if I want to block anything from Slovakia then I need a resolved IP/Country/continent policy, not source as the source is already my PC. Having source IP/Country in the policy is not going to do anything. In fact using "And" separator incorrectly means the rule won't work at all. Since you're from the Netherlands, your source IP is a Dutch IP, not anything else. So your content category policy at the moment is basically useless which is probably the main reason why you haven't had a false positive yet.

 

[LinuxFan58]

@SeriousHoax

Where do you see source, I use resolved in all policies resolved?

I see I had made a mistake (cutting pasting in the first post) , this is the policy I actually am using (both resolved continent and resolved country)
I just check to be certain.

 

[SeriousHoax]

@SeriousHoax

Where do you see source, I use resolved in all policies resolved?
View attachment 297146

I see I had made a mistake (cutting pasting in the first post) , this is the policy I actually am using (both resolved continent and resolved country)
I just check to be certain.
View attachment 297145

Okay, it looks fine now