Remote Desktop Across NAT and Firewalls (Without Port Forwarding)

中文版本： 《不用端口转发也能跨 NAT / 防火墙远程》

If a remote desktop tutorial in 2025 tells you to "forward port 3389 on your router," close the tab. Port forwarding is a 1990s solution to a problem that has better answers now — and it opens your network to the entire internet in exchange.

This post explains how modern remote desktop tools cross NAT and firewalls automatically, and why you should never punch holes in your router again.

What Port Forwarding Actually Costs You

When you forward a port, you tell your router: "any traffic to my public IP on port 3389, send it to my workstation." Two problems:

The entire internet can reach that port. Botnets scan all 4 billion IPv4 addresses every few hours. Within 24 hours of opening RDP to the internet, you'll see thousands of login attempts.
Your home or office network's perimeter just got a new hole. Any vulnerability in the remote desktop service is now exposed to everyone.

The 2017 BlueKeep CVE alone exposed an estimated 800,000+ internet-facing RDP servers to wormable remote code execution. They didn't need to be open. They were opened on purpose, by people following bad tutorials.

What Modern Tools Do Instead

Two devices behind their own NATs can talk to each other directly, as long as the connection is initiated correctly. The trick is called NAT traversal, and it uses three protocols working together:

STUN — "What's my public IP?"

STUN (Session Traversal Utilities for NAT) lets a device behind NAT ask a public server: "what does my traffic look like from your side?" The server replies with the IP:port the NAT is mapping to. Now the device knows its public address.

Client (192.168.1.5:54321) ──► STUN server
                            ◄── "You look like 203.0.113.7:48201"

ICE — "Let's try every path"

ICE (Interactive Connectivity Establishment) collects all the possible addresses for a device — local IP, public IP via STUN, relay IP — and exchanges them with the peer through a signaling server. Both sides try every combination until one works.

TURN — "When all else fails"

TURN (Traversal Using Relays around NAT) is the fallback. If ICE can't find a direct path (typically symmetric NAT on both ends), traffic goes through a TURN relay. This is still encrypted end-to-end in a properly designed tool — the TURN server can't read the contents.

Why It Works

Once both sides know each other's public IP:port and both have sent a packet out through their NAT, the NAT entries stay open long enough for return traffic. This is sometimes called "UDP hole punching."

Client NAT mapping table:        Server NAT mapping table:
54321 → 203.0.113.7:48201        53000 → 198.51.100.4:39102

Each side sends one packet outbound.
Now both NATs allow return traffic on those mappings.
The peers can talk directly.

It sounds fragile. In practice, this works for the majority of internet connections.

When It Fails

NAT traversal fails when:

Both endpoints are behind symmetric NAT (rare on home routers, common on cellular carriers and some corporate networks).
The network blocks UDP entirely (some highly restrictive corporate firewalls).
The signaling server can't be reached (rare; usually means a misconfigured outbound proxy).

A serious tool falls back to TURN automatically and keeps the session working. See NAT Traversal Failed? for diagnostics if you hit this.

What This Means for You

You don't need to touch your router. Don't.
You don't need to set up a VPN just for remote desktop.
You don't need a public IP address.
A properly designed tool gets a session up from any network with outbound internet access.

This is the single biggest difference between a 2025 remote desktop tool and the RDP-via-port-forwarding setups of the 2010s.