The Traffic Source selector is here: Cloudflare Gateway can now tell where your traffic came in!

Hey there, it's Shii! Today I found a Cloudflare Gateway update focused on the "front door" of your network. It might look understated, but I think it's the kind of feature that really pays off once you're running it, so let me walk you through it!

Cloudflare Changelog developers.cloudflare.com

What was announced?

According to the Cloudflare Changelog, Cloudflare Gateway's HTTP and Network policies now include a new "Traffic Source" selector. It identifies how traffic reached Cloudflare in the first place. For example, you can now distinguish traffic coming through the Cloudflare One Client (WARP) from traffic arriving via an MCP portal or a proxy endpoint, and apply different rules to each.

The story so far

Until now, Gateway policies could already be built around things like destination URL or application category, but there was no way to control traffic based on which onramp it actually came in through. Corporate networks have all sorts of entry points, WARP clients, Mesh connectors, Magic WAN, clientless RDP, proxy endpoints, and more, but they all had to be handled under the same rules.

What changes

With the Traffic Source selector, you can now apply different policies depending on the onramp type. Here are the values from the original post:

• Device client (device_client) — traffic from the Cloudflare One Client (WARP)
• Mesh (mesh) — traffic from a Cloudflare Mesh connector
• Cloudflare WAN (cloudflare_wan) — traffic from Magic WAN
• Clientless RDP (clientless_rdp) — traffic from a clientless RDP session
• Proxy endpoint (proxy_endpoint) — traffic from a proxy endpoint via a PAC file
• Clientless Browser Isolation (agentless_biso) — traffic from clientless Browser Isolation
• MCP portal (mcp_portal) — traffic from an MCP portal

That means you could apply a special rule only to traffic coming through an MCP portal, or set different policies for employee devices on WARP versus visitor devices on a proxy, fine-grained control based on where traffic came from. For network admins, this makes it much easier to design zero-trust policies tailored to the source of the traffic.

Dive Deep

Under the hood, the Traffic Source selector uses an API field called net.onramp.type, and you can wire it into a condition in either HTTP or Network policies like this:

net.onramp.type == "device_client"

Since the UI display names and API values are both published together, this should be easy to work with if you're managing policies as code, say, with Terraform.

Alongside it, a "Browser Isolation" selector was also added for Network and HTTP policies. It uses:

net.is_isolated == true

to determine whether the current session is running inside Remote Browser Isolation. That opens the door to things like applying a different rule only to isolated sessions.

The announcement doesn't say whether this is GA or still in beta, and for detailed setup it points to the "HTTP policies" and "Network policies" documentation.

Wrap-up

• Cloudflare Gateway's HTTP/Network policies gained a Traffic Source selector, letting net.onramp.type distinguish seven onramp types including WARP, Mesh, Magic WAN, proxy, and MCP portal
• You can now apply different policies per onramp type, enabling finer-grained zero-trust access control
• A Browser Isolation selector (net.is_isolated) was also added, so you can tell whether a session is isolated

If you run network policies on Cloudflare One and have been wishing you could vary your rules by traffic source, this announcement is for you!