Cloudflare Command Center: Domains, DNS, Zero Trust, and Tunnels from Beginner to Expert Part 14: Private Networking with Cloudflare Zero Trust

Part 13 closed the loop on Cloudflare Access, walking through how to put a Zero Trust authentication layer in front of publicly reachable applications. That covered one half of what Cloudflare Zero Trust can do. This part covers the other half, and it's the one that tends to surprise people who assumed "Zero Trust" just meant fancier login pages.

Private networking is different. Not in a subtle way. Fundamentally different in what it protects, how it routes traffic, and what an attacker would need to do to reach something that shouldn't be reachable in the first place. Part 14 is about building a private network that doesn't expose anything to the public internet, doesn't require a traditional VPN appliance, and still lets your developers, remote workers, and internal tools talk to each other as if they were sitting in the same building.

That's the goal. Here's how it works.

Why Private Networking Needs a Rethink

The Problem With Traditional VPNs

Traditional VPNs were designed for a world that no longer exists. The model made sense when your entire infrastructure sat in one building, your employees worked from desks inside that building, and "remote access" meant occasional travel. Authenticate once, get inside the perimeter, access everything. Simple. Also catastrophically naive by current standards.

The core flaw isn't performance or cost, though both are real problems. The core flaw is that VPN access is binary. You're either in or you're out. Once a user authenticates, they typically get broad access to whatever the VPN subnet can reach, which in most organizations is far more than any individual user actually needs. A compromised credential doesn't just expose one service. It exposes the network.

Hardware VPN appliances compound this. They're expensive to buy, painful to maintain, and they create exactly the kind of single point of failure that keeps infrastructure teams awake at night. Scaling them for a distributed workforce means buying more hardware, managing more configuration, and hoping the vendor's firmware update cycle keeps pace with the threat landscape.

"A network perimeter that assumes trust based on location is not a security model. It's a liability."

What Zero Trust Private Networking Actually Means

Zero Trust flips the assumption. Instead of granting broad access after a single authentication event, it verifies identity and device posture before every connection to every resource. There's no "inside the network" in the traditional sense. There's just a continuous evaluation of whether this specific device, used by this specific user, should reach this specific resource right now.

Cloudflare's implementation runs on a network that spans more than 300 cities globally. That matters because latency kills adoption. If your private network access is slow, people route around it. They find workarounds, they disable the client, they store things in places they shouldn't. A fast, transparent connection that users barely notice is the only version of this that actually gets used consistently.

Small businesses benefit as much as enterprises here. You don't need a dedicated IT team or a rack of hardware to build this. You need a Cloudflare account, a few configuration steps, and about an hour.

How Cloudflare Zero Trust Private Networking Works

The Architecture at a Glance

Two components do all the work. On the user's device, the WARP client handles enrollment, routing, and the encrypted connection to Cloudflare's edge. On the network side, the cloudflared connector runs as a lightweight daemon on a machine that has access to your private subnet. These two pieces never communicate directly. Everything routes through Cloudflare's global network, which acts as the broker for every connection.

That brokered model is what makes this work without exposing anything publicly. Your internal database, your development server, your internal dashboard: none of them need a public IP address. None of them need firewall rules that allow inbound traffic from the internet. They stay completely dark to anything except the cloudflared connector running beside them.

WARP Client Plus Tunnel: The Core Pairing

It's worth being precise about what each component does, because they're easy to conflate. The WARP client is the device-side piece. It enrolls the device into your Zero Trust organization, routes traffic destined for private IP ranges through an encrypted tunnel to Cloudflare's edge, and enforces any policies you've configured for that device or user. It does not connect directly to your private network.

The cloudflared tunnel is the network-side piece. It runs on a server or VM inside your private network, maintains an outbound-only connection to Cloudflare's edge, and advertises which IP ranges are reachable through it. When a WARP-enrolled device sends traffic to one of those advertised ranges, Cloudflare routes it through the tunnel to the cloudflared connector, which delivers it to the destination.

How Traffic Flows From Device to Private Resource

Walk through the path once and it becomes intuitive. A developer opens a database client on their laptop and tries to connect to 10.10.1.50. The WARP client on that laptop sees the destination IP falls within an advertised private range. It routes the traffic through an encrypted connection to the nearest Cloudflare edge location. Cloudflare checks whether this device and user are authorized to reach that subnet based on your configured policies. If they are, the traffic continues through the cloudflared tunnel to the connector running in your private network, which delivers it to the database at 10.10.1.50. The database responds, the path reverses, and the developer gets their query results.

No public IP. No inbound firewall rules on the database server. No VPN appliance in the critical path. The whole exchange happens through outbound connections that both sides initiated, brokered by Cloudflare's network in the middle.

Setting Up the WARP Client for Private Access

Installing WARP on macOS, Windows, and Linux

The WARP client ships as a native application for every major desktop platform. On macOS, it's a standard .pkg installer available from Cloudflare's download page. On Windows, it's an .msi package that installs cleanly and adds a system tray icon. On Linux, Cloudflare maintains packages for Debian-based and RPM-based distributions, installable through standard package managers once you've added the Cloudflare repository.

The consumer version of WARP is a privacy-focused DNS and traffic tool that Cloudflare offers publicly. That's not what you're deploying here. The Zero Trust version, sometimes labeled Gateway with WARP, is a different operational mode that connects the client to your organization's Zero Trust tenant rather than Cloudflare's public consumer network.

Configuring WARP in Gateway With WARP Mode

After installation, the default mode is consumer WARP. To switch it to Zero Trust mode, the device needs to be enrolled in your organization. That enrollment process changes what the client does fundamentally. Instead of routing all traffic through Cloudflare's public network for privacy, it routes only the traffic you've configured, applies your organization's policies, and reports device posture information back to your Zero Trust dashboard.

Gateway with WARP mode also enables DNS filtering through Cloudflare Gateway, which is a separate capability covered later in this series. For now, the important thing is that enrollment is what activates private network routing.

Connecting WARP to Your Zero Trust Organization

Enrollment happens through your team name, which is the subdomain you configured when setting up your Zero Trust account. In the WARP client preferences, there's an account section where users can enter this team name. On macOS and Windows, that's under Preferences, then the Account tab. On Linux, you use the warp-cli command-line tool with the registration new command.

Once the team name is entered, the client opens a browser window to your configured identity provider for authentication. After successful authentication, the device is enrolled and appears in your Zero Trust dashboard under the Devices list. Routing behavior changes immediately. Traffic destined for your advertised private IP ranges starts flowing through the tunnel rather than hitting the public internet directly.

The distinction between Include and Exclude traffic modes determines which traffic actually goes through WARP. Include mode sends only specified ranges through the tunnel. Exclude mode sends everything except listed ranges. For private network access, Include mode with your specific private subnets is usually the right starting point, and the next section on split tunnels covers this in detail.

Device Enrollment: Getting Users and Machines Into Your Network

Enrollment Permissions and Identity Providers

Before any device can enroll, you need to configure who's allowed to do it. In the Zero Trust dashboard, under Settings and then WARP Client, there's an enrollment permissions section where you define which users can enroll devices. This is typically tied to an identity provider, and Cloudflare supports the ones organizations actually use: Google Workspace, Okta, GitHub, Azure AD, and others via generic SAML or OIDC connectors.

Connecting an identity provider for enrollment is the same process covered in Part 13 for Access authentication. If you already have an IdP configured, you can use it here without additional setup. The enrollment permission rule can be as broad as "anyone in my organization" or as narrow as a specific group, email domain, or user attribute that your IdP provides.

Manual Enrollment vs. MDM Deployment

For small teams, manual enrollment is fine. Users download WARP, enter the team name, authenticate, and they're in. For larger organizations, manual enrollment at scale becomes a coordination problem. That's where MDM deployment changes the calculus entirely.

Cloudflare publishes MDM configuration profiles for Jamf, Microsoft Intune, and other mobile device management platforms. These profiles can pre-configure the team name, set the operating mode to Gateway with WARP, and trigger silent enrollment without any user interaction. A new employee gets their laptop, the MDM profile deploys automatically, and by the time they sit down the device is already enrolled in your Zero Trust network.

The MDM configuration also lets you lock down client settings so users can't accidentally switch modes, disable WARP, or change the team name. For environments where compliance matters, that lockdown is often a requirement rather than a preference.

Device Posture Checks Before Access Is Granted

Enrollment gets a device into your network. Device posture checks determine what that device can actually reach once it's enrolled. These checks run continuously and can gate access to specific resources based on real-time device state.

The checks Cloudflare supports include OS version requirements, disk encryption status, firewall enabled or disabled, specific application presence, and certificate-based verification. A device running an outdated OS version can be blocked from reaching sensitive internal resources while still having access to less critical ones. A device without disk encryption enabled can trigger a different policy than a fully compliant machine.

From a developer's perspective, the enrollment flow looks like this: open WARP, click the account login option, enter the team name, authenticate through whatever IdP your organization uses, and the device appears enrolled. The whole process takes under two minutes when the identity provider is already configured. In the dashboard, that device shows up in the Devices list with its posture status, the user it's associated with, the platform it's running on, and a revoke option that immediately removes its access.

Revoking a device is immediate and complete. The device loses routing access to all private subnets and any Access-protected resources tied to device posture requirements. For offboarding or lost devices, that's the relevant button.

Exposing Private Subnets via Cloudflare Tunnel

Creating a Tunnel for Private Network Routing

The cloudflared tunnel for private network routing is created the same way as any other Cloudflare Tunnel. In the Zero Trust dashboard, navigate to Networks and then Tunnels. Create a new tunnel, give it a name that identifies the network segment it covers, and follow the installation steps to run the cloudflared connector on a machine inside your private network.

The connector machine doesn't need to be powerful. It needs two things: outbound internet access to reach Cloudflare's edge, and network-level access to the subnet you want to advertise. A small VM, a spare server, or even a Raspberry Pi handles this workload without strain. The cloudflared process is lightweight and maintains persistent outbound connections to Cloudflare, so there's no inbound firewall configuration required on the connector machine itself.

Advertising IP Routes Through the Tunnel

Once the tunnel is running, you add private network routes to it. In the tunnel configuration, under the Private Network tab, you add the CIDR ranges that should be reachable through this tunnel. Adding 10.0.0.0/8 tells Cloudflare that any WARP-enrolled device trying to reach anything in that range should route through this tunnel.

You can be more specific. Advertising 10.10.1.0/24 instead of the entire 10.0.0.0/8 range limits what's reachable through this particular tunnel, which is useful when you have multiple tunnels covering different network segments. Specificity here is a security decision as much as a routing one. Advertising only what users actually need to reach is better than advertising everything and relying on application-level controls downstream.

Example: Accessing a Private 10.x.x.x Subnet

Concrete scenario. A developer's laptop has WARP enrolled in your Zero Trust organization. You have a cloudflared connector running on a VM at 10.10.1.5 inside your private network, with the route 10.10.1.0/24 advertised through the tunnel. A PostgreSQL database runs at 10.10.1.50.

The developer opens their database client and connects to 10.10.1.50:5432. WARP sees the destination falls within the advertised range. The traffic routes to Cloudflare's edge, passes through the tunnel to the cloudflared connector at 10.10.1.5, and gets delivered to the database. The database sees the connection arriving from an internal IP and responds normally. The developer gets their connection.

The database has no public IP. No inbound rules were added to any firewall. The developer didn't configure anything special in their database client. It just works, because the routing layer handles everything transparently.

For production environments, running multiple cloudflared connectors against the same tunnel provides redundancy. If one connector goes down, Cloudflare automatically routes through the remaining healthy connectors. Two connectors on separate machines in the same subnet is the minimum recommended setup for anything that needs to stay available.

Split Tunnels: Controlling What Traffic Goes Through Cloudflare

Include Mode vs. Exclude Mode

Not every byte of traffic from an enrolled device should route through Cloudflare's network. Most of it shouldn't.

Split tunneling is how you

Gateway Policies for Identity-Aware Network Access

What Gateway Network Policies Are

Cloudflare Access handles application-level authentication. You've seen that in earlier parts of this series. Gateway network policies operate at a different layer entirely. They sit between the enrolled device and private destinations, evaluating every connection attempt before a single packet reaches your internal network. Think of Access as the bouncer at the front door of a specific application, and Gateway network policies as the security desk in the lobby that decides which floors you're even allowed to reach.

These policies evaluate connections against a combination of signals: user identity pulled from your IdP, group membership, device posture scores, destination IP or CIDR, protocol, and port. That combination is what makes this genuinely different from a traditional firewall rule. A firewall knows about IPs and ports. Gateway knows who is holding the device, whether that device is healthy, and whether that person belongs to a group that should have access to that destination at all.

Policy ordering matters. Cloudflare evaluates Gateway network policies from top to bottom, and the first matching policy wins. If no policy matches, the default behavior applies, which is configurable as either allow or block. Most security-conscious configurations set the default to block, forcing every permitted path to be explicitly defined.

Building Policies Based on Identity, Device, and Destination

Creating a Gateway network policy starts in the Zero Trust dashboard under Gateway > Firewall Policies > Network. Each policy is a set of conditions combined with an action: allow, block, or override. The conditions draw from selectors that include user email, IdP group, device posture profile, destination IP, destination port, and protocol.

Identity flows into policy evaluation through a specific chain. The user authenticates with your IdP during WARP enrollment. That authentication produces a token containing group membership claims. When the enrolled device makes a connection attempt, WARP passes that identity context to the Gateway policy engine, which evaluates it against your defined conditions in real time. The device posture check runs alongside that, confirming the device meets your baseline before any access is granted.

Example: Only Engineers Can Reach the Database Subnet

Here's a concrete policy. The goal is to restrict access to 10.10.1.0/24 to users who are members of the engineering group in your IdP.

In the Network policy editor, set the following conditions:

• Destination IP matches 10.10.1.0/24
• User Group Names includes engineering

Set the action to Allow. Save the policy and position it above any broader block rule in your policy list.

What this accomplishes: a developer enrolled in WARP who belongs to the engineering group can reach any host in that subnet. A contractor enrolled in WARP who isn't in that group hits the block rule that sits below and gets denied, with the reason code logged for your review.

This is the contrast worth understanding clearly. A Cloudflare Access policy protects a specific application URL. It controls who can authenticate to that application. A Gateway network policy controls whether a connection to a destination IP and port is allowed at all, regardless of what application is running there. Both have their place. For private networking, Gateway network policies are the primary control layer.

Real-World Example: Developer Access to Internal Tools

The Scenario: A Remote Developer Needs Database and Admin Panel Access

A developer is working remotely. They need two things: SSH access to a PostgreSQL database running at 10.0.1.5 and browser access to an internal Grafana dashboard at 10.0.1.20. Both resources live on the office network. Neither is exposed to the internet. In the old model, this means a VPN client, a hardware appliance someone has to maintain, and probably a static IP whitelist that someone forgot to update six months ago.

The Zero Trust model handles this differently. No appliance. No static IPs. No client software beyond WARP.

Step-by-Step Configuration Walkthrough

The configuration has four moving parts. First, a cloudflared tunnel runs on a server in the office network, advertising 10.0.0.0/24 as a private network route. Second, the developer's device has WARP installed and enrolled in the organization's Zero Trust account. Third, the split tunnel configuration includes 10.0.0.0/24 so traffic destined for that range routes through WARP rather than going out to the internet directly. Fourth, a Gateway network policy allows members of the engineering IdP group to reach destinations within 10.0.0.0/24.

"Every connection through this setup is logged with a timestamp, the user identity, the destination IP, and whether it was allowed or blocked. That's an audit trail a traditional VPN rarely produces."

That last point is the one most teams underestimate until they need it.

What the Developer Experience Looks Like

The developer opens WARP, authenticates with Google SSO, and they're enrolled. That's it. They open a terminal and SSH to 10.0.1.5 directly. They open a browser and navigate to http://10.0.1.20. Both work. No special client configuration, no certificate bundle to install, no IT ticket to request access to a VPN profile.

The Zero Trust logs in the dashboard record every session. When a security review comes up, you have a complete record of who accessed what and when, without running a query against a firewall that may or may not have kept those logs.

Real-World Example: Small Business Remote Access

The Scenario: A 15-Person Team Replacing Their Office VPN

Fifteen employees. One office with a NAS, an internal wiki, and accounting software. Everyone needs remote access, but the hardware VPN is aging, the license renewal is coming up, and nobody on the team particularly wants to manage it. This is exactly the scenario where Cloudflare's Zero Trust stack earns its place.

The target state: cloudflared runs on an office server or a Raspberry Pi, advertising the office subnet 192.168.1.0/24 as a private network route. WARP is deployed to all 15 company devices. Access is segmented by role. The hardware VPN gets decommissioned.

Deploying WARP Across the Team via MDM

Silent deployment through MDM is the right move for a team this size. Configure the WARP client with the organization's team name pre-populated, set enrollment to require authentication through your IdP, and push the package. Employees open their devices and WARP is already there, already configured, waiting for them to authenticate.

Device posture checks can be added at this stage too. Requiring disk encryption and a current OS version before granting enrollment is a reasonable baseline for a 15-person team.

Segmenting Access by Role

Two Gateway network policies cover the access requirements. The first allows all authenticated staff to reach the internal wiki at 192.168.1.10. The second allows only members of the finance IdP group to reach the accounting server at 192.168.1.30. Everyone else who tries to connect to 192.168.1.30 hits the default block rule, and that attempt is logged.

The result is that adding a new employee means adding them to the right IdP group. Removing an employee means removing them from the IdP, which immediately revokes their WARP enrollment and all associated access. No VPN profile to delete. No firewall rule to update. The IdP is the single source of truth.

Monitoring, Logging, and Troubleshooting Private Network Access

Zero Trust Logs for Network Sessions

The Zero Trust dashboard logs every network session that passes through Gateway. Each log entry records the user identity, the destination IP, the port, the protocol, the timestamp, and the policy decision with a reason code. For a small team, the dashboard view is sufficient for day-to-day review. For anything requiring compliance logging or incident response, Logpush exports those logs to your SIEM automatically.

Logpush supports destinations including Splunk, Datadog, S3-compatible storage, and others. Setting it up takes about ten minutes in the dashboard under Settings > Logpush, and it's worth doing before you need it rather than after an incident.

Common Issues and How to Diagnose Them

Three problems account for most of the troubleshooting tickets in private network setups.

Split tunnel misconfiguration is the most common. If traffic to your private subnet isn't routing through WARP, check the split tunnel settings in the WARP client profile. The private CIDR must be included in the "Include" list if you're using include mode, or excluded from the "Exclude" list if you're using exclude mode. Running warp-cli debug dns and warp-cli tunnel stats gives you a quick read on what's actually routing.

Tunnel connector offline is the second. Check the cloudflared service status on the server running the connector, then check the connector health indicator in the Zero Trust dashboard under Networks > Tunnels. A connector that's been offline for more than a few minutes will show a degraded status.

Using the WARP Client Diagnostics

The WARP client includes a built-in connectivity test accessible from the client menu. It confirms whether the device is enrolled, whether the tunnel is active, and whether DNS is resolving through Gateway. For deeper issues, trace logs capture the full connection lifecycle. The Send Feedback option in the client generates a support file with logs, configuration details, and diagnostic output, which is useful when escalating an issue to Cloudflare support.

Your Private Network Setup Checklist

Work through this list in order. The tunnel and route advertisements have to be in place before WARP can reach anything, and the policies have to be correct before you start testing or you'll spend time chasing access failures that are actually configuration gaps.

What's Next: Building on Your Private Network Foundation

Part 13 covered the architecture behind WARP and Cloudflare Tunnels, establishing why this model works and how the components fit together. This part turned that architecture into a working private network: enrolled devices, advertised routes, split tunnel configuration, and Gateway policies that enforce identity-aware access controls. If you've followed the checklist and tested your configuration, you now have a functional VPN replacement built on infrastructure that scales, audits itself, and doesn't require a hardware refresh every three years.

That foundation matters because everything built on top of it gets to inherit its properties. The access controls, the logging, the identity integration: those carry forward.

Part 15 takes this further by layering Cloudflare Access application policies on top of the private network you've just built. That combination creates defense-in-depth: Gateway policies control whether a connection to a destination is allowed at the network level, and Access policies control whether a user can authenticate to a specific application running at that destination. Both checks have to pass. It's a meaningful security upgrade over either layer alone.

Before Part 15, take the time to test your current setup against a non-production subnet. Validate the policy logic, confirm the logs are appearing, and make sure device posture checks are behaving as expected. Migrating critical infrastructure onto a configuration you haven't stress-tested is how outages happen.