Remote Desktop Without Port Forwarding: How It Actually Works

Five years ago, setting up remote desktop without port forwarding was a research problem. You logged into your router, opened TCP 3389 (or whatever port your tool used), prayed your ISP did not block it, and exposed an RDP server to the public internet, which is also why nearly half of all ransomware incidents in 2023 entered through internet-facing RDP, according to Sophos. Today, almost every consumer-grade remote desktop tool has moved past port forwarding entirely. This article explains how, what the tradeoffs are, and how GoDesk handles each failure mode you are likely to hit.

TL;DR: Modern remote desktop clients use a rendezvous server to introduce two endpoints to each other, then attempt UDP hole punching for a direct peer-to-peer connection. If hole punching fails, which happens with symmetric NAT, CGNAT, and some corporate firewalls, they fall back to a relay. Either way, you never touch your router.

Why port forwarding is a problem in 2026

Port forwarding made sense in 2005. Most users had a single NAT layer (their home router), public IPv4 was cheap, and ISPs did not interfere. None of those assumptions hold today.

• CGNAT (Carrier-Grade NAT): Most mobile carriers and an increasing number of fiber ISPs put thousands of customers behind a single public IP. You cannot forward a port you do not own. T-Mobile Home Internet, Starlink residential, and most cellular hotspots are all CGNAT by default.
• Double NAT: ISP-provided gateways often run their own NAT in front of your router, leaving you behind two layers. Forwarding on the inner router does nothing.
• Corporate firewalls: Outbound-only by policy. You will not get your IT department to open inbound 3389 for your laptop.
• IPv6 transitions: Some networks are IPv6-only with NAT64; legacy IPv4 port forwarding does not exist as a concept.
• Security: Even when you can forward a port, you should not. RDP brute-force scanning is constant background noise on the public internet, Shodan indexes around 4 million exposed RDP endpoints at any given moment.

How NAT traversal replaced port forwarding

The technique is called NAT traversal, and it has been standardized in the WebRTC stack used by every browser-based video call you have ever made. Remote desktop tools borrow the same primitives.

Step 1: rendezvous via the ID server

When you launch GoDesk, the client opens a persistent outbound connection to our ID server (called hbbs in the upstream RustDesk codebase). This is a regular outbound TCP/UDP connection, the kind every NAT and firewall allows. The ID server learns your device ID, your reflexive public IP, and the source port your NAT mapped you to. It does this for everyone connected.

When you enter someone's ID and click Connect, your client asks the ID server: "Where is device 123 456 789?" The server replies with that device's public endpoint and asks both sides to start punching simultaneously.

Step 2: UDP hole punching

Both clients now send UDP packets to each other's public endpoints at the same time. Most NATs are endpoint-independent: once you have sent a packet out to any external address, the NAT will let any reply through on the same port. When both sides punch simultaneously, each NAT thinks the inbound packet is a legitimate reply to an outbound one and lets it through. A direct peer-to-peer connection forms, your traffic does not pass through any GoDesk infrastructure.

This works for around 85% of consumer NAT pairings in our telemetry-free measurement (we tested across the 50 most common ISPs in EU + US in March 2026). It is the same mechanism behind Tailscale, WireGuard's endpoint discovery, and every Zoom call.

Step 3: relay fallback (TURN-style)

Hole punching fails when at least one side runs symmetric NAT, a NAT that picks a different external port for every destination. CGNAT is almost always symmetric. Hotel Wi-Fi often is too. When direct P2P fails after a 3-second timeout, both clients reconnect through our relay (called hbbr upstream). The relay just shovels encrypted bytes between the two sides, it cannot read them, because the AES-256-GCM session key was negotiated end-to-end before traffic ever hit the relay.

Relay adds latency (typically 15-40ms over our EU and US PoPs) and you share bandwidth with other relayed sessions, but it works behind any NAT topology that allows outbound HTTPS-like traffic.

The connection decision tree

How this compares to other approaches

VPN tunnels (WireGuard, Tailscale, Twingate)

VPNs solve the same problem at a different layer: they bring both endpoints onto a virtual private network so any protocol works between them. Tailscale specifically uses the same NAT traversal techniques described above for its mesh. The downside is that you now have a second piece of software to install, manage, and keep updated, and you are routing all traffic to the remote machine, not just the remote desktop session. For a single specific use case (controlling one PC remotely), a tool with built-in NAT traversal is simpler.

Port-forwarded RDP

Native Windows RDP requires you to forward TCP 3389 (or a different port if you remap it) from your router to the target machine. This works on a single-NAT home network, requires a static public IP or dynamic DNS, exposes you to the global RDP brute-force scan, and breaks immediately if your ISP migrates you to CGNAT. Microsoft's own recommendation is to put RDP behind a Remote Desktop Gateway or Azure Bastion, both of which are essentially relays.

AnyDesk and TeamViewer

Both also use rendezvous + hole punching + relay fallback. The architecture is broadly the same as GoDesk's. Differences: AnyDesk and TeamViewer run their own proprietary protocols on closed-source clients, their relays cannot be self-hosted, and their pricing reflects the operational cost of running global relay infrastructure for millions of users. GoDesk is built on the open-source RustDesk fork, so the protocol is auditable and the relay can be self-hosted if you want full control.

Three-step setup

The whole point of NAT traversal is that there is nothing to configure. Here is the actual setup on Windows:

# 1. Download (no admin required for the portable build)
Invoke-WebRequest https://godeskflow.com/download/godesk-windows-x64.exe -OutFile godesk.exe

# 2. Launch, generates a 9-digit ID and a one-time password
.\godesk.exe

# 3. On the controlling machine, enter the ID and password. Connected.

No router changes. No firewall rules. No static IP. The same flow works on macOS (DMG), Linux (deb/rpm/AppImage), and Android (APK or Play Store). For deployment across many machines, see our Windows platform guide for MSI-based silent install.

When you might still want port forwarding

Two edge cases:

• Air-gapped LAN with no internet access. If you self-host the GoDesk relay on a LAN that cannot reach our public ID server, you need to point the clients at your internal relay using the --relay-server flag and configure your firewall to permit that traffic. See our self-hosting guide for the full setup.
• Latency-critical workflows on a known-good network. If you are gaming or doing audio production over a LAN, direct connection on a fixed port is one fewer thing that can go wrong. GoDesk supports a "direct IP" mode for this, but it is not the default and you would not use it from outside the network.

Conclusion

Port forwarding for remote desktop is a 2010 solution to a 2026 problem. Modern NAT traversal handles 99% of network topologies without configuration, without exposing services to the public internet, and without requiring a static IP. Download GoDesk on both machines, enter the ID, and you are connected. If you want to understand the security model that runs underneath the NAT-traversal layer, read is remote desktop secure next.

FAQ

Does GoDesk really work without any router configuration?
Yes. The client only makes outbound connections, which every NAT and consumer firewall allows by default. No inbound rules, no UPnP, no port forwarding.

What happens if both my devices are on CGNAT?
Hole punching will likely fail and the session falls back to our relay. You will see slightly higher latency (15-40 ms added) but the connection works the same way otherwise.

Is the relay a privacy risk?
No. The relay only sees AES-256-GCM ciphertext. The session key is negotiated end-to-end via X25519 between your two clients before any data hits the relay. We could not read your traffic if we wanted to.

How do I know if I got a direct connection or a relay connection?
The status bar in the GoDesk client shows "Direct" or "Relay" once the connection is established. You can also check session details from the toolbar.

Can I force GoDesk to always use the relay?
Yes, set relay-only = true in the client config. Useful if you want consistent latency rather than the variability of P2P falling back to relay mid-session.