Cloud & Infrastructure / Deep Dive
REMOTE ACCESS
Reach internal servers, NAS, dashboards, and home labs from anywhere — without a static IP, without opening ports, without exposing the network.
Reachable from anywhere, exposed nowhere
Most office networks, branch sites, and home labs sit behind a router that does not have a static public IP. Traditionally that meant choosing between exposing the network through port forwarding (cheap, dangerous) or running a corporate VPN (more secure, more friction). A modern alternative — Cloudflare Tunnels paired with Zero Trust access policies — replaces both. A small daemon inside the network opens an outbound connection to Cloudflare's edge, and authorised users reach the internal service through a public hostname they sign into. No inbound port is opened on the router, no static IP is needed, and access can be scoped per user, per device, and per application. This guide explains how the pattern works and where it fits.
Inbound ports opened
Zero
Static IP required
No
Auth surface
Per-app, per-user, per-device
How a tunnel actually works
A lightweight connector runs on a host inside the network — a NAS, a small VPS, a Raspberry Pi, or directly on the server you want to reach. It opens a long-lived outbound TLS connection to Cloudflare's edge. When an authorised user requests the public hostname, Cloudflare proxies the request through that outbound connection to the internal service.
- Outbound TLS only — no inbound firewall rules
- Public hostname maps to an internal service
- TLS terminated and re-encrypted at the edge
- Survives ISP IP changes automatically
How access is gated
The tunnel is paired with a Zero Trust policy that decides who can reach which application. Identity comes from the provider you already use — Google Workspace, Microsoft 365, GitHub, an email-OTP, or a self-hosted IdP — not a separate VPN credential.
- Per-application access rules, not network-wide trust
- Identity provider integration (SSO, email OTP, mTLS)
- Session length and device posture controls
- Audit log of every authenticated request
When to use a tunnel instead of a VPN
A traditional site-to-site or client VPN puts a user on the network. A tunnel-and-policy setup puts a user on a single application. For most modern teams the second model is closer to what they actually want: one engineer needs the internal Grafana, one finance lead needs the office accounting tool, the on-call engineer needs SSH to a single VM. None of them need full network reachability, and giving them full network reachability is how lateral movement happens during a breach. Tunnels let you publish only the specific service, scope access by identity, and revoke it without touching firewall rules or VPN configurations. The setup is also dramatically friendlier on mobile and on networks that block UDP — the user just opens a URL and signs in.
Common scenarios this solves
The pattern fits almost any case where a network without a static IP needs to publish something internal. Examples that land on this service in practice: reaching a Synology or TrueNAS file server from outside the office, exposing a self-hosted ERP or CRM under a custom domain, giving a remote contractor temporary access to a single internal app, putting SSH behind an SSO login instead of a public IP, fronting a home-lab Plex or Home Assistant with an authenticated URL, and replacing a flaky branch-office VPN with a per-app rule. In each case the underlying network stays unreachable from the public internet, while the specific service gets a clean, signed-in URL that works from any device.
Got a service stuck behind a CGNAT?
If the ISP gives you a shared IP and refuses to forward ports, a tunnel is usually the cleanest fix. Send us the service and we will scope the setup.
Plan a tunnel deploymentSame-day for one app
Setup time
Google, Microsoft, GitHub, OTP
Identity providers
Zero ports
Inbound exposure
FAQ
Frequently asked questions
Answers built for decision-makers who need clarity before committing.
A free Cloudflare account covers the tunnel itself. Zero Trust access policies have a free tier that comfortably handles small teams. Paid plans add more identity provider integrations, longer log retention, and higher seat counts. Most small businesses start on free and only move to a paid tier when they exceed the free seat count.
What happens if my home or office internet goes down?
The tunnel disappears with the outbound connection — it is fundamentally a relay through your internet uplink, not a replacement for it. For high-availability scenarios, two connectors on two different links (e.g. fibre + LTE) keep the tunnel up if either one fails, and Cloudflare load-balances between them automatically.
Is this safer than just port-forwarding?
Considerably. Port forwarding exposes a service to every IP on the public internet, where it is scanned within minutes. A tunnel never opens an inbound port on your router, the service is only reachable through Cloudflare's edge, and the access policy requires authenticated identity before the request even hits your network. The exposed surface drops from 'every attacker on the internet' to 'authenticated members of your team'.
Can I keep using my existing VPN for some things?
Yes. Tunnels are usually deployed alongside an existing VPN, not as a replacement on day one. The pattern most teams settle on is: VPN stays for full-network access by trusted admins, tunnels handle per-application access for everyone else. Over time, the VPN gets used less and the tunnel set grows — but there is no forced migration moment.
Will SSH and remote desktop work through a tunnel?
Yes. SSH works through a short client command that wraps the connection through the tunnel, and remote-desktop protocols (RDP, VNC) can be published as authenticated web URLs. Both are gated by the same Zero Trust policy as any other application.
Can I revoke access for one person quickly?
Yes — that is one of the strongest arguments for this pattern. Revocation is a single change in the access policy, takes effect on the next request, and applies across every application the policy gates. There is no certificate to rotate, no shared VPN secret to change, and no firewall rule to edit.
One service, one signed-in URL.
Tell us what's stuck behind a router with no static IP — a NAS, a self-hosted app, an internal dashboard, an SSH host — and we will publish it through an authenticated URL.
Set up secure remote accessContinue exploring
Each guide stands alone, but the full picture is built from all four. Pair this with the related deep dives or jump back to the Cloud Hosting & Infrastructure pillar.
Self-hosted business tools on VPS
Run your own CRM, ERP, file drive, and team apps on a private VPS — and publish them through tunnels.
Read this guide →Disaster recovery & backup solutions
Pair the access layer with backups: even if a host fails, the data restores cleanly.
Read this guide →Domain name & professional email setup
Run the tunnels under your own domain, with proper email authentication on the same brand.
Read this guide →