diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx
index b70c0267922214..3cfd82361f6f72 100644
--- a/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx
+++ b/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx
@@ -20,18 +20,15 @@ To enable remote access to your private network, follow the guide below.
To connect your infrastructure with Cloudflare Tunnel:
1. Create a Cloudflare Tunnel for your server by following our [dashboard setup guide](/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel/). You can skip the connect an application step and go straight to connecting a network.
-
2. In the **Private Networks** tab for the tunnel, enter the IP/CIDR range of your private network (for example `10.0.0.0/8`). This makes the WARP client aware that any requests to this IP range need to be routed to your new tunnel.
:::note
-
Cloudflare Tunnel only supports routes in the [private IP address space](https://www.rfc-editor.org/rfc/rfc1918.html#section-3):
- `10.0.0.0` - `10.255.255.255`
- `172.16.0.0` - `172.31.255.255`
- `192.168.0.0` - `192.168.255.255`
-
-:::
+ :::
## 2. Set up the client
@@ -63,7 +60,6 @@ You can create Zero Trust policies to manage access to specific applications on
5. For **Value**, enter the IP address for your application (for example, `10.128.0.7`).
:::note
-
If you would like to create a policy for an IP/CIDR range instead of a specific IP address, you can build a [Gateway Network policy](/cloudflare-one/policies/gateway/network-policies/) using the **Destination IP** selector.
:::
@@ -74,15 +70,17 @@ You can create Zero Trust policies to manage access to specific applications on
8. Modify the policies to include additional identity-based conditions. For example:
- **Policy 1**
- | Selector | Operator | Value | Logic | Action |
+
+ | Selector | Operator | Value | Logic | Action |
| -------------- | ------------- | ---------------- | ----- | ------ |
- | Destination IP | in | `10.128.0.7` | And | Allow |
- | User Email | matches regex | `.*@example.com` | | |
+ | Destination IP | in | `10.128.0.7` | And | Allow |
+ | User Email | matches regex | `.*@example.com` | | |
- **Policy 2**
- | Selector | Operator | Value | Action |
+
+ | Selector | Operator | Value | Action |
| -------------- | -------- | ------------ | ------ |
- | Destination IP | in | `10.128.0.7` | Block |
+ | Destination IP | in | `10.128.0.7` | Block |
Policies are evaluated in [numerical order](/cloudflare-one/policies/gateway/order-of-enforcement/#order-of-precedence), so a user with an email ending in @example.com will be able to access `10.128.0.7` while all others will be blocked. For more information on building network policies, refer to our [dedicated documentation](/cloudflare-one/policies/gateway/network-policies/).
@@ -111,7 +109,5 @@ Check the local IP address of the device and ensure that it does not fall within
To resolve the IP conflict, you can either:
- Reconfigure the user's router to use a non-overlapping IP range. Compatible routers typically use `192.168.1.0/24`, `192.168.0.0/24` or `172.16.0.0/24`.
-
- Tighten the IP range in your Split Tunnel configuration to exclude the `10.0.0.0/24` range. This will only work if your private network does not have any hosts within `10.0.0.0/24`.
-
- Change the IP/CIDR of your private network so that it does not overlap with a range commonly used by home networks.
diff --git a/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx b/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx
index faf3801b04ae71..8dfcccf2eca46b 100644
--- a/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx
+++ b/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx
@@ -2,14 +2,15 @@
{}
---
-import { Details } from "~/components";
+import { Tabs, TabItem } from "~/components";
1. Go to **Settings** > **Network**.
-2. Enable **Proxy** for TCP.
-3. (Recommended) To proxy traffic to internal DNS resolvers, select **UDP**.
-4. (Recommended) To proxy traffic for diagnostic tools such as `ping` and `traceroute`, select **ICMP**. You may also need to update your system to allow ICMP traffic through `cloudflared`:
+2. Turn on **Proxy**.
+3. Select **TCP**.
+4. (Recommended) To proxy traffic to internal DNS resolvers, select **UDP**.
+5. (Recommended) To proxy traffic for diagnostic tools such as `ping` and `traceroute`, select **ICMP**. You may also need to update your system to allow ICMP traffic through `cloudflared`:
-
+
1. Ensure that `ping_group_range` includes the Group ID (GID) of the user running `cloudflared`.
@@ -36,14 +37,12 @@ import { Details } from "~/components";
cloudflared tunnel run --icmpv4-src
```
-
-
-
+
In your environment, modify the `ping_group_range` parameter to include the Group ID (GID) of the user running `cloudflared`.
By default the [`cloudflared` Docker container](https://github.com/cloudflare/cloudflared/blob/master/Dockerfile#L29C6-L29C13) executes as a user called `nonroot` inside of the container. `nonroot` is a specific user that exists in the [base image](https://github.com/GoogleContainerTools/distroless/blob/859eeea1f9b3b7d59bdcd7e24a977f721e4a406c/base/base.bzl#L8) we use, and its Group ID is hardcoded to 65532.
-
+
Cloudflare will now proxy traffic from enrolled devices, except for the traffic excluded in your [split tunnel settings](/cloudflare-one/connections/connect-networks/private-net/cloudflared/#3-route-private-network-ips-through-warp). For more information on how Gateway forwards traffic, refer to [Gateway proxy](/cloudflare-one/policies/gateway/proxy/).
diff --git a/src/content/partials/cloudflare-one/tunnel/warp-to-tunnel-route-ips.mdx b/src/content/partials/cloudflare-one/tunnel/warp-to-tunnel-route-ips.mdx
index a1951571465af4..a24f839796a158 100644
--- a/src/content/partials/cloudflare-one/tunnel/warp-to-tunnel-route-ips.mdx
+++ b/src/content/partials/cloudflare-one/tunnel/warp-to-tunnel-route-ips.mdx
@@ -1,14 +1,11 @@
---
{}
-
---
By default, WARP excludes traffic bound for [RFC 1918 space](https://datatracker.ietf.org/doc/html/rfc1918), which are IP addresses typically used in private networks and not reachable from the Internet. In order for WARP to send traffic to your private network, you must configure [Split Tunnels](/cloudflare-one/connections/connect-devices/warp/configure-warp/route-traffic/split-tunnels/) so that the IP/CIDR of your private network routes through WARP.
1. First, check whether your [Split Tunnels mode](/cloudflare-one/connections/connect-devices/warp/configure-warp/route-traffic/split-tunnels/#change-split-tunnels-mode) is set to **Exclude** or **Include** mode.
-
2. If you are using **Include** mode, add your network's IP/CIDR range to the list. Your list should also include the [domains necessary for Cloudflare Zero Trust functionality](/cloudflare-one/connections/connect-devices/warp/configure-warp/route-traffic/split-tunnels/#cloudflare-zero-trust-domains).
-
3. If you are using **Exclude** mode:
1. Delete your network's IP/CIDR range from the list. For example, if your network uses the default AWS range of `172.31.0.0/16`, delete `172.16.0.0/12`.
2. Re-add IP/CDIR ranges that are not explicitly used by your private network. For the AWS example above, you would add new entries for `172.16.0.0/13`, `172.24.0.0/14`, `172.28.0.0/15`, and `172.30.0.0/16`. This ensures that only traffic to `172.31.0.0/16` routes through WARP.