You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/connect-private-hostname.mdx
+80-12Lines changed: 80 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,20 +5,14 @@ sidebar:
5
5
order: 2
6
6
---
7
7
8
-
import { Render } from"~/components";
8
+
import { Render, Details } from"~/components";
9
9
10
10
`cloudflared` can route to non-HTTP applications on your private network using their private hostname (for example, `wiki.internal.local`). Private hostname routes are especially useful when the application has an unknown or ephemeral IP, which often occurs when infrastructure is provisioned by a third-party cloud provider.
11
11
12
12
:::note[Availability]
13
13
Hostname routes currently require Gateway resolver policies, an Enterprise-only feature. If you are on a Free or Pay-as-you-go plan, you will need to connect the application using its [IP address](/cloudflare-one/connections/connect-networks/private-net/cloudflared/connect-cidr) and [configure Local Domain Fallback](/cloudflare-one/connections/connect-networks/private-net/cloudflared/private-dns/) to resolve its private hostname.
14
14
:::
15
15
16
-
## Limitations
17
-
18
-
### Supported user traffic
19
-
20
-
### Supported network on-ramps
21
-
22
16
## How private hostname routing works
23
17
24
18
Private hostname routing with Cloudflare Tunnel consists of three main components:
@@ -27,7 +21,7 @@ Private hostname routing with Cloudflare Tunnel consists of three main component
27
21
- Gateway resolver policies instruct Gateway to resolve the private hostname using your internal DNS resolver instead of the default public resolver.
28
22
-`cloudflared` installs on a host machine in your private network and proxies traffic from Cloudflare to your internal DNS resolver and internal applications.
29
23
30
-
Figures 1 and 2 illustrate what happens when a user connects to a private hostname (`wiki.internal.local`) from a WARP device.
24
+
Figures 1 and 2 illustrate the flow of DNS and network traffic when a user connects to a private hostname (`wiki.internal.local`):
31
25
32
26

33
27
@@ -36,14 +30,88 @@ Figures 1 and 2 illustrate what happens when a user connects to a private hostna
36
30
3.`cloudflared` does a DNS lookup to figure out what the origin IP is for `wiki.internal.local`.
37
31
4. The Gateway resolver now knows that the origin IP is `10.0.0.5`.
38
32
5. Rather than responding to the DNS query with the actual origin IP, Gateway responds with a random IP address from the CGNAT range `100.80.0.0/16` (for example, `100.80.0.1`). This CGNAT IP is called the initial resolved IP.
39
-
6. Gatewaystores the mapping between the private hostname, CGNAT initial resolved IP, and the actual IP.
33
+
6. Gateway's network engine stores the mapping between the private hostname, initial resolved IP, and the actual IP.
40
34
7. The WARP client receives the initial resolved IP (`100.80.0.1`) in the DNS response for `wiki.internal.local`.
41
35
42
-
As shown in Figure 2 below, the WARP client will now send `wiki.internal.local` traffic to the initial resolved IP through Gateway. Because the destination IP falls within the designated CGNAT range, Gateway knows how it maps to the actual origin IP. Traffic that passes your network policies will now route through Cloudflare Tunnel to the private application.
36
+
As shown in Figure 2 below, the WARP client will now send `wiki.internal.local` traffic to the initial resolved IP. The initial resolved IP mechanism is required because Gateway's network engine operates at L3/L4 and can only see IPs (not hostnames) when processing the connection. Because the packet's destination IP falls within the designated CGNAT range, Gateway knows that it corresponds to a hostname route and can apply hostname-based policies. Traffic that passes your Gateway policies will route through Cloudflare Tunnel to the application's actual origin IP.
43
37
44
38

45
39
46
-
To learn more about the initial resolved IP mechanism, refer to the [Cloudflare blog]().
40
+
To learn more about hostname routing, refer to the [Cloudflare blog]().
41
+
42
+
## Connect to a private hostname
43
+
44
+
This section covers how to enable remote access to a private hostname application using `cloudflared` and WARP.
- Initial resolved IP CGNAT range: `100.80.0.0/16`
71
+
- Private network CIDR where the application is located, e.g. `10.0.0.0/8`. (Still need to know the IP range of the network. Do not need to know the specific IP of the application)
72
+
- Internal DNS resolver IP
73
+
74
+
### 4. Create a resolver policy
75
+
76
+
### 5. (Recommended) Filter network traffic with Gateway
77
+
78
+
#### Enable Gateway proxy for TCP and UDP
79
+
#### Zero Trust policies
80
+
81
+
If you're running a private app on port 443:
82
+
83
+
Option 1: create an Access self-hosted private app https://developers.cloudflare.com/cloudflare-one/applications/non-http/self-hosted-private-app/
84
+
85
+
Option 2: create a Gateway network policy using the SNI selector https://developers.cloudflare.com/cloudflare-one/policies/gateway/network-policies/#sni
86
+
87
+
Self-hosted private apps and Gateway network policies are not currently supported for services on non-443 ports. You can only create a Gateway DNS policy.
88
+
89
+
90
+
### 6. Connect as a user
91
+
92
+
93
+
94
+
## Supported on-ramps/off-ramps
95
+
96
+
### Device connectivity
97
+
98
+
End users can connect to private hostnames from the following device on-ramps:
0 commit comments