Article · · updated
Remote desktop without port forwarding
Most remote desktop setups fail at the router, not in the software. Here is why, how Nelkira gets round it with a relay on port 443, and what that relay can and cannot see.
Why port forwarding is the usual obstacle
A PC on an office or home network has a private address. Nothing on the internet can start a connection to it. The router in front of it only passes traffic that the PC asked for.
The classic answer is to forward a port: tell the router to send everything arriving on one port to one PC. That is a hole in the firewall that stays open all day, for anyone who scans for it. It also needs the router’s password, a public address that does not change, and a change request on networks you do not own.
On a hospital network, that request is often refused, and rightly so. At home, the router often belongs to the internet provider. Either way, port forwarding is the step where remote access stops being something you can just set up.
The local network and a relay, at the same time
Nelkira never asks you to forward a port. A session tries the local network and a relay at the same time and keeps whichever answers first.
Two PCs on the same subnet normally talk straight to each other where Windows Firewall allows it. The session then stays on the site, and there is nothing in the middle to add delay, though the relay still hears about the call while it is set up.
Where a firewall refuses a direct path, both machines connect outward to a relay instead. Outward connections are what routers are built to allow. There is nothing to forward and nothing to open.
Remote desktop over port 443
The relay listens on port 443. That is the port browsers use for every https page, so a network that allows web browsing already allows it. It is the same port web browsing uses, so it works wherever a browser does.
Nothing special is asked of the network. No firewall rule, no VPN, no public address on either side. A machine on a locked-down ward network reaches a relay the same way it reaches a website.
What the relay can and cannot read
A relay in the path is the obvious place to worry about, including the relays we operate. Here is what it can and cannot do today.
The two machines agree a key directly with each other, fresh for every session (a P-256 exchange). Everything after that is sealed with AES-256-GCM: screen, keystrokes, mouse, clipboard, files. There is a separate key in each direction, and a counter stops a captured message being replayed. The relay copies encrypted bytes and holds no key for them.
Encryption alone would not stop a relay from running two exchanges and sitting between them. Where a password protects the connection, the viewer proves which two keys it saw, and the PC being reached checks that proof before it lets anyone in. From release 0.4.0 both ends prove the password instead of one side sending it (SPAKE2, RFC 9382). A viewer older than 0.4.0 still runs the check one way: it sends the password, inside the encrypted channel, to whichever machine answers the number, so a sign-in from it through a hostile relay is not protected against impersonation. A 0.4.0 viewer never sends the password to an older PC; it asks for Allow there instead. From 1 May 2027 a PC on 0.4.0 or newer accepts a password only from 0.4.0 or newer viewers; older viewers still connect when the person at the PC clicks Allow.
The second stated limit: a connection let in by clicking Allow, with no password typed, has no shared secret to bind a proof to. It is still encrypted against a relay that merely watches. It is not proof against an active attacker in the relay path. Both limits are written in the security statement.
Where the relay sits still matters
Removing port forwarding does not remove distance. We measured a Kansas relay from Dhaka once: 216 ms each way, roughly 430 ms between moving the mouse and seeing it move. A relay in Dhaka, for a session in Dhaka, measured about 75 ms. That is the difference between usable and not.
So the relay is not tied to us. Installing your own is one command on a Linux box. The directory, the relay and every session record can sit on servers you control, in the country you choose. How to do that is on the self-hosted remote desktop page.
Three questions
Do I need a public IP address?
No. Both machines connect outward. Where the network allows, they find each other on the local network; otherwise both reach a relay on port 443.
Does the relay keep a copy of the session?
It cannot read what it carries, so there is nothing readable for it to keep. The record of a session, who, how, when and which files, is kept on the machine that was accessed, and never holds content.
Can I run the relay in my own country?
Yes. It is one command on a Linux box, and the directory and the records can sit with it, on servers you control. See self-hosted remote desktop.