Private network access

Enroll clients and apply identity policy

Use the current Cloudflare One client enrollment and Gateway or Access policy to restrict who may reach the routed resource.

8 minute lesson

~~~

The route exists. Now decide who can use it.

Private clients enroll into the organization and send matching routes through the Cloudflare One client. The user installs the client, enters your team name, and authenticates with your identity provider. From that point the device has an identity attached to every packet it sends into the private network. Device identity and posture can become policy inputs — you can require a company-managed device, not just a valid login.

Verify enrollment on the client before testing anything else:

warp-cli status
# Status update: Connected

One client-side gotcha: the client’s split tunnel configuration excludes common private IP ranges by default, so traffic to your advertised CIDR may bypass the tunnel entirely. Include your routed range in the Cloudflare One split tunnel settings, or the route you built in the last lesson silently never gets used.

Write the policy tight

Grant only the users, devices, destinations, and ports required. A Gateway network policy for one SSH server looks like this in intent:

Allow  destination IP 10.0.0.5, port 22  when user group is "ops"
Block  destination IP 10.0.0.0/29        everyone else

Policies evaluate in order, so the narrow allow sits above the broad block. Resist “allow the whole team to the whole subnet” as a first draft. It never gets tightened later.

Keep a recovery path while changing network policy. If the only way to reach the server is the path you are editing, one bad rule locks you out. Keep console access or a direct SSH path open until the policy is proven.

Test the denial

Test both allowed and denied identities; a successful route from one administrator does not prove least privilege. It proves the happy path, which was never in doubt.

Permit one operator to SSH to the private server and prove an ordinary test user cannot reach port 22. Log in as the test user on a second device, run ssh 10.0.0.5, and watch it fail. Then check the Gateway logs and find the block event. A policy you have only seen allow traffic is a policy you have not tested.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →