Cloudflare Private Origins: route a public hostname to a private IP — no public address required
Cloudflare's new closed-beta feature lets Enterprise teams proxy a private-IP origin through the full Cloudflare edge stack without exposing a public address — here's how the four transport options work and whether to act now.
Cloudflare entered closed beta on June 10 with Application Services for Private Origins, a feature that lets a proxied DNS A/AAAA record point to an RFC 1918 (or CGNAT / ULA) address and still get the full Cloudflare edge stack — WAF, DDoS mitigation, Bot Management, load balancing — on top. 1
Until now, proxying a private IP through Cloudflare produced Error 1002 ("DNS points to prohibited IP"). 2 Private Origins removes that constraint for Enterprise customers who already have a Cloudflare WAN connection in place.
Loading content card…
What it actually does
The core primitive is a single new toggle in the DNS record editor: "Use private network routing." 1
private_routing toggle on an A record with a private IPv4 address. 3Once enabled, inbound requests to
dash.example.com travel through Cloudflare's global edge normally — TLS termination, WAF inspection, cache — and then the origin-fetch leg travels back through the customer's existing encrypted tunnel to reach 10.1.0.1 inside their private network. The origin never needs a public IP, an inbound firewall rule, or any agent software installed on the host. 4At the API level, the
private_routing field on a DNS record defaults to true for any RFC 1918, CGNAT (100.64.0.0/10), or ULA (fc00::/7) address — it is auto-detected. Setting it to false on a private-IP record returns an error; the field is unsupported on non-A/AAAA record types. 3 When a hostname has multiple A/AAAA records and at least one has private routing enabled, all records for that name travel via private routing.How the tunnel gets there: transport options
Getting Cloudflare's edge to talk to your private network is the harder half of the setup. Private Origins doesn't add a new tunnel type — it reuses whatever Cloudflare WAN connectivity you already have. The four supported transports are: 14
| Transport | How it connects | Redundancy model | Best fit |
|---|---|---|---|
| IPsec anycast | Bidirectional encrypted tunnels to Cloudflare's anycast IPs | Requires two tunnels with prioritized static routes for failover | On-prem or cloud networks with a hardware/software firewall that speaks IKEv1/v2 |
| GRE | Unencrypted GRE over Cloudflare's anycast network | Same dual-tunnel + static route model as IPsec | Environments where encryption is handled at a different layer (MPLS, MACsec, etc.) |
| CNI (Cloud Network Interconnect) | Direct Layer 2/3 cross-connects at carrier-neutral facilities | Carrier-level redundancy built in | Colocation deployments that already have a Cloudflare cross-connect |
| Cloudflare Mesh | Software-defined overlay using Cloudflare's own WireGuard-based mesh | Mesh inherits its own redundancy | Multi-site or all-cloud setups already enrolled in Cloudflare One / Magic WAN |
One mandatory configuration note: Automatic return routing must be disabled for private origins traffic. Return routing was designed for public-to-public traffic patterns; leaving it on causes asymmetric routing that breaks origin reachability. Health checks must use the defaults (
type=reply, direction=bidirectional, rate=mid) to correctly track tunnel liveness. 4Five prerequisites before you can enable it
The docs list the requirements explicitly, and they all point at the same thing: this is an add-on to an existing Enterprise WAN deployment, not a standalone feature. 4
- Active Cloudflare WAN subscription
- Account-level Private Origins permission (separate from standard DNS edit permissions — your team needs to request it)
- At least two anycast IPsec tunnels (for the IPsec path) configured with bidirectional health checks
- Static routes with priority ordering so traffic fails over correctly between tunnels
- Cloudflare Source IP configured to a private range (e.g.,
100.64.0.0/12) so origin servers accept the return traffic
Spectrum and Workers VPC also gain private-origin support — Spectrum uses the
virtual_network_id field, and Workers VPC bindings use the same private_routing mechanism — though dedicated documentation pages for both were not yet live as of June 12. 1Where this sits in Cloudflare's connectivity matrix
Cloudflare's announcement maps Private Origins to one cell of a four-quadrant connectivity matrix — Public User × Private Origin — which is labeled "Today's Release": 1
- Public → Public: classic Cloudflare CDN / WAF (unchanged)
- Public → Private: Private Origins (this release)
- Private → Public: Cloudflare One / Gateway (existing egress security)
- Private → Private: on the roadmap, no timeline given
The blog post from Cloudflare's Enrique Somoza, Steve Welham, and Shruti Mittal frames this as a philosophical shift: "Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit." 1 Until Private Origins, teams running internal apps had to choose between exposing the app publicly (to get Cloudflare's edge services) or keeping it private (and losing those services). Private Origins removes that trade-off for the inbound path.
The architectural reading from @0x_codex captures the shift well: "private apps are starting to get the same edge security/performance layer as public websites — without first pretending they are public." 5
Loading content card…
How it differs from Cloudflare Tunnel and WARP Connector
Private Origins, Cloudflare Tunnel, and WARP Connector all solve "how do I route traffic into a private network without exposing a public IP" — but they target different traffic directions and operator models:
| Private Origins (this release) | Cloudflare Tunnel (cloudflared) | WARP Connector | |
|---|---|---|---|
| Traffic direction | Public internet → private origin | Public internet → private origin | Private user → private resource |
| Requires agent on origin host | No | Yes (cloudflared daemon) | Yes (WARP Connector daemon) |
| DNS record proxy | Standard Cloudflare proxied A/AAAA | CNAME to .cfargotunnel.com | Via Cloudflare One routing |
| Transport | IPsec / GRE / CNI / Mesh (WAN-level) | mTLS over HTTPS (host-level) | WireGuard (host-level) |
| Operational scope | Network-level (routes entire IP ranges) | Application-level (per-app or per-hostname) | User-level (device-to-resource) |
| Plan requirement | Enterprise + Cloudflare WAN | Free and up | Cloudflare One (Zero Trust) |
| GA status | Q4 2026 (currently closed beta) | GA | GA |
The practical difference: if you already run Magic WAN / Cloudflare WAN at the network layer and want your internal services to inherit edge protection without touching each host, Private Origins is the right tool. If you're a team of any size that wants to expose a single internal app to the internet with minimal infrastructure,
cloudflared Tunnel is faster to set up and available today on any plan.How it compares to cloud-native private endpoints
AWS PrivateLink, GCP Private Service Connect, and Azure Private Link all solve an adjacent problem: private service-to-service connectivity within a single cloud. They don't need Cloudflare (or any CDN), but they are cloud-locked.
| Cloudflare Private Origins | AWS PrivateLink | GCP Private Service Connect | Azure Private Link | |
|---|---|---|---|---|
| Cross-cloud / hybrid | ✅ Any IPsec/GRE-capable infra | ❌ AWS-only | ❌ GCP-only | ❌ Azure-only |
| Public traffic ingress | ✅ Yes (core use case) | ❌ No (service-to-service only) | ❌ No | ❌ No |
| Edge services (WAF, DDoS) | ✅ Full Cloudflare stack | ❌ No | ❌ No | ❌ No |
| Requires agent | No | No | No | No |
| Pricing | TBD (closed beta) | $0.01/GB + $0.01/hr/ENI 6 | ~$0.01/hr/endpoint (consumer) 7 | Per-hour + per-GB (JS-rendered, not extractable) 8 |
| GA | Q4 2026 | GA | GA | GA |
The cloud-native private endpoint services are not direct competitors — they solve private east-west connectivity, not public north-south ingress. If your concern is keeping service-to-service calls inside AWS, PrivateLink is the right answer. If your concern is routing public user traffic to an origin that shouldn't have a public IP, Private Origins is the first cloud-agnostic option that also carries full WAF/DDoS capability.
Migrate now or just watch?
Just watch — for most teams. The closed beta is Enterprise-only, requires an active Cloudflare WAN subscription, and won't reach GA until Q4 2026. 19 The community response reflects this: the official Reddit cross-post had 6 upvotes and one substantive comment at the time of writing, with the top commenter noting it "sounds like it's only going to be for Enterprise users." 10
Worth putting on your radar now if:
- You run internal apps (dashboards, APIs, staging environments) that currently need a public IP solely to sit behind Cloudflare's WAF and DDoS protection.
- You're already on Cloudflare Enterprise with Magic WAN / WAN connections in place — the delta to Private Origins is just the account-level permission and DNS toggle.
- You operate in a regulated environment where exposing an origin IP, even behind Cloudflare, is a compliance risk.
What to watch before committing:
- Pricing: not yet disclosed. Given the Enterprise prerequisite and WAN subscription requirement, expect a meaningful add-on cost.
- Private-to-private routing: on the roadmap, but no date. Until it ships, Private Origins only covers the inbound public-traffic use case — internal service mesh routing still needs another approach.
- Spectrum and Workers VPC integration: the blog mentions both, but the dedicated documentation pages were returning 404 as of this writing. 1
If you're already in the Cloudflare Enterprise tier with WAN, contact your account team now — closed beta access is invite-based, and early feedback typically shapes what makes it into GA.
Cover image from the Cloudflare blog post
References
- 1Cloudflare blog: Route public traffic to private applications
blog.cloudflare.com
- 2Cloudflare Docs: Troubleshooting
developers.cloudflare.com
- 3Cloudflare Docs: Private network routing
developers.cloudflare.com
- 4Cloudflare Docs: Set up a private origin via Cloudflare WAN
developers.cloudflare.com
- 5
- 6AWS PrivateLink Pricing
aws.amazon.com
- 7GCP Private Service Connect overview
cloud.google.com
- 8Azure Private Link pricing
azure.microsoft.com
- 9Cloudflare Docs: Private origins overview
developers.cloudflare.com
- 10
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.