Reach TCP forwards: any service on your machines, with nothing exposederic

Reach RDP got a lot of attention as a way to reach a remote desktop without exposing port 3389. But RDP is really just one service riding a more general capability. Reach forwards any TCP service on a machine you've shared to a local port on the machine you're sitting at — and once you see it that way, the desktop is only the most visible example.

The question that usually comes after "how do I remote into that PC?" is "...and how do I get to the database on it? The file share? The admin page for the NAS? The licence server the accounting software phones home to?" The honest answer with most tools is: open another port on the router, or stand up a VPN and hand over the whole network. Reach's answer is the same as it is for RDP — forward the one service, over an identity-gated path, with nothing exposed.

What a forward actually is

A forward in Reach is three things: a remote host, a remote port, and a local port that Reach opens on 127.0.0.1 for you. You add it against a machine that has turned on "Share this PC," and Reach stands up a listener on your loopback — say localhost:15432. Anything you point at that local port is carried, byte for byte, to host:5432 on the far machine.

That's the whole model. Your Postgres client connects to localhost:15432; as far as it's concerned the database is running on your own machine. psql, DBeaver, a JDBC string, smbclient, a browser pointed at a router's web UI — none of them know or care that the bytes are travelling through a tunnel to a box behind NAT in another state.

Reach knows a couple of protocols well enough to do the launching for you: pick an RDP forward and it writes the .rdp and opens mstsc; pick an SSH forward and it opens a terminal at the local port. Everything else is a plain TCP forward with a "copy localhost:port" button — you paste that into whatever client the service needs. The protocol is yours; Reach just moves the bytes.

RDP or a bare forward? Same door, two ways through

Worth being explicit, because the question comes up the moment you've read the RDP piece: Reach RDP is a TCP forward — of port 3389, with a generated .rdp written and mstsc launched at it. "Share this PC" is the one mechanism; the full desktop and a bare forward are two things you do with it. The only real choice is how much of the machine you want.

• The full desktop (RDP). You get the whole graphical machine — every app, the GUI, the screen. Reach for it when you need to operate the machine: run a Windows app, click around a GUI tool, do something there's no client or command line for. The costs: it needs a desktop-capable host (Windows Pro/Enterprise — Home can't host RDP), it's heavier on the link because it's carrying a rendered screen, and it takes over the interactive session.
• A single service (a forward). You get one port — the database, the share, the admin page — and drive it with your own local client. Reach for it when you only need the one thing: it's lighter, it works against Linux boxes, NASes and appliances that have no "desktop" at all, you can run several in parallel, and it doesn't tie up anyone's screen. The cost is the mirror image: it's that one service, not a view of the machine — so if what you need is to see and drive the desktop, that's RDP's job.

Rule of thumb: need to see the screen → RDP; need to reach a service → a forward. Often you want both to the same box, and Reach runs them side by side — an RDP forward and a database forward to the same server are just two entries in the list.

The substrate is the same one RDP uses

Because a forward is just a tunnelled TCP stream, it inherits everything the RDP path already does:

• Nothing exposed, nothing forwarded. The far machine makes an outbound control connection to Reach and waits. There's no inbound firewall rule, no public port, no static IP. Your connection is matched to the machine by identity, not by an address anyone can scan.
• P2P when it can, relay when it can't. If your device and the target are on the same subnet, the forward goes peer-to-peer and the gateway never sees the bytes. Otherwise it rides the gateway relay. Same decision, same code, as every other Reach connection.
• Tuned for interactive traffic. TCP_NODELAY on the relay sockets and immediate flushing, so a database session or an SSH shell doesn't feel like it's wading through treacle — the thing that makes a naive tunnel miserable is buffering, and we don't.
• Scoped sharing. A shared machine can advertise more than one service, and you grant a specific forward to a specific person. A contractor can get the one port they need and nothing else on the box.

What you'd actually use it for

The list is basically "anything that listens on a TCP port":

• A database — Postgres, MySQL, SQL Server — reached by your normal client, without the database ever being open to the internet (which is how a depressing number of them get ransomwared).
• A file share (SMB/445) on the office NAS or a server, mounted from home.
• The web admin panel of something that should never face the internet: a NAS, a router, a managed switch, a printer, a Proxmox or Home Assistant box, a UniFi controller.
• A licence server or an internal API that a desktop app or a dev environment needs to reach.
• Git over SSH, or any other SSH-based workflow, to a box with no public SSH port.

The honest limits

• It's TCP. Forwards carry TCP streams. Real-time UDP apps — game servers, some VoIP, anything latency-sensitive over datagrams — are a different path; that's what Reach's adaptive UDP relay is for.
• Reach carries bytes; it doesn't replace the service's own auth. A forwarded database still wants its own username and password; a forwarded admin panel still wants its login. Reach gates who can open the tunnel; the service gates what they can do once inside. That's the right split — defence in depth, not a single gate.
• It's for machines you own or manage. The far end has to run "Share this PC" and advertise the service. This is for your fleet, your servers, your team — not for poking at a port on a stranger's network.

The headline is the same one that mattered for RDP, just generalised: you can reach any service on any of your machines, from anywhere, with the client you already use — and leave nothing listening on the public internet.

TCP forwards are part of TYO Reach. Already a Reach user? Add one from the tray under "Forwards." New to Reach? Start here.