Skip to content

CLOUDFLARE 2026-06-10

Read original ↗

Route public traffic to private applications with Cloudflare

Summary

Cloudflare launches Application Services for Private Origins (closed beta, Enterprise), extending its security, performance, and programmability stack (WAF, bot management, rate limiting, caching, Workers, rewrites) to applications running on private networks. Until now, applying these services to private origins required public IPs, firewall exceptions, or connector software (cloudflared). The new capability integrates Cloudflare's private networking layer directly into the application services proxy stack, allowing private IPs to be valid origin targets for public hostnames — using existing IPsec, GRE, CNI, Cloudflare Tunnel, or Cloudflare Mesh connectivity without requiring connector software on the origin.

Key takeaways

  1. Private origins get the full L7 stack. Toggling use_private_routing on a proxied DNS A/AAAA record routes origin connections through the customer's existing private network connectivity instead of the public Internet — WAF, rate limiting, caching, bot management, Workers all run normally; only the final hop changes. (Source: "The only difference is the final hop: instead of reaching the origin over the public Internet, Cloudflare routes the connection through your existing private network connectivity.")

  2. Four-quadrant connectivity model. Traffic is classified by user origin × application location: public→public (classic CDN), private→public (Cloudflare One client), public→private (this launch), private→private (next). The public→private quadrant was the missing piece for customers already on Cloudflare WAN/Mesh. (Source: "Application traffic now falls into four combinations based on where users come from and where applications live.")

  3. Automatic detection for RFC 1918/6598/4193 ranges. The toggle enables automatically when the DNS record points to private IPv4 (10.x, 172.16-31.x, 192.168.x), CGNAT (100.64-127.x), or ULA IPv6 (FC00::/7) addresses since these are only reachable within private networks; public IPs reachable only through a private tunnel require manual toggle. (Source: "The toggle is enabled automatically for RFC 1918 private IPv4 ranges...")

  4. Unified routing layer across products. Cloudflare's private networking layer is now shared by DNS-proxied HTTP origins, Spectrum L4 proxy, and Workers VPC bindings — a single source of truth for private connectivity. (Source: "Workers VPC bindings and Spectrum private origin routing now rely on the same underlying private connectivity layer, giving customers a single source of truth.")

  5. Spectrum extends to TCP/UDP on private IPs. Spectrum applications can specify a virtual_network_id directly on the origin configuration. Cloudflare verifies IP-to-route match at config save time (reject if no tunnel route exists). Initial release supports Cloudflare Tunnel connectivity; other connectivity options follow. (Source: "This means you can now put Spectrum in front of any TCP/UDP service running on a private IP. The service stays private. No public IP, connector software, or load balancer required.")

  6. Workers VPC completes the loop for edge compute. Workers reaching private origins use a binding (env.MY_SERVICE) that routes through the same private path as DNS records — browsers/mobile/Workers/AI agents all reach private origins through Cloudflare. (Source: "Browsers, mobile apps, Workers, and AI agents all reach your private origins through Cloudflare.")

  7. No connector software required on the origin. The key differentiator from Cloudflare Tunnel (which requires cloudflared on/near the origin): customers on WAN (IPsec/GRE/CNI) or Mesh get private-origin routing without deploying connector software, using their existing network-layer connectivity. (Source: "This routing model builds on connectivity patterns Cloudflare already supports... without requiring connector software running on the origin.")

  8. Return-route requirement. Customers must configure a return route for Cloudflare's source IP range 100.64.0.0/12 in their private network — the proxy communicates over this CGNAT range. (Source: "You will need Cloudflare One connectivity and a return route for Cloudflare's source IP range 100.64.0.0/12 in your private network.")

Systems / concepts / patterns extracted

Systems

Concepts

Patterns

Operational numbers

  • GA target: Q4 2026
  • Connectivity options: IPsec tunnels, GRE tunnels, CNI links, Cloudflare Tunnel, Cloudflare Mesh
  • Cloudflare source IP range: 100.64.0.0/12 (return-route requirement)
  • Private IP auto-detection: RFC 1918 (10.x, 172.16-31.x, 192.168.x), RFC 6598 (100.64-127.x), RFC 4193 (FC00::/7)

Caveats

  • Closed beta, Enterprise-only — no GA pricing or SLA disclosed.
  • Spectrum private origins initially supported through Cloudflare Tunnel only (other connectivity options "will follow").
  • No latency/throughput comparison of private-path vs public-path origins disclosed.
  • The post is substantially a product launch announcement — architectural depth is moderate (explains the signal flow but not the internal routing-engine internals).
  • Private-to-private traffic (the fourth quadrant) is "building toward" — not available yet.

Source

Last updated · 542 distilled / 1,571 read