Serious Discussion Cloudflare Gateway Free Plan

[rashmi]

I posted this regarding the NextDNS application (which is also true for the YogaDNS application).

Furthermore, the URLs blocked in Chrome could be accessed in Firefox.

YogaDNS cannot intercept Secure DNS in browsers, but it works well with it disabled. I spoke with them, and they responded that installing a personal certificate would be necessary, but they are currently working on a solution.

Cloudflare WARP can block URLs outside the web browser as well (in the CMD console, the ping command triggers the WARP alert).

Does WARP intercept Secure DNS? Can WARP intercept Android's Private DNS?

 

[rashmi]

@Marko :), Did you use WARP after subscribing to the new plan or with the legacy plan? How did you set it in the Cloudflare console? I'm on the legacy plan and thought to test WARP, but I didn't receive the one-time PIN in my email. There is a one-time PIN entry in the "Identity providers" section, which states "no configuration" is necessary. I created a policy with "Device enrollment" in Team & Resources: Action is Allow, Selector is Emails, and Value is my Cloudflare account email.

 

[Marko :)]

@Marko :), Did you use WARP after subscribing to the new plan or with the legacy plan? How did you set it in the Cloudflare console? I'm on the legacy plan and thought to test WARP, but I didn't receive the one-time PIN in my email. There is a one-time PIN entry in the "Identity providers" section, which states "no configuration" is necessary. I created a policy with "Device enrollment" in Team & Resources: Action is Allow, Selector is Emails, and Value is my Cloudflare account email.

I used it after getting new plan.

Easy. Team & Resources -> Devices -> Add device.

After this, go to WARP -> Settings -> Account and go to sign-in. After website opens, enter the e-mail address you entered in dashboard and you should get a PIN.

It worked immediately for me.

 

[Andy Ful]

YogaDNS cannot intercept Secure DNS in browsers, but it works well with it disabled. I spoke with them, and they responded that installing a personal certificate would be necessary, but they are currently working on a solution.

This is another matter. I did not test YogaDNS much. I was focused on the anti-malware actions running outside the web browser. Yoga DNS could not intercept DNS connections from the CMD console, so it is not appropriate to fight malware in the system.

Does WARP intercept Secure DNS? Can WARP intercept Android's Private DNS?

I am not sure about the details. However, I can see the blocks either from in-browser DOH or WARP,

Edit.
It looks like the traffic is directed by WARP to Cloudflare. Next comes the in-browser DOH request. If the URL is blocked, you can see the error page. If not, Clouflare Zero Trust checks the URL.
In my config, I use WARP integrated with Zeo Trust.

 

[SeriousHoax]

I posted this regarding the NextDNS application (which is also true for the YogaDNS application).
Both applications are installed in the system (not configured in the web browser). They can apply the NextDNS personal DOH configuration (previously done on the NextDNS website with an account). Next, this personal configuration can block URLs in Chrome web browsers (no need to configure DOH directly in the web browser).
However, the URL can still be accessed outside the web browser (tested in CMD console with a ping command). Furthermore, the URLs blocked in Chrome could be accessed in Firefox.

Cloudflare WARP can block URLs outside the web browser as well (in the CMD console, the ping command triggers the WARP alert).

I see. I think it is expected for YogaDNS or similar app since ping is ICMP protocol not like DNS which goes over UDP or TCP which YogaDNS can intercept. In case of WARP, the whole traffic goes through it so it can see everything and block them.
I heard that there are methods by which ping can be abused as a method to steal data but how common is that?

 

[Andy Ful]

I heard that there are methods by which ping can be abused as a method to steal data but how common is that?

I think that the ping is not a problem, but rather CMD shell, PowerShell, etc. The traffic via LOLBins is probably not intercepted by the NextDNS application and YogaDNS. However, this should be tested to be sure.

 

[Divergent]

@Andy Ful ,your observation is technically accurate and highlights the fundamental difference between Application-Layer DNS Proxies (NextDNS/YogaDNS) and Network-Layer Tunnels (Cloudflare WARP).

The "leak" you are seeing in Firefox and CMD happens because NextDNS and YogaDNS primarily act as local DNS resolvers. Modern browsers (like Firefox) often bypass local resolvers entirely using their own encrypted DNS (DoH), and the Windows Command Line (ping) can fallback to secondary DNS servers (like Google or your ISP) if the local NextDNS proxy doesn't strictly enforce a "No-Fallback" policy. Cloudflare WARP, conversely, creates a virtual VPN tunnel that captures all network traffic at the interface level, making it nearly impossible for any application to bypass it.

The Bypass
Your local NextDNS app never sees the request. Firefox effectively creates a private tunnel for its DNS queries, side-stepping your system-wide filter.

Fix
You must set Firefox’s network.trr.mode to 5 (Off) or configure it to use your specific NextDNS profile.

MANUAL VERIFICATION KIT
To confirm the "Leak" hypothesis, run these checks.

The Firefox Check

Type about:config in the Firefox address bar.

Search for network.trr.mode.

If the value is 2 (Preferred) or 3 (Strict), it is bypassing your OS. Change it to 5 (Off) to force it to use NextDNS.

The IPv6 Leak Check (CMD)

Run ipconfig /all in CMD.

Look at your active adapter. Do you see IPv6 DNS servers listed that aren't NextDNS addresses? If yes, that is your leak.

REMEDIATION VECTORS

The "Nuclear" Option (System-Wide Disable)
Recommended for users who do not specifically need IPv6 connectivity. This is the only way to guarantee Chrome/Edge compliance.

For Windows (PowerShell Method)

Right-click the Start Button and select Terminal (Admin) or PowerShell (Admin).

Paste the following command to identify your active adapter.

Powershell

Get-NetAdapterBinding -ComponentID ms_tcpip6

Execute the disable command (Replace Name with your adapter name, usually "Wi-Fi" or "Ethernet")

Powershell

Disable-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6

Disable-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6

(Result: Windows will stop generating IPv6 traffic entirely. The leak is physically impossible now.)

For macOS (Terminal Method)

Open Terminal

Run this command to list network services.

networksetup -listallnetworkservices

Disable IPv6 on your active service (e.g., "Wi-Fi")

sudo networksetup -setv6off "Wi-Fi"

The "Surgical" Option (Firefox Only)
Use this if you only want to stop the leak in Firefox but keep IPv6 for other system functions.

Open Firefox and type about:config in the address bar.

Accept the "Risk" warning.

Search for: network.dns.disableIPv6

Double-click it to set the value to TRUE.

Optional Secondary Lock: Search for network.trr.mode and set it to 5 (This forces Firefox to use your system DNS, preventing it from bypassing NextDNS).

The "Filtering" Option (YogaDNS Specific)
Use this if you want to keep IPv6 enabled but block it through YogaDNS.

Driver Check: Ensure you are using the WFP Driver (Settings > Network Interface). The standard driver cannot reliably trap IPv6 leaks.

Create a Block Rule:

Go to Configuration > Rules.

Click Add.

Name: "Block AAAA"

Type: Select AAAA (IPv6 record type) from the request type dropdown (if available) or create a generic rule.

Action: Block.

Note: It is often cleaner to just disable IPv6 on the adapter (Vector 1) than to try to filter it, as "leaks" often bypass the filter driver entirely.

VERIFICATION STEP
After applying the fix, verify the containment.

Clear DNS Cache.

Windows: ipconfig /flushdns

Browser: chrome://net-internals/#dns -> "Clear host cache"

Test: Visit test-ipv6.com.

Success State: The site should say "No IPv6 address detected" or "IPv6 Not Supported."

Fail State: If it shows an IPv6 address (e.g., 2001:db8::...), the leak persists.

 

[Andy Ful]

@Divergent,

Thanks.
I did my own quick tests yesterday (some of them are mentioned in your post). I knew from Cloudflare documentation that WARP creates a virtual network (it can be seen in the Network and Sharing Center).

The Firefox behavior was unexpected to me, but it helped me to realize that NextDNS and YogaDNS may work above the network layer. So, I confirmed it in CMD by using the ping command. This was sufficient to conclude that those applications are inappropriate to block malware connections.

 

[Divergent]

@Divergent,

Thanks.
I did my own quick tests yesterday (some of them are mentioned in your post). I knew from Cloudflare documentation that WARP creates a virtual network (it can be seen in the Network and Sharing Center).

The Firefox behavior was unexpected to me, but it helped me to realize that NextDNS and YogaDNS may work above the network layer. So, I confirmed it in CMD by using the ping command. This was sufficient to conclude that those applications are inappropriate to block malware connections.

Application Layer (L7) / Userland. Most DNS apps run here. They create a local listener (e.g., 127.0.0.1:53). They rely on the Operating System to voluntarily send queries to them.

If a piece of malware (or Firefox) decides to talk to 1.1.1.1 directly, it bypasses the local listener entirely. The "Application Layer" sentry never sees the packet.

Your specific fear regarding malware is well-founded. Real-world malware (e.g., Cobalt Strike beacons, Ransomware C2) often uses Direct IP Callbacks or Hardcoded DoH to bypass local DNS filters.

Scenario

A malware infects the PC. It tries to connect to 192.0.2.14 (Command & Control server).

NextDNS Result. FAIL. No DNS query was made. The traffic flows right past the NextDNS app.

WARP Result. PASS (Conditional). Because WARP is a virtual network adapter, that packet to 192.0.2.14 must travel through the WARP tunnel. Cloudflare can then block that specific IP at their gateway (if using Zero Trust/Gateway settings).

There is one technical nuance regarding YogaDNS.

YogaDNS WFP (Kernel Mode). If you had enabled the Windows Filtering Platform (WFP) driver in YogaDNS, the result would have been different. WFP operates at the Kernel/Network layer (similar to a firewall). It can force-intercept packets even if they try to bypass standard DNS settings.

Since you saw leaks in ping, we can confirm you were not using WFP mode, validating your conclusion that your specific configuration was vulnerable.

You have successfully derived a core cybersecurity principle. "Defense in Depth."

DNS Filtering (NextDNS) is excellent for privacy, ad-blocking, and stopping "dumb" malware that relies on domain names.

Network Tunneling/Firewalling (WARP/Snort) is required to stop "smart" malware that uses direct IP connections or non-standard protocols.

Your analysis is CORRECT. DNS-only blockers should not be relied upon as a primary "Malware Firewall."

 

[SeriousHoax]

I think that the ping is not a problem, but rather CMD shell, PowerShell, etc. The traffic via LOLBins is probably not intercepted by the NextDNS application and YogaDNS. However, this should be tested to be sure.

I see. I use Technitium DNS Server app on my PC which changes system DNS to 127.0.0.1 & :: so ping command to a blacklisted domain is blocked by it. I also tried some lolbins whose requests were also blocked. But Technitium is bit more complex app. Something lighter would be AdGuard Home and Unbound where you'll have to put your ZeroTrust DoH/DoT. AdGuard Home supports all encrypted DNS protocols while Unbound only supports DoT. But of course, as you know, none of these would block direct communication to an IP address.

 

[Andy Ful]

DNS Filtering (NextDNS) is excellent for privacy, ad-blocking, and stopping "dumb" malware that relies on domain names.

Yes. However, DNS filtering via Cloudflare WARP + Zero Trust (especially blocking NRDs) is welcome when blocking loaders (like ClickFix). I mentioned it in one of my previous posts. This requires DNS filtering at the network level, like in Cloudflare WARP.

Network Tunneling/Firewalling (WARP/Snort) is required to stop "smart" malware that uses direct IP connections or non-standard protocols.

This requires adding some IP-related policies in CloudFlare Zero Trust. I am not sure how effective/useful this can be in practice, especially at home. It is possible that some IP filtering is included in Zero Trust Indicator Feeds.

 

[Parkinsond]

A critical zero-day vulnerability in Cloudflare’s Web Application Firewall (WAF) allowed attackers to bypass security controls and directly access protected origin servers through a certificate validation path.

Cloudflare Zero-Day Vulnerability Enables Any Host Access Bypassing Protections

A critical zero-day vulnerability in Cloudflare's Web Application Firewall (WAF) allowed attackers to bypass security controls and directly access protected origin servers through a certificate validation path.

cybersecuritynews.com

 

[Marko :)]

Gosh this Cloudflare is REALLY unstable. They have issues literally every... single... day. Today again issues with dashboard.

 

[rashmi]

I used it after getting new plan.

Easy. Team & Resources -> Devices -> Add device.

I added the "login method" to the policy; that seemed to be the problem. Then, I used the "Add device" wizard, and it worked perfectly.

I tested Gateway with WARP mode; WARP is identity-based. You don't need to create Cloudflare "Locations" if you use WARP.

The free legacy plan allows a maximum of 3 locations (profiles). Identity-based WARP is better; you can have 50 seats (profiles) instead.

Identity-based WARP has a drawback; you can't have multiple pairs in the firewall policy.
For example, I have one "Blocked" policy; it blocks different categories for all 3 locations. It isn't possible with identity-based WARP; you must create a new policy for each user to have different protection.

I haven't looked into the ad block script yet for replacing Cloudflare locations with user emails.

Edit.
It looks like the traffic is directed by WARP to Cloudflare. Next comes the in-browser DOH request. If the URL is blocked, you can see the error page. If not, Clouflare Zero Trust checks the URL.
In my config, I use WARP integrated with Zeo Trust.

It seems Gateway with WARP can't intercept the secure DNS of browsers.

But of course, as you know, none of these would block direct communication to an IP address.

I suppose one could use policies in "Network" and "HTTP" for this.

 

[Andy Ful]

It seems Gateway with WARP can't intercept the secure DNS of browsers.

Yes and No. It intercepts all traffic (including the browsers) and directs it to CloudFlare. Next, Cloudflare checks the URL of DOH and allows it, so the DOH in the browser can check the domain. If you block in the Cloudflare the domain of NextDNS (used in the web browser), all domains will be blocked in the web browser.

 

[Trident]

Yes and No. It intercepts all traffic (including the browsers) and directs it to CloudFlare. Next, Cloudflare checks the URL of DOH and allows it, so the DOH in the browser can check the domain. If you block in the Cloudflare domain of NextDNS used in the web browser, all domains will be blocked in the web browser.

Sorry to ask, but isn’t WARP operating through a “VPN” protocol? At least on mobile it is…?

 

[Andy Ful]

Sorry to ask, but isn’t WARP operating through a “VPN” protocol? At least on mobile it is…?

If I recall correctly, WARP uses WireGuard or MASQUE.

 

[Trident]

If I recall correctly, WARP uses WireGuard or MASQUE.

Well that’s why, WARP relies on kernel mode traffic redirection/interception which the browser simply can’t bypass.

I played with it very briefly just now but it seems very convoluted.

I mean surely I can define IP ranges…

I will need a quick start guide…

 

[Andy Ful]

I will need a quick start guide…

There are some good videos on the web. The rest may be found in this thread.

 

[Trident]

There are some good videos on the web. The rest may be found in this thread.

I know but till I read these 14 pages… I will try and find the most useful posts in the beginning of the thread.