|
| 1 | +--- |
| 2 | +pcx_content_type: how-to |
| 3 | +title: Set up a private origin via Cloudflare WAN |
| 4 | +description: Proxy public hostnames to private origins through a Cloudflare WAN IPsec tunnel. |
| 5 | +products: |
| 6 | + - dns |
| 7 | +sidebar: |
| 8 | + order: 2 |
| 9 | + badge: Beta |
| 10 | +tags: |
| 11 | + - Private networks |
| 12 | +--- |
| 13 | + |
| 14 | +This guide walks you through proxying public hostnames to origins on a private network. The private network is reachable through a [Cloudflare WAN](/cloudflare-wan/) (formerly Magic WAN) IPsec tunnel. The CDN, WAF, Cache, and other proxied features apply to this traffic the same way they apply to traffic destined for public origins. |
| 15 | + |
| 16 | +:::note[Closed beta] |
| 17 | +Private Origins for Application Services is in closed beta. To request access, contact your Cloudflare account team. |
| 18 | +::: |
| 19 | + |
| 20 | +## Before you begin |
| 21 | + |
| 22 | +Confirm the following before you start: |
| 23 | + |
| 24 | +- **Active Cloudflare WAN subscription**: This capability requires a Cloudflare WAN subscription on your account. |
| 25 | +- **Access to private origins enabled on your account**: This is a separate entitlement from standard authoritative DNS access. Contact your Cloudflare account team to request access. |
| 26 | +- **IPsec tunnels configured**: Set up two anycast IPsec tunnels for redundancy, each with a different Cloudflare anycast endpoint. Refer to [Configure tunnel endpoints](/cloudflare-wan/configuration/how-to/configure-tunnel-endpoints/). Two settings are important for this use case: |
| 27 | + - Leave **Automatic return routing** disabled. It does not apply to the public-to-private origin traffic pattern, where requests originate on the Internet and reach your origin through Cloudflare's reverse proxy. |
| 28 | + - Keep the default **Health check** settings (type `reply`, direction `bidirectional`, rate `mid`). These defaults are required for tunnel health to track correctly in this use case. |
| 29 | +- **Static routes configured**: Add two static routes for the private prefix you want to reach — one per tunnel — with different priorities so traffic fails over to the backup tunnel if the primary goes down. For example, set priority `100` on the route through your primary tunnel and `101` on the route through your backup tunnel (lower numbers are higher priority). Refer to [Configure routes](/cloudflare-wan/configuration/how-to/configure-routes/). |
| 30 | +- **Cloudflare Source IP set to a private range**: The Cloudflare Source IP is the IP that Cloudflare uses when sending proxied requests into your private network. If it is left as a public range, your network cannot route the return traffic back through the tunnel and requests time out. Refer to [Configure Cloudflare source IPs](/cloudflare-wan/configuration/how-to/configure-cloudflare-source-ips/). |
| 31 | + |
| 32 | +## 1. Verify your Cloudflare Source IP allocation |
| 33 | + |
| 34 | +A misconfigured Cloudflare Source IP is the most common cause of failure. If the Source IP is left as a public range, the network where your origin lives has no return route and requests time out before reaching the application. |
| 35 | + |
| 36 | +Go to [Configure Cloudflare source IPs](/cloudflare-wan/configuration/how-to/configure-cloudflare-source-ips/) and verify that the Source IP is set to a private range, such as `100.64.0.0/12` (the default) or another private `/12` you have selected. |
| 37 | + |
| 38 | +## 2. Create a DNS record with private network routing |
| 39 | + |
| 40 | +Create an `A` or `AAAA` record that points to the private IP address of your origin, with proxy status enabled and **Use private network routing** turned on. This tells Cloudflare to send traffic for the hostname through your Cloudflare WAN tunnel instead of over the public Internet. |
| 41 | + |
| 42 | +For the dashboard and API steps, refer to [Private network routing](/dns/manage-dns-records/how-to/private-origins/private-network-routing/). |
| 43 | + |
| 44 | +## 3. Verify end-to-end connectivity |
| 45 | + |
| 46 | +After the DNS record is in place, validate the path from the Cloudflare network through your tunnel to the origin. |
| 47 | + |
| 48 | +### Check tunnel health |
| 49 | + |
| 50 | +In the Cloudflare dashboard, confirm that your IPsec tunnel is healthy. Refer to [Check tunnel health on the dashboard](/cloudflare-wan/configuration/common-settings/check-tunnel-health-dashboard/). |
| 51 | + |
| 52 | +### Send a request from an external client |
| 53 | + |
| 54 | +From a machine outside your private network, send an HTTPS request to the proxied hostname: |
| 55 | + |
| 56 | +```bash |
| 57 | +curl -v https://<YOUR_DOMAIN>/ |
| 58 | +``` |
| 59 | + |
| 60 | +A successful response confirms that Cloudflare accepted the request, applied your proxied features, and reached the origin through the tunnel. |
| 61 | + |
| 62 | +### Confirm traffic on the origin |
| 63 | + |
| 64 | +On the origin VM, verify that requests are arriving from the Cloudflare Source IP range. For example, to watch for incoming traffic from `100.64.0.0/12` on port `443`: |
| 65 | + |
| 66 | +```bash |
| 67 | +sudo tcpdump -n -i any 'src net 100.64.0.0/12 and dst port 443' |
| 68 | +``` |
| 69 | + |
| 70 | +Replace `100.64.0.0/12` with the Source IP range configured for your account, and adjust the port to match the listener on your origin. |
| 71 | + |
| 72 | +## Common pitfalls |
| 73 | + |
| 74 | +| Symptom | Cause and fix | |
| 75 | +| --- | --- | |
| 76 | +| Connection timeouts from clients | Cloudflare Source IP is set to a public range. Set it to a private `/12`. | |
| 77 | +| Request times out, no response on the origin | The network where your origin lives has no return route for the Cloudflare Source IP range. Add a route that sends that range back through the tunnel. | |
| 78 | +| Tunnel shows IKE established but health checks fail | ICMP is blocked on the path or the health check is misconfigured. Allow ICMP between the tunnel endpoints and confirm the health check direction is `bidirectional` and type is `reply`. | |
| 79 | +| Traffic tries to route over the public Internet | The **Use private network routing** toggle is not turned on for the DNS record. Edit the record and turn the toggle on. | |
| 80 | + |
| 81 | +## Next steps |
| 82 | + |
| 83 | +- [Configure tunnel health alerts](/cloudflare-wan/configuration/common-settings/configure-tunnel-health-alerts/) to get notified when a tunnel goes down. |
| 84 | +- Review the [Private network routing](/dns/manage-dns-records/how-to/private-origins/private-network-routing/) reference for dashboard and API details. |
| 85 | +- If you run into tunnel issues, refer to [Tunnel health troubleshooting](/cloudflare-wan/troubleshooting/tunnel-health/) and [IPsec troubleshooting](/cloudflare-wan/troubleshooting/ipsec-troubleshoot/). |
0 commit comments