Cloudflare Tunnel Alternatives for MSP Remote Access: Browser RDP, SSH, and Whole-LAN Reach

Cloudflare Tunnel (the cloudflared daemon, formerly Argo Tunnel) has become a default answer to a hard problem: how do you reach a service behind CGNAT or a firewall with no open inbound ports? The tunnel dials outbound to Cloudflare's edge, holds the connection open, and your service becomes reachable through a public hostname. No port forwarding, no static IP. For an MSP or a homelabber, that is a genuinely useful pattern, and the free tier makes it easy to try.

But once you move from publishing a single web app to actually supporting a client site full of mixed devices, Cloudflare Tunnel starts to show its shape. It was built to put web applications in front of Cloudflare's CDN and WAF, not to give an engineer fast, ad-hoc access to every box on a LAN. This post covers where it fits, where it does not, and the router-tunnel alternative.

Where Cloudflare Tunnel Is Genuinely Good

If you are exposing an HTTP or HTTPS application, a self-hosted dashboard, an internal wiki, a web app you want behind Cloudflare Access, the tunnel is excellent. You get edge caching, a WAF, DDoS protection, and browser-only access to the web UI with no client software. For a public-facing web service that should sit behind Cloudflare anyway, it is hard to beat and the price is right.

Where It Falls Short for Device Access

Non-HTTP needs a client. HTTP hostnames work in a plain browser, but RDP, SSH, VNC, and arbitrary TCP do not. To reach those you either install the WARP client and build a Zero Trust private network, or run cloudflared access tcp on the engineer's machine to open a local listener. Either way there is now client software and per-connection setup on the accessing side, which is exactly the friction an MSP is trying to remove when a line is down at 3am.

It is a platform, not a workflow. Cloudflare Zero Trust can express almost anything, but you assemble it: tunnels, public hostnames, DNS records, Access applications, policies, and WARP enrolment. Doing that per client site, across dozens of sites, is real engineering time. There is no built-in notion of "this is client A's network, these engineers are scoped to it, log every session."

Traffic rides a global US CDN. For a European MSP handling patient data, POS systems, or anything under GDPR and NIS2, routing client sessions through a third-party global edge is a data processing question you have to answer. It is not disqualifying, but it is paperwork.

The Router-Tunnel Alternative

ProxyLink keeps the part of Cloudflare Tunnel that works, one outbound connection, no open ports, CGNAT-proof, and drops the per-service assembly. You install a single WireGuard tunnel on the site's router or gateway (MikroTik, pfSense, OPNsense, EdgeRouter, OpenWRT, or any Linux box). It dials outbound and holds itself open with a keepalive. From that point every IP on the LAN, and every declared VLAN behind it, is reachable, whether or not the device could ever run software. You do not run a daemon on each target and you do not add a DNS hostname per service.

What Engineers Actually Get

• Browser RDP, SSH, and VNC, full sessions in a browser tab with no client on the engineer's laptop and no WARP enrolment. No mstsc.exe, no PuTTY, no local cloudflared listener.
• HTTP and HTTPS proxy links to appliance web UIs, NVRs, PBX panels, Synology DSM, UniFi, pfSense, with origin handling tuned so appliance CSRF checks pass instead of failing behind a rewritten host.
• TCP and UDP links for RTSP video, SIP and VoIP, and PLC protocols like Modbus TCP, no desktop client required.
• MSP structure built in, teams, client groups, per-engineer scoping, an audit log of who reached which IP and port and when, and per-link session recording. Kernel-level WireGuard peer isolation means one client's tunnel can never reach another's.

The relay runs on EU infrastructure in Germany, on an open protocol, with no third-party remote-access network in the path, which keeps the compliance story short.

When to Use Which

If your goal is to publish a web application to the public internet behind a WAF, use Cloudflare Tunnel. If your goal is to give engineers instant, logged, browser-based access to every device across many client sites, RDP servers, network appliances, cameras, phone systems, and switches alike, a router tunnel is the shorter path. Many MSPs run both.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. One tunnel per client router, every device on the LAN reachable from a browser. Setup guides for MikroTik, pfSense, OPNsense, EdgeRouter, and OpenWRT are in the docs.