Cloudflare Tunnel vs Access: Do You Need Both?

Cloudflare Tunnel connects your application to Cloudflare. Cloudflare Access controls who reaches it. For a private home dashboard exposed through a public hostname, use both. A functioning tunnel alone does not add an identity check. Cloudflare’s application publishing guide explains this distinction.

Key Takeaways #

• Explain the route: distinguish the connector, origin, and identity check.
• Configure a policy: admit named people to one private dashboard.
• Evaluate protection: test allowed, denied, and alternate access paths.
• Design access: document separate requirements for visitors and automation.

Before You Begin #

Audience: home-server owners deciding how to protect a browser dashboard. The worked example assumes an active domain on Cloudflare, a working local web application, and permission to administer both. Estimated effort: 20–30 minutes for the policy exercise after connector setup. Difficulty: beginner to intermediate.

Reading path: start with the product roles, follow one request, then configure and review a small policy. Finish by writing an access specification for your own service.

What Each Product Does #

The origin is the server running your application. The cloudflared connector initiates connections from your infrastructure to Cloudflare, so the origin does not need a publicly routable IP address. Requests and responses then travel over the established connection. Cloudflare Tunnel overview .

An identity provider (IdP) authenticates the visitor. An Access policy defines an action and matching criteria. Allow admits matching users. Bypass disables Access enforcement for matching traffic. Access policy reference .

Follow One Browser Request #

For dashboard.example.com, the logical request path is:

Browser -> Cloudflare Access -> tunnel connection -> cloudflared -> dashboard
               |
               +-> identity provider when authentication is needed

The connector initiates the tunnel connection outward from your network. Browser requests then travel toward the origin over this established connection. An outbound connection carrying inbound application requests is the central reason Tunnel works without a conventional forwarded origin port. Tunnel connection model .

Application permissions remain another decision. Admission to a dashboard does not automatically specify who should edit its settings or delete its data. If the application has viewer and administrator roles, configure and test those roles separately.

For example, a family viewer needs permission to see backup status, while you need permission to change backup destinations. Write those requirements before selecting identities. Two people passing the same Access check should not automatically receive the same application privileges.

When You Need Both #

The audience determines the protection. Compare these arrangements before publishing a route:

Access without Tunnel is supported for an already reachable origin. Protect alternate routes to the server as well. Cloudflare recommends creating the Access application first when publishing a new tunnel route. Self-hosted application requirements .

For a private home dashboard reached through a public hostname, start with Tunnel plus Access.

Configure a Dashboard Policy #

Use this worked configuration for two intended visitors. Replace both example addresses with identities you control. Create the Access application before adding the public tunnel route.

1. Application: open Zero Trust → Access controls → Applications and create a self-hosted application with a public hostname.
2. Hostname: enter the dedicated dashboard hostname. Leave the path unrestricted for this whole-hostname example.
3. Policy: create an Allow policy named Dashboard viewers.
4. Identity selector: add an Include rule using Emails, with [email protected] and [email protected] replaced by your two intended addresses.
5. Login: select the identity provider used by those visitors and choose a deliberate session duration.
6. Route: save the application, then connect the hostname to the dashboard through your tunnel.

The official application workflow documents these settings. Expected result: a new visitor encounters authentication before reaching the application. Complete the denied-identity test below before relying on the policy.

Interpret the Rule Logic #

Include combines alternatives with OR. Require adds mandatory conditions with AND. Exclude removes matching users. Adding another Include condition broadens the eligible group. Access rule semantics .

Policy-review exercise: your requirement names only Alice and Bob, but your colleague adds a country as another Include condition. Reject the change because it admits an additional population. Geography does not establish membership in your household.

Authenticate Scheduled Scripts #

A service token contains a Client ID and Client Secret for automated requests. Configure the application policy to accept the token using Service Auth. Creating a token without the corresponding policy does not grant application access. Cloudflare service tokens .

For a backup script or monitoring check, keep the secret in the tool’s protected credential storage. Give each integration a distinct token name and a deliberate expiration date. Rotate or revoke its token when retiring the integration. The service-token documentation covers these lifecycle operations.

Client compatibility deserves an explicit check. A tool expecting an API response will not necessarily handle an interactive browser login. Confirm its support for request headers or another supported authentication method before choosing the policy.

Test Access Decisions #

Treat these as acceptance checks for your deployment:

A visible login screen proves only one path encountered authentication. Test the denied case and alternate routes too. These are suggested checks, not results from a deployed example.

Check the Origin Boundary #

An origin trusting Access identity should validate the signed application token. Cloudflare forwards it in the Cf-Access-Jwt-Assertion header. A header’s presence alone does not prove authenticity. Cloudflare JWT validation .

A JSON Web Token (JWT) carries signed claims. Use the documented validation approach, including the expected issuer and application audience, when integrating Access identity into an origin. Decoding a token and reading an email field is insufficient validation.

Issuer identifies the authority issuing the token. Audience identifies its intended application. Check token validity and expiration through a supported validation library, instead of implementing signature checks from scratch.

Keep the boundary explicit: identify where validation happens and which routes reach the application. An old port forward or alternate hostname deserves its own review, even after the main hostname passes every browser test.

Troubleshoot Policy Mismatches #

Session behavior also affects retesting. Access has several session durations, including application and global sessions. Record the session setting and use a fresh session when checking a new identity. Access session management .

Write Your Access Specification #

Create a short specification before adding another service:

Service and hostname:
Human identities allowed:
Application roles required:
Automation credential and expiry:
Other routes to the origin:
Where Access tokens are validated:
Allowed-identity test result:
Denied-identity test result:

Completion criterion: another administrator should understand who gets access, how each client authenticates, and which evidence proves denial. If you add a monitoring integration later, update its credential entry and repeat the unauthenticated request check.

Next Steps #

Follow the site’s Cloudflare Tunnel setup guide for connector setup, then apply the official Access application workflow . For a cellular connection, read T-Mobile Home Internet port-forwarding limits before choosing your remote-access route.