AllTech
01
Open inbound ports
RDP on 3389, a NAS admin page, a camera NVR, a line-of-business app on a nonstandard port. Scanned continuously, brute-forced routinely.
Cloudflare Partner · SASE Solutions
Reach your own infrastructure
without publishing it to the internet.
Every port you forward is a door with a sign on it. Private cloud routing replaces that model: a lightweight connector inside your network makes an outbound-only connection to Cloudflare, and authorized users and sites reach your servers through it. Nothing is listening on a public IP, because nothing needs to be.
Cloudflare Partner
No inbound ports
Identity-aware
Local engineers
01 · The problem
Port forwarding was never a security model.
Almost every network we inherit has at least one of these. They work. They also mean the internet can reach your server, and the only thing between the two is a password and hope.
02
A flat VPN
Once a user is on, they're on the network — every subnet, every share, every device. A stolen credential inherits the whole thing.
03
VPN concentrator at the edge
A public listener that has to be patched promptly and sized for peak load, and that becomes a headline every time a CVE lands.
04
Vendor access nobody tracks
A machine-tool vendor, an ERP consultant, and a former contractor with a static-IP allow rule that's been in the firewall since 2021.
05
Overlapping IP ranges after a merger or a second site
Both offices are 192.168.1.0/24 and nothing routes cleanly between them.
06
Site-to-site VPN that drops
Two firewalls arguing over an IPsec tunnel that fails during business hours and comes back before anyone can look at it.
02 · What we deploy
Cloudflare Tunnel and private network routing.
A connector daemon (cloudflared) runs inside your
network — on a VM, a server, or a container — and dials out to the Cloudflare edge over an
encrypted connection. Traffic for your internal resources travels back down that
connection. Your firewall keeps zero inbound rules for it.
01
Outbound-only connectors
cloudflared establishes the connection outward. No public IP, no NAT rule, no listener to attack. Deployed with multiple replicas so a single host reboot is not an outage.
02
Private network routes
Internal CIDR ranges published into Cloudflare, so client devices can reach IPs and internal hostnames as though they were on the LAN — without being on the LAN.
03
Virtual networks
Overlapping RFC1918 ranges handled properly. Two sites both running 192.168.1.0/24 stop being an architectural problem.
04
Public hostnames for internal apps
An internal web app published at a real hostname, with a Cloudflare-managed certificate and an Access policy in front — no DMZ, no reverse proxy to maintain, no origin exposure.
05
Identity- and posture-aware authorization
Who the user is (Entra ID, Okta, Google Workspace group membership) and what they're connecting from (OS version, disk encryption, managed-device check) both factor into whether the connection is permitted.
06
Service tokens & non-human access
Scripts, CI jobs, and vendor integrations get scoped, revocable credentials instead of a permanent firewall exception.
07
Browser-rendered SSH and RDP
Administrative access to a server through a browser session, logged, with no client software and no exposed port. Plan-dependent — see the limitations below.
08
Site-to-site via Magic WAN
Where the requirement is genuinely network-to-network rather than user-to-resource, we scope Magic WAN instead of stacking tunnels. Separate scope; we'll say so up front.
03 · What changes in practice
What you actually notice afterwards.
01
The firewall gets simpler
Inbound rules for remote access come out. Fewer moving parts, less to review, less to get wrong at 4 p.m. on a Friday.
02
Access becomes per-resource
A user is authorized for the ERP server, not for "the network." Revoking access is a policy change, not a firewall change.
03
There's a log
Every session is attributable to a person or a token, with a timestamp. Useful during an incident, and useful on an insurance questionnaire.
04 · Common deployments
What clients actually ask for.
01
Remote staff needing internal file shares and apps
WARP client + private network routes
Replaces flat VPN with per-resource authorization
02
Admin access to servers (RDP/SSH)
Tunnel + Access policy, optionally browser-rendered
Closes 3389/22 permanently
03
Internal web app for a hybrid team
Public hostname via tunnel + Access
No DMZ, no exposed origin, real certificate
04
Vendor or contractor access to one machine
Tunnel route + service token or scoped policy
Narrow, logged, revocable, time-boxed
05
Second site or post-merger overlapping subnets
Virtual networks
Resolves the IP collision without re-addressing
06
Plant-floor equipment that must not face the internet
Connector on a segmented VLAN
Reachable by the people who need it, invisible to everyone else
05 · How we engage
Three ways to start.
01
ASSESS · Remote access & exposure review
What's currently reachable from the internet, what the VPN grants, which vendors have standing access, and where the addressing problems are. Written findings and a migration plan. Stands alone as a deliverable.
02
DEPLOY · Tunnel & private network build
Redundant connectors, routes, virtual networks, identity integration, policy set, pilot, cutover, and decommissioning of the old inbound rules. Documented and handed over.
03
OPERATE · Managed private networking
Connector health and patching, policy and route changes, new-hire and vendor provisioning, session log review, and quarterly access review. Billed monthly.
06 · How the rollout goes
Three phases, and the ports close last.
- 01
Phase 1 · Week 1 · Connector and one resource
Stand up cloudflared with two replicas, publish a single non-critical internal app, and prove the path end to end. Existing VPN stays up untouched.
- 02
Phase 2 · Weeks 2–4 · Routes, identity, and pilot group
Publish the internal CIDRs, wire up the identity provider, set group-based policies, and move a pilot group of real users off the VPN. This is where we find the app that expects a specific source IP.
- 03
Phase 3 · Weeks 4–8 · Cut over and close ports
Move remaining users, migrate admin access, then decommission inbound firewall rules and the VPN concentrator — in that order, and not before. Closing the ports is the last step, because it's the one that's inconvenient to undo in a hurry.
Closing the old inbound rules is the point of the project. A deployment that leaves the VPN and the port forwards running alongside the tunnel has added a system without removing a risk. We'll push on this.
07 · Who this is for
Where it makes the most difference.
01
Anyone with RDP or a NAS reachable from the internet
This is the single highest-value change available to most small networks.
02
Hybrid and remote teams
Outgrowing a VPN that grants everything to everyone.
03
Multi-site and post-merger organizations
With routing and addressing problems that re-addressing alone will not fix.
04
Manufacturers
With equipment and vendors that need narrow, logged access.
05
Clinics and professional services
That have to answer "who reached that system, and when" with a record.
06
Anyone whose VPN appliance is out of support
Or on the wrong side of a recent CVE.
08 · Honest limitations
What this will not do for you.
01
The connector is infrastructure you now depend on.
cloudflared runs on a host that needs patching, monitoring, and enough resources. We deploy redundant replicas and monitor them; a single-replica install on a workstation under someone’s desk is not a design.
02
It is not a high-throughput file transfer path.
Traffic routes through the Cloudflare edge. For most business applications the difference isn't noticeable; for moving very large datasets between sites all day, it is. That's a Magic WAN or dedicated-circuit conversation.
03
Latency-sensitive and non-TCP protocols need scoping.
UDP and ICMP support over private routes has real constraints, and some industrial and legacy protocols assume LAN latency. We test the specific application rather than assuming.
04
Overlapping subnets need virtual networks, and virtual networks add complexity.
It solves the collision; it doesn't make the topology simpler. Documentation matters more here.
05
Some capabilities are plan-gated.
Browser-rendered SSH/RDP, seat counts, and certain policy features vary by Cloudflare tier. We'll tell you which tier your requirements actually need before you buy one.
06
Applications that key off source IP will need attention.
Some line-of-business apps and licence servers make decisions based on the client address. Those get identified in the pilot phase, and occasionally need a vendor conversation.
07
It doesn't secure the endpoint or the destination.
An authorized user on a compromised laptop still reaches what they are authorized for. Pair it with Endpoint Security.
08
It is not a backup or a resiliency strategy.
If the server is down, a tunnel to it is also down. See Backup & Disaster Recovery.
Related: Endpoint Security · Backup & Disaster Recovery
09 · FAQ
Common questions
Does this replace our VPN?
For most user-to-resource access, yes — that's usually the goal. We keep the VPN running in parallel through the pilot phase and decommission it once the tunnel is carrying real work.
Do we have to open any firewall ports?
No inbound ones. The connector needs outbound access to the Cloudflare edge, which most firewalls already permit.
What happens if the connector host goes down?
Nothing, if it's deployed properly. We run multiple replicas across separate hosts so a reboot or a failed VM doesn't take access with it.
Can our vendors use this without us installing anything on their machines?
Often, yes — an internal app published at a hostname with an Access policy needs only a browser and an email-based login. Full private-network access does require the client.
Will remote users notice it's slower?
Rarely, for normal application traffic — sessions are handled at the Cloudflare edge nearest the user rather than backhauled to your office. Bulk file transfer over a slow office upload link is still bounded by that upload link.
Can we still reach devices by internal hostname?
Yes. Internal DNS resolution is configured as part of the deployment so private hostnames keep working for users on the client.
Two of our sites use the same IP range. Is that a blocker?
No. Virtual networks let both ranges coexist without re-addressing either office.
Is this the same thing as Zero Trust Access?
They're two halves of one platform. Zero Trust Access is the authorization layer — who gets in. Private cloud routing is the transport layer — how the traffic gets there without an open port. We usually deploy them together.
On that last one, see Zero Trust Access (ZTNA) — the authorization half of the same platform.
10 · Related services
The rest of the stack it plugs into
01
Zero Trust Access (ZTNA)
The authorization layer that sits in front of these routes.
02
Cloudflare Zero Trust
The full Cloudflare One platform this belongs to.
03
Secure Web Gateway
The outbound half — same client, same policy engine.
04
DNS & DDoS Protection
For the resources you do publish publicly.
05
Endpoint Security
The device this can't vouch for.
06
Network & Infrastructure
The segmentation and edge this rides on rather than replaces.
07
Managed SOC
Humans reviewing the session and access logs.
Start with a conversation
Find out what's reachable from the internet right now.
Send us a short note about your environment. We'll walk your remote access setup, tell you which ports can be closed and in what order, and be straight with you about anything that genuinely still needs a VPN.
