techlist.io
KREN
cloudflare

Route public traffic to private applications with Cloudflare (opens in new tab)

cloudflarecloudflare-workerszero-trustweb-application-firewallprivate-networkingcloudflare-tunnelapi-routing

Cloudflare is extending its application security, performance, and programmability services to applications hosted on private networks. Its new Application Services for Private Origins allows public traffic to reach private origins through existing connectivity such as IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh—without public IP exposure, inbound firewall rules, or cloudflared on the origin. The feature is entering closed beta for eligible Enterprise customers.

Unifying Public and Private Application Traffic

  • Private applications—including internal APIs, AI backends, MCP servers, and operational tools—can now use:
    • WAF
    • Bot management
    • Rate limiting
    • Caching
    • Traffic acceleration
    • Rewrites
    • Workers
  • Cloudflare treats private IPs as valid origin targets for public hostnames.
  • The model supports four traffic combinations:
    • Public users to public applications
    • Private users to public applications
    • Public users to private applications, which is shipping now
    • Private users to private applications, planned for the future

Reusing Existing Private Connectivity

  • The feature builds on Cloudflare’s existing private networking layer.
  • Supported connectivity models include:
    • Cloudflare Tunnel
    • Cloudflare One Client
    • IPsec and GRE tunnels
    • CNI links
    • Cloudflare Mesh
  • Customers can manage routing through Cloudflare’s dashboard and APIs rather than maintaining separate networking stacks.
  • Workers VPC bindings and Spectrum private-origin routing also use this shared connectivity layer.

Application Services for Private Origins

  • Customers can enable Use private network routing on a proxied A or AAAA DNS record.
  • Cloudflare continues applying WAF, rate limiting, caching, bot management, and transform rules at its edge.
  • Only the final connection differs: Cloudflare sends traffic through the customer’s private network instead of over the public Internet.
  • Private routing is automatically enabled for:
    • RFC 1918 IPv4 ranges such as 10.0.0.0/8
    • RFC 6598 CGNAT ranges such as 100.64.0.0/10
    • RFC 4193 IPv6 unique-local addresses such as FC00::/7
  • Public IPs reachable only through a private network can be configured manually.

API Configuration

  • Private routing is represented as an additional DNS record attribute:
{
  "type": "A",
  "name": "app.example.com",
  "content": "10.0.0.50",
  "ttl": 300,
  "proxied": true,
  "use_private_routing": true
}
  • Cloudflare’s Origin API returns the use_private_routing flag.
  • When the proxy sees that flag, it passes the request to Cloudflare’s private networking layer, which selects the appropriate private path.

Beyond HTTP

  • The same routing approach supports non-HTTP services.
  • Potential origins include:
    • TCP databases
    • UDP logging endpoints
    • Private APIs accessed by Workers
  • Spectrum can extend the model to TCP and UDP services, while Workers VPC enables direct access from serverless code.

Cloudflare’s recommendation is effectively to use existing private connectivity as the transport layer while centralizing application security, performance, and routing at Cloudflare’s edge. The feature is currently limited to eligible Enterprise customers in closed beta.