Not in the office, but still able to connect back to the office computer: Using Natapp to enable Windows Remote Desktop

Author: 一只牛博 Tags: Backend

The computer is at the office, but you're already home. When you suddenly need to grab a file or spend a few minutes finishing up some work, the biggest hassle is not being able to access that machine at all. Installing standalone remote control software is suitable for temporary assistance, but for a long-term connection to a fixed computer, both ends need to maintain a client, and you might also encounter login, authorization, or plan limitations.

This time, I kept Windows' built-in Remote Desktop and only ran the Natapp client on the office computer. Through a VIP2 TCP tunnel, I connected the local 3389 port to the public internet. External Mac, Windows computers, or phones use their original Remote Desktop clients to connect to the fixed address and port provided by Natapp.

The connection relationship is not complicated:

After a successful connection, files and software still run on the office computer, and there is no need to open public network ports for each application individually.

First, confirm the office computer supports Remote Desktop

According to Microsoft's Remote Desktop enablement instructions, the controlled machine needs to use Windows 10/11 Pro, Enterprise, Education, or Windows Server. The Home edition cannot act as the controlled end. The office computer must also have a password-protected account and remain powered on, connected to the network, and not in sleep mode.

Open "Settings -> System -> Remote Desktop", enable Remote Desktop and keep Network Level Authentication (NLA), then check the local port in an administrator PowerShell:

Test-NetConnection 127.0.0.1 -Port 3389

Only proceed to configure the public network tunnel if you see TcpTestSucceeded : True.

If the local 3389 is not listening, first check the Remote Desktop service and firewall; if the local machine is normal but the external network cannot connect, then troubleshoot Natapp.

Why I directly chose VIP2 this time

The Remote Desktop address will be saved long-term on computers and phones, so a fixed public network address and port is more convenient. Free tunnels are suitable for testing the link, but for a long-term entry point to a fixed computer, I directly used VIP2.

Natapp's currently listed VIP2 plan has a 10 RMB/month base fee, traffic is billed at 1.1 RMB/GB, providing a 100M bandwidth cap and a fixed domain name or TCP port, and supports custom local ports. Pay-as-you-go billing is suitable for Remote Desktop that is not always connected but used when needed.

Estimating one connection per day with light usage of 30MB each time, 30 days would consume about 900MB, with a traffic cost of less than 1.1 RMB, plus the base fee, totaling about a dozen RMB per month. 30MB is just an estimate; resolution, dynamic screen content, and file transfers will all affect actual traffic.

100M is the plan's bandwidth cap; the actual experience also depends on the office's upload speed, the external network, and the remote computer's performance. The focus here is more on the low-cost fixed TCP entry point.

Create a TCP tunnel pointing to 3389

Remote Desktop uses TCP, so create a VIP2 TCP tunnel in the Natapp backend. The official documentation states the local port for Remote Desktop is 3389, keep the local address as 127.0.0.1, and use the currently available port in the console for the public network port.

The public network port and the local 3389 do not need to be the same, and there is no need to modify the router. Before saving, confirm the protocol is TCP and the local port is 3389.

After creation, you will get an authtoken, which is the credential for the Natapp client to start the tunnel. Do not make it public or commit it to a code repository.

Assume the address provided by the tunnel is:

xxxx.natapp.cc:45678

External clients fill in the complete xxxx.natapp.cc:45678; 3389 is only used for tunnel forwarding to the office computer.

Make Natapp persistent on the office computer

Choose the Windows version on the Natapp client download page and place it in a fixed directory.

The download page provides a PowerShell installation command. Confirm the current directory and download source before executing. After completion, run the help command first, then start the client in the foreground. Foreground logs can directly show authentication, reconnection, and port errors. After confirming the tunnel is usable, install it as a system service. This step only prepares Natapp and will not modify Windows Remote Desktop settings.

Then start it in PowerShell:

cd C:\natapp
.\natapp.exe -config=config.ini

Seeing Tunnel Status Online and the Forwarding public address indicates the tunnel is established. If authentication fails, first check the authtoken.

After the foreground test passes, install it as a system service. The official instructions indicate that version 2.5.3 and above support -service, and Windows requires an administrator PowerShell.

Common commands are as follows:

.\natapp.exe -service install
.\natapp.exe -service start
.\natapp.exe -service status

Execute status and check the console's online status, then restart the computer to test once more; the tunnel should recover without manually opening PowerShell, which confirms that the auto-start on boot is effective. If service parameters are modified, the service needs to be reinstalled.

A system service cannot wake a sleeping computer, so the controlled machine must still have automatic sleep disabled.

A public network entry cannot rely solely on a Windows password

After the TCP address is connected to the public network, you should keep a strong Windows password and NLA, and enable brute-force protection and access tokens in Natapp.

The authtoken is used to start the tunnel, and the access token is used to verify external connectors. According to Natapp's instructions, first open the TCP public address in a browser and enter the token; the current public IP will be whitelisted for 24 hours. If the IP changes due to a network switch, re-verification is required. Do not concatenate the token into shared links.

When the token is not enabled, the browser might prompt "TCP tunnel is prohibited for web access". This is just a protocol prompt and does not mean the entry point is protected.

Establish a remote connection on an external computer

Connection testing should be done outside the company network. On a Mac, follow Microsoft Windows App's connection process, select + -> Add PC in Devices, and then fill in the public address in PC Name:

xxxx.natapp.cc:45678

Windows computers can directly use the system's built-in "Remote Desktop Connection" and fill in the same address. The account can be entered at the time of connection.

Double-click the device card, check the certificate prompt for the first connection, then enter the office computer's Windows account, not the Natapp credentials. After entering the desktop, open File Explorer to confirm the environment, then actively disconnect and reconnect once. Programs still run on the office computer; the Mac only transmits the display and operations.

After a successful connection, you can access the full Windows desktop without opening ports for each application individually.

A phone can also serve as a temporary entry point

A phone can also use the same Natapp address. When the access token is enabled, first complete verification using the phone's browser, then add a new PC in the Remote Desktop client, filling in public_hostname:public_port and the Windows account. After switching Wi-Fi or mobile networks, you might need to re-verify the token. The device card uses the public network port, not the local 3389.

A phone is suitable for viewing files or confirming program status; for long-duration input and multi-window operations, a computer is still recommended.

When unable to connect, check the link segment by segment

When Remote Desktop fails, do not modify the firewall, port, and account simultaneously. Troubleshooting in the order the connection passes through will be faster:

1. Execute Test-NetConnection 127.0.0.1 -Port 3389 on the office computer to confirm local RDP is normal;
2. Check if the Natapp client or system service is online, and if the Forwarding address matches the current tunnel;
3. Confirm the external client is filled with public_hostname:public_port, not 3389;
4. If the access token is enabled, first complete verification using the browser on the current external network;
5. If the Windows login box appears but cannot enter, check the username format, account password, Remote Desktop user permissions, and NLA;
6. If it connects occasionally but fails after being idle for a long time, first check if the office computer has entered sleep mode.

Natapp is responsible for forwarding the connection, and Windows is responsible for the account and desktop permissions. Tunnel logs can record connections but cannot record specific operations within the desktop.

After Remote Desktop is usable

VIP2 uses a 10 RMB base fee plus actual traffic costs to keep a fixed remote entry point for a Windows computer without a public IP. For long-term use, keep a strong password, NLA, brute-force protection, and access token; important files still need independent backups.