Zero Trust is a decision to stop treating network location as proof of identity. A broadly configured VPN can give an authenticated user access to an entire internal subnet; a narrower design authorizes access to specific applications. A zero trust tunnel deployment combines the connection with that authorization decision: who is this identity, what device are they on, and is that combination allowed to reach this application.
Outbound tunnels remove inbound ingress
The first structural change is how traffic reaches your application. Instead of opening a port on a firewall and publishing a public IP, you run a lightweight connector inside the network next to the service. That connector dials outbound to the edge and holds the connection open. With Access configured for the published application, requests are authorized at the edge and handed down the existing outbound connection.
The practical consequence is that the origin does not need a listening port exposed to the Internet or a static public address. Remove old inbound rules to realize that benefit. The published hostname remains reachable, so it still needs authentication. The application does not have to move; the connector reaches it over the internal network the same way any other internal client would.
Route definitions map a public hostname to an internal address the connector can reach. Keep those mappings narrow. Private network routes can cover a range, but their reachability needs a separate policy decision; a route alone does not establish least privilege.
The mechanics of getting a connector running, including the outbound port it needs and the ingress rules that decide what it will serve, are covered step by step in Cloudflare Tunnel setup: your first tunnel.
For CGNAT, native protocols and the remaining origin exposure, Cloudflare Tunnel vs port forwarding explains the connection choices before you add policy.
Access, Gateway and Tunnel: where each product starts and stops
Treat these as separate responsibilities when designing the deployment. A healthy connector proves a connection exists; it does not establish who may use it.
| Product | Responsibility | What to configure separately |
|---|---|---|
| Tunnel | Connects Cloudflare to an origin through outbound cloudflared connections | Application authentication and who can reach each route |
| Access | Enforces access policies for configured applications | Origin connectivity and protection against direct origin access |
| Gateway | Filters traffic sent through its DNS, network or HTTP controls | Client routing, DNS settings and the policies for each traffic type |
For a published internal website, Tunnel can provide the connection and Access can require an identity provider login. Cloudflare’s self-hosted application instructions recommend creating Access protection before publishing the route. Installing the connector alone does not add a login screen.
Gateway traffic policies govern traffic routed through that service. DNS policies can block resolution, network policies can control connections, and HTTP policies can inspect web requests when the required traffic handling is configured. Those controls serve a different role from an Access application policy.
The endpoint component is the Cloudflare One Client. Its mode determines whether it routes traffic, forwards DNS, or only reports posture. The WARP client explanation covers these choices. A browser-only application and a managed laptop reaching private services can therefore use different combinations of the same products.
Policies are identity plus context, not IP ranges
An access policy answers a single question: should this request be allowed. The inputs are the authenticated identity from your identity provider, the group or role membership carried in that token, and signals about the device and the request itself.
Integrating an identity provider makes this workable. Keep account lifecycle, group membership and multi factor enrollment there. Access uses identity information to evaluate application policies. Account disablement should be paired with a review of existing sessions; Cloudflare’s session management documentation explains session duration and revocation. Do not assume an already issued session disappears immediately after an identity-provider change.
Write policies against groups, not individual users. Individual grants accumulate silently and nobody audits them. Group based rules stay legible and get reviewed as part of normal identity governance.
Whether a proxied policy engine is the right shape for your fleet at all is the subject of Cloudflare Access compared with Tailscale.
How Access evaluates a policy: Include, Exclude, Require, and why Bypass runs first
Cloudflare’s Access policy reference separates rule matching from policy actions. Within a policy, Include supplies alternative matches (OR), Require adds mandatory conditions (AND), and Exclude removes matches (NOT). A request needs an Include match, all applicable Require conditions and no Exclude match. An Exclude condition removes eligibility for that policy; it does not replace an application-wide Block policy.
For example, an Allow policy might Include a maintenance group, Require an approved device posture check and Exclude a suspended group. That expresses membership plus a mandatory device condition. Putting the device check in a second Include instead would create an alternative way to match, undermining the intended requirement.
Across policies, Bypass and Service Auth run first in their displayed order. Block and Allow then run in their displayed order. Once an Allow or Block matches, evaluation stops. There is no universal rule that all Allows precede all Blocks, and a lower restrictive policy cannot undo an earlier Allow.
Bypass removes Access enforcement for matching traffic and does not produce Access request logs. It cannot use identity selectors. It is therefore unsuitable as a general exception for internal users who have trouble signing in. Service Auth is the separate action for machine authentication; choose the appropriate credential mechanism instead of removing enforcement from an automated caller’s route.
When reviewing a policy change, write down three expected outcomes: an approved group member on a compliant device, the same member on a failing device, and a user outside the approved group. Check the whole policy list against each case. This suggested review method exposes an earlier permissive policy that would otherwise make a carefully written Require rule irrelevant.
What device posture can and cannot check
Device posture supplies additional signals about an endpoint. Cloudflare’s client-check matrix lists OS version and Require WARP across its supported desktop and mobile platforms. Disk encryption checks cover Windows, macOS and Linux; the firewall check covers Windows and macOS; the antivirus check is Windows-only. Check platform support before requiring the same signal from every device.
These checks need the managed client deployed and the desired checks enabled. A browser login on an unmanaged device cannot by itself supply a client-side disk-encryption result. Third-party endpoint integrations are another source of posture signals, documented separately in the posture overview.
A passing check answers the configured question. An OS-version result does not prove that a device is free of malware, and encryption at rest does not decide which applications its user should reach. Keep identity and application authorization in the policy alongside posture. Treat the result as an input with a defined scope, rather than a blanket trust decision.
Client mode matters too. Posture only mode reports health without routing traffic or DNS through Cloudflare. Requiring an appropriate posture result and requiring traffic through Gateway are distinct conditions; one does not automatically imply the other.
As a rollout recommendation, enable the intended checks for a small managed device group and inspect their results before attaching a mandatory condition to a critical application. Resolve unsupported platforms and enrollment problems first. Then verify both a passing and failing device against the protected application, with a documented recovery path for administrators.
Common mistakes
The most frequent one is lifting and shifting a VPN. If every application ends up behind one broad policy that says any employee, you have rebuilt flat network access with a different login page. Segment by application sensitivity from the start.
The second is forgetting non browser traffic. Web applications are the easy case. SSH, RDP, databases, and internal APIs need their own handling through the device client or through protocol aware routing, and teams often leave a legacy VPN running indefinitely just to cover them. That legacy path becomes the weakest link.
The third is skipping logging. Per request authorization produces a decision log that tells you who reached what and when. Ship it somewhere durable before you need it for an incident, not after.
The fourth is treating the connector as infrastructure that looks after itself. A single daemon running in a terminal on one host is a single point of failure for every application behind it, and when it stops, users get an error page rather than a degraded experience. Cloudflare error 1033 and how to fix a broken tunnel walks through why connectors disappear and which redundancy actually helps.
Start with one internal application, put it behind identity and a narrow policy, confirm the origin port is closed from outside, and expand from there.
