The Core Mechanism

Remote Control With Zero Network Configuration

To connect two computers directly, the traditional internet model expects each machine to own a reachable public IP address and to accept inbound connections. In practice almost no end-user PC meets those conditions: it sits behind a home or office router, hidden inside a private network, and its firewall silently drops unsolicited incoming traffic.

Modern remote support software sidesteps this entirely with a Relay (Control) Server architecture. Instead of one PC trying to "call in" to the other, both PCs quietly "call out" to a shared server. The server then stitches those two outbound calls into a single session. The result: launch the program, share a code, and you are connected — no port forwarding, no public IP, no router changes on either side.

The one idea to remember: A firewall's job is to block strangers knocking on the door from outside (inbound), but it freely lets people inside walk out (outbound). Remote control software wins by making both computers walk out to meet at a neutral location—the relay server—rather than trying to force one of them to open its door.

The Traditional Problem

Private IPs & Stateful Firewalls

Why a Direct Connection Fails
NAT & Private Addresses: Most devices hold a private IP (e.g. 192.168.x.x / 10.x.x.x) that is only valid inside the local network. From the public internet this address is not routable—there is literally no way to dial it.
Stateful Inbound Blocking: Routers and corporate firewalls keep a "connection table" and only permit traffic that matches a session the inside started. An unexpected inbound packet has no matching entry, so it is dropped by default.
Manual Setup Is Fragile: Public IPs, port forwarding, DMZ, or VPN tunnels can technically expose a PC—but they widen the attack surface, break whenever the ISP rotates a dynamic IP, and are far too complex for a typical end user.

The Modern Solution

Outbound Rendezvous at a Relay Server

How Remote Software Solves It
Outbound Is Allowed: The same firewall that blocks inbound traffic generally permits outbound connections. Remote solutions take advantage of this by dialing out over dedicated ports 9500 and 9501.
A Shared Meeting Point: Both the technician (Agent) and the customer (Client) open an outbound connection to one mutually reachable Relay Server with a fixed public address.
Persistent Tunnel: Each side keeps its outbound socket open (long-lived TCP / WebSocket with keep-alives), so the server can push data back down the pipe the client already opened—no inbound connection is ever needed.

The Relay Server, In Detail

Two Jobs: Matchmaker First, Courier Only If Needed

A relay server actually performs two distinct roles. First it acts as a signaling / rendezvous server—a matchmaker that pairs the two outbound connections and helps them discover each other's public address. Then, only if a direct link cannot be formed, it becomes a data relay that forwards the encrypted stream on the connection's behalf.

Both PCs dial out to the relay server; the server pairs them and, whenever possible, hands off to a direct peer-to-peer tunnel.

Step-by-Step Workflow

How a Session Is Established

01

Outbound Registration

Opening the Tunnel
On launch, the client opens an outbound TLS connection to the relay server over port 9501. Because it is an encrypted outbound request, local firewalls and routers let it through.
This socket is kept alive with periodic keep-alive packets, giving the server a return path to reach the client at any moment no inbound needed

02

Signaling & Pairing

Matching the Two Sides
The customer enters a short 6-digit session code. The server uses it to authenticate and pair the customer's socket with the correct agent's socket.
Acting as a signaling server, it then tells each side the other's public IP and port (as seen from the internet), plus session keys—the information needed to attempt a direct link.

03

NAT Traversal & Streaming

Choosing the Fastest Path
Hole Punching (STUN): Both sides fire packets at each other's public address simultaneously. Because each side's NAT already expects a reply, a direct P2P tunnel opens—lowest latency.
Relay Fallback (TURN): If a symmetric/strict NAT blocks P2P, the encrypted stream is forwarded through the relay server instead. Slower, but it always works.

Traced end to end, a single session looks like this:

Phase	What happens on the wire	Why it clears the firewall
Connect	Client & Agent each open an outbound TLS socket to relay.server:9501.	Outbound connections are generally permitted; the NAT creates a return-path entry automatically.
Register	Each side registers with a session identifier and stays connected via keep-alives.	The server now holds a live pipe to both—no port forwarding, no listening port on the PCs.
Signal	Session code is validated; the server swaps each side's public IP:port and key material.	Only metadata crosses here—small, fast, and still over the existing outbound sockets.
Traverse	STUN-style hole punching attempts a direct P2P path; TURN relay is used if it fails.	Simultaneous outbound packets trick both NATs into accepting the peer's replies.
Stream	Screen frames flow one way; keyboard/mouse events flow the other—all AES-256 encrypted.	Runs over whichever tunnel won: direct P2P (fast) or server relay (fallback).

Security By Design

The Relay Never Sees Your Screen

End-to-End Encryption

Keys Belong to the Endpoints

Encrypted Before It Leaves
Per-session keys: Agent and Client negotiate a fresh symmetric key (e.g. via an ephemeral key exchange) so each session is cryptographically unique.
AES-256 payloads: Screen frames and input events are encrypted on the sender before transmission and decrypted only on the receiver.
Blind relay: Even when data passes through the server, it forwards ciphertext only—it cannot read the screen or keystrokes.

No Attack Surface Opened

Nothing to Port-Forward

Safer Than Traditional Access
Zero open ports: Because the PC never listens for inbound connections, there is no exposed port for an attacker to scan or exploit.
Consent-driven: A session exists only while a valid short-lived code is active and the customer is running the client—it cannot be reused later.
Auditable path: All traffic rides the dedicated encrypted port 9501, so it is compatible with corporate proxies and inspection without special exceptions.

Why It Just Works

Benefits of the Relay-Based Architecture

Key Architectural Highlights
One-Click for End Users: The customer only double-clicks a small executable—no installation, admin rights, or network setup required.
Enterprise Firewall Friendly: Everything runs over outbound ports 9500/9501, so it works inside strict corporate networks without weakening any security policy.
Dynamic IP & Mobile Ready: Because addressing is handled by the relay at connect time, it works seamlessly across DHCP changes, mobile hotspots (LTE/5G), and roaming Wi-Fi.
Adaptive Performance: Direct P2P is used whenever possible for minimal latency, with automatic relay fallback so a connection is never simply refused.
End-to-End Encrypted: AES-256 protects control signals and video across the entire path, including any relay hop.

How Remote Control Works