# https://tunnels.io/use-cases/remote-desktop

[Home](https://tunnels.io/) / [Use cases](https://tunnels.io/use-cases) / Remote desktop

Use cases

# Remote-desktop into a machine with no public address.

The desktop at home or in the office sits behind NAT with no public IP. A raw TCP tunnel gives its RDP or VNC port a public host and port, so you can reach it from anywhere without touching the router. TCP starts on Professional at $4 a month.

[Get started →](https://tunnels.io/get-started) [See pricing](https://tunnels.io/pricing)

## Two ports, one command

Only two cases matter. Windows Remote Desktop listens on TCP port `3389`. Most VNC servers listen on TCP port `5900`. Both are plain TCP streams, carried the same way.

```
# on the Windows box you want to reach
$ tunnels tcp 3389
Active Tunnels:
▸ tcp://tunnels.host:41337 → 127.0.0.1:3389  [tcp]
# or a machine running a VNC server
$ tunnels tcp 5900
```

What comes back is a host and a port, not a name you chose. A raw TCP listener has no equivalent of SNI, so there is nothing in the connection for the edge to read a hostname out of, and the assigned port is what identifies your tunnel. Reserved subdomains shape HTTPS hostnames and do not apply here. Read the port off the line the client prints.

Nothing changes on your side beyond that. The Computer field in the Microsoft Remote Desktop client takes `tunnels.host:41337` instead of a LAN address, and a VNC viewer takes the same.

The connection is opened outward, from the host to us, which is why no inbound port has to be open. That is the whole trick, and [the mechanics of an outbound control connection](https://tunnels.io/learn/what-is-a-reverse-tunnel) are worth ten minutes.

## How does this compare with the alternatives?

The approaches people reach for, on the four things that decide.

| Approach | Needs router access | Software on both ends | Session survives a host reboot | Cost |
| --- | --- | --- | --- | --- |
| RDP over a tunnels.io TCP tunnel | No | Host only. Any RDP client on your side | No. The route returns if the client starts at boot | Professional, $4/mo |
| VNC over a tunnels.io TCP tunnel | No | Host only. Any viewer on your side | No. Same as above | Professional, $4/mo |
| Commercial remote-desktop SaaS | No | Yes. Vendor agent and vendor app | No. The agent restarts with the OS | Per-seat subscription set by the vendor |
| VPN back to the network | Usually, to publish the endpoint | Yes. A client on every machine | No. The interface returns if enabled at boot | Free self-hosted, otherwise per user |
| Router port forwarding | Yes, plus a stable IP or dynamic DNS | No. Only RDP or VNC itself | No. The rule persists in the router | Nothing, at much higher exposure |

No remote-desktop session survives a reboot of the machine it runs on. The fourth column measures whether the machine becomes reachable again unaided.

A mesh VPN is right when every machine should see every other machine, and heavy for one port, once a week, from a laptop that is not yours. Our [side-by-side with Tailscale](https://tunnels.io/compare/tailscale) sets out where the line falls.

## Why is RDP on a public port scanned constantly?

Because it is worth a great deal to whoever finds it. Port 3389 open to the internet is one of the most profitable things a scanner can discover, so it is swept for continuously. A machine you port-forwarded this morning takes login attempts by the afternoon.

Four habits do most of the work. Leave Network Level Authentication on, so a caller authenticates before a session is set up at all. Sign in with a purpose-made local account, not Administrator. Give it a long password used nowhere else. And run the tunnel only while you need it: a port published twenty minutes a week is a target twenty minutes a week.

The protocols differ underneath. RDP negotiates its own encryption between your client and the host. Most VNC servers offer a weak challenge-response and no transport encryption, so expose a VNC port deliberately and briefly.

## What latency should you expect?

Worse than a LAN, and we would rather say so. Keystrokes travel to our edge, down the tunnel to the host, and screen updates return the same way. That is a hop the traffic would not otherwise take, and no engineering removes it.

It sorts into two piles. Administration is fine: editing a config file, restarting a service, clicking through an installer, checking a build. The interface feels a beat behind and you stop noticing. Anything redrawing the screen continuously is not: video, 3D work, games, scrubbing a timeline. If you are waiting for the picture, a faster tunnel is not the answer.

## What happens when the tunnel reconnects?

The client reconnects on its own, backing off exponentially with jitter, and it honours a reconnect delay the server can send so a restart does not bring every client back at once.

What does not survive is the TCP connection your viewer held. The viewer will say so. Reconnect once the tunnel is back and you land in the same session, because the host kept it running.

A reserved subdomain will not hold the address still, because a reserved subdomain shapes an HTTPS hostname and a TCP tunnel has no hostname of its own. What you get back on reconnect is a port. The client asks for the one it held and usually gets it, and if you want it guaranteed, give the tunnel a name in the config file and set `remote_port`. That is the only way to pin it; there is no command-line flag for it.

## How do you keep it running without a terminal open?

A tunnel started in a terminal dies with it, and you cannot restart it on a machine you cannot reach. Save the tunnel in the client config so it has a name, then let the system start it at boot. On Linux, an ordinary unit file:

```
# /etc/systemd/system/tunnels.service
[Unit]
After=network-online.target
[Service]
ExecStart=/usr/local/bin/tunnels --log stdout start-all
Restart=always
[Install]
WantedBy=multi-user.target
```

On Windows the client is a plain executable with no service installer, so wrap it. A scheduled task set to run at system startup, with highest privileges and independent of anyone being logged on, is the least fuss; NSSM or WinSW does the same with better restart handling. Test it by rebooting while you are next to the machine. Note that `tunnels start-all` brings up every named tunnel at once, each counting against your tunnel limit.

## Which plan you need

Professional, at $4 a month or $40 a year. Raw TCP carries RDP and VNC, and TCP starts on Professional. The free Basic and Student plans are HTTPS only, so neither can open a TCP tunnel at all.

Professional

$4/mo

Raw TCP, five tunnels but only one of them TCP, three reserved subdomains, 128 GB a month.

Gold

$10/mo

Ten tunnels, 256 GB, and custom domains on a name you own.

Premium

$20/mo

Unlimited tunnels, 512 GB, permanent names, no lease to renew.

Annual billing is $40, $96 and $192. A 24-month prepay is $72, $144 and $288. [/pricing](https://tunnels.io/pricing) is authoritative.

## What this does not do

We move a TCP stream between your machine and a public address. We are not a remote-desktop product.

- No RDP or VNC implementation. You bring the server and the viewer. We do not draw a screen, share a clipboard or transfer a file. If Remote Desktop is disabled on the host, a tunnel to 3389 reaches a closed port.
- No session recording. No capture, no replay, no audit trail of a session. If you must record remote access for compliance, this is not it.
- No IP allowlist. A published TCP address is reachable from anywhere. No allowlist, no OAuth and no single sign-on at the edge, and `--httpauth` is an HTTP feature that does nothing for TCP. Access control is the host's job.
- No UDP, so no UDP-accelerated RDP. Our engine carries HTTPS and raw TCP and nothing else. Modern Windows clients use a UDP transport for smoother graphics, and it is not carried here. RDP falls back to TCP on its own, so everything works and you lose the acceleration. This is the limit you will feel.

## Questions

### Can I use Remote Desktop without port forwarding?

Yes. The tunnel client runs on the machine you want to reach and opens a connection outward to us, which gives port 3389 a public host and port. Nothing inbound has to be allowed on the router, and your RDP client connects to that address, not a LAN one.

### Do I need a paid plan for RDP or VNC?

Yes. Both need a raw TCP tunnel, and TCP starts on Professional at $4 a month or $40 a year. The free Basic and Student plans carry HTTPS only. Reserved subdomains, which Professional also includes, apply to HTTPS hostnames rather than TCP ports, so what makes the address savable here is pinning `remote_port` on a named tunnel in the config file.

### Does this work with any RDP or VNC client?

Yes, as long as the client lets you type a hostname and a port. The tunnel is a plain TCP stream, so the Microsoft Remote Desktop client, Remmina, FreeRDP, RealVNC and TigerVNC behave as they do on a LAN. Nothing is installed on the machine you sit at.

### Is UDP-accelerated RDP carried through the tunnel?

No. The engine carries HTTPS and raw TCP only, with no UDP support of any kind. RDP detects this and falls back to its TCP transport, so the session works normally, but you lose the smoother graphics path UDP gives on a LAN.

### What happens to my desktop session if the tunnel drops?

Your viewer disconnects and the client reconnects the tunnel by itself, using exponential backoff with jitter. The session on the host keeps running, so reconnecting puts you back where you were. The client asks for the port it held before and normally gets it back; pin `remote_port` on a named tunnel in the config file if you want that guaranteed.

## Related reading

[SSH to a machine behind NAT The same TCP tunnel on port 22, when a shell is enough.](https://tunnels.io/use-cases/ssh) [Publishing a home lab Several services off one box, kept up across reboots.](https://tunnels.io/use-cases/homelab) [tunnels.io vs Tailscale A private mesh between your devices, against one public port.](https://tunnels.io/compare/tailscale) [The outbound connection, explained Why a connection opened from inside lets traffic in from outside.](https://tunnels.io/learn/what-is-a-reverse-tunnel) [Four ways to publish a local port Tunnels, SSH forwarding, router rules and deploying, compared.](https://tunnels.io/learn/how-to-expose-localhost)

One command on the machine you want to reach.

Install the client, sign in, run `tunnels tcp 3389`, connect from anywhere. TCP is on Professional, $4 a month.

[Get started →](https://tunnels.io/get-started) [See pricing](https://tunnels.io/pricing)