How to Access a Computer Remotely Without Port Forwarding
Remote Desktop normally requires a reachable network path to the host computer. That can be difficult when your router is behind carrier-grade NAT, your public IP address changes, or you do not control the router. Localtonet provides another approach: its client establishes an outbound connection to a relay and publishes a selected local service through an assigned public host and port. This avoids inbound router port forwarding and does not require a public IP address, but the published RDP endpoint must still be protected with strong Windows authentication, Network Level Authentication, current security updates, and careful tunnel lifecycle management.
Why Remote Desktop Port Forwarding Often Fails
A traditional Remote Desktop setup forwards an external router port to TCP port 3389 on a Windows computer. That approach requires control of the router and an internet connection on which unsolicited inbound traffic can reach the router. It may fail when an internet service provider uses carrier-grade NAT, when another upstream router performs NAT, or when inbound connections are filtered.
Carrier-grade NAT commonly uses addresses from 100.64.0.0/10, although a router may also receive another non-public address in some provider configurations. If the router does not have a publicly reachable address, adding a forwarding rule to that router does not create a path through the provider's upstream NAT. A dynamic public IP address is a different issue. Port forwarding can still work with a dynamic address, but clients need a way to track address changes, such as dynamic DNS.
| Network condition | Effect on direct RDP | Outbound tunnel approach |
|---|---|---|
| Carrier-grade NAT | The subscriber router cannot create a forwarding rule through the provider's upstream NAT. | The Localtonet client initiates an outbound relay connection, so no inbound provider mapping is required. |
| Dynamic public IP | The saved destination may stop working after the public address changes. | The client reconnects outbound to Localtonet. Use the endpoint currently assigned to the tunnel. |
| No router administration | You cannot add or maintain an inbound forwarding rule. | No router configuration is required for the normal Localtonet workflow. |
| Inbound filtering | Direct connections may be blocked by the router, provider, or network administrator. | An outbound tunnel may work if the network permits the Localtonet client connection. Do not use it to violate organizational policy. |
Localtonet avoids exposing TCP 3389 through your home router, but a raw TCP or combined UDP/TCP tunnel creates a public relay endpoint for the selected service. Anyone who discovers that host and port can attempt to reach RDP unless another applicable control blocks them. Keep Windows patched, require Network Level Authentication, use strong unique credentials, stop the tunnel when it is not needed, and apply any access restrictions available in your current Localtonet plan or deployment.
What You Need
Step 1: Enable and Secure Remote Desktop
Perform these steps locally on the Windows computer before relying on remote access. Microsoft recommends enabling Remote Desktop only on trusted networks and only when it is needed. Windows 10 reached the end of standard support on October 14, 2025. If the host still runs Windows 10, review Microsoft's current Extended Security Updates options or migrate to a supported Windows release rather than exposing an unmaintained system.
Confirm the Windows edition
Open Settings → System → About and check the edition under Windows specifications. Use a supported Pro, Enterprise, or Education edition for Microsoft's built-in RDP host. Do not use unofficial patches that modify Windows licensing or terminal-service components.
Enable Remote Desktop
Open Settings → System → Remote Desktop, turn on Remote Desktop, and confirm the change. Windows normally enables the associated firewall rules as part of this supported settings workflow.
Require Network Level Authentication
Keep the option requiring Network Level Authentication enabled. NLA requires authentication earlier in the connection process and reduces the resources exposed before authentication. Very old clients that cannot use NLA should be updated rather than accommodated by weakening the host.
Authorize only the necessary users
Use the Remote Desktop users control in Windows Settings to grant access only to specific accounts. Prefer a standard user account where administrative privileges are not required. Record the correct account format, such as COMPUTERNAME\username for a local account or the appropriate Microsoft or organizational account identifier.
Test RDP on the local network
Before creating a public tunnel, connect from another trusted device on the same local network. This confirms that Remote Desktop, the selected user, and the Windows firewall are configured correctly. Troubleshooting locally first separates RDP configuration problems from tunnel problems.
Step 2: Install and Connect the Localtonet Client
Use the current operating-system section of the Localtonet documentation rather than the old /documents/download address, which no longer resolves to a download page. Installation details and available client controls can change by release, so follow the current Windows instructions shown in the documentation or dashboard.
Open the current Localtonet documentation
Visit localtonet.com/documents, select Operating Systems, and open the Windows instructions. Download the client only from a Localtonet-controlled location identified there.
Install or run the supported Windows client
Place the client in an appropriate location and follow the current documented launch instructions. Do not copy installation or service commands from an old article without checking that they are supported by the installed client version.
Associate the host with its device token
Use the device-specific authentication token supplied through your Localtonet account. Treat it as a credential. Do not place a real token in screenshots, public commands, tickets, or shared documents.
Confirm the device is connected
Verify in the dashboard that the intended Windows device is connected before creating or starting the tunnel. Creating a tunnel configuration does not mean it is running.
Step 3: Create and Start the RDP Tunnel
RDP uses TCP for its primary transport and can also use UDP for improved connection behavior. A TCP tunnel is the basic compatible choice. Where the current dashboard and your plan support it, a combined UDP/TCP tunnel can be considered for the same local target. Do not assume that every protocol, relay region, endpoint option, or fixed address is included in every plan.
Select the connected host device
In the Localtonet dashboard, create the appropriate raw port tunnel and select the device running the Localtonet client. Confirm that this is the computer hosting RDP or a device that is explicitly permitted to reach it.
Select an available relay server
Choose from the relay servers or regions currently offered in your dashboard. Availability can vary, so do not rely on a server code copied from an older tutorial.
Set the local target
If the Localtonet client runs on the RDP host, set the local IP to 127.0.0.1 and the local port to 3389. If the client runs on a different trusted device, use the RDP host's private LAN address instead and ensure local routing and firewall policy permit that connection.
Create and start the tunnel
Save the configuration, then press Start. The tunnel is available only while the selected device is connected and the tunnel is running. Record the public host and port shown for this tunnel.
Verify the current endpoint
Use the exact host and port displayed by the dashboard. Endpoint persistence can depend on the current configuration or plan, so verify the address after changes instead of assuming it will remain permanent.
| Field | Typical RDP value | Important qualification |
|---|---|---|
| Tunnel family | TCP, or combined UDP/TCP where available | Use options currently shown in your dashboard and supported by your plan. |
| Local IP | 127.0.0.1 | Use this only when the Localtonet client and RDP host are the same computer. |
| Local port | 3389 | Use a different value only if the Windows RDP listener was intentionally reconfigured. |
| Public destination | Host and port assigned by Localtonet | This is a public relay endpoint and must be protected as an exposed RDP service. |
Step 4: Connect from Another Device
On Windows, open Remote Desktop Connection by searching for it or running mstsc. Enter the assigned Localtonet host and port in the computer field using the format hostname:port. Supply the authorized Windows account when prompted.
On macOS, iOS, iPadOS, or Android, use Microsoft's current Windows App where it is available. Microsoft has replaced the older Microsoft Remote Desktop branding on these platforms. Add a PC and enter the assigned public host and port in the fields supported by that version of the app. Interface details can change, so consult Microsoft's current Windows App documentation if the port is presented separately.
Linux users can use a maintained RDP client such as Remmina or FreeRDP. Avoid putting a password directly in a shell command because command-line arguments can be retained in shell history or exposed to other local processes. Let the client prompt securely for credentials or use an appropriately protected credential facility.
An RDP certificate warning can occur when the destination name does not match the certificate presented by the Windows host. A warning is not proof that a connection is safe. Confirm that the endpoint is the one shown in your Localtonet dashboard and verify the host certificate or fingerprint through a trusted path before continuing. Do not select a permanent trust option until you have performed that verification.
Keep Remote Access Available Safely
The computer must remain powered on, connected to the network, and able to run the Localtonet client. Configure sleep behavior according to your security and availability requirements. Setting a computer never to sleep improves availability but increases energy use and leaves the device continuously reachable, so use that setting deliberately.
If unattended startup is required, use only the startup or service mechanism documented for your installed Localtonet client version. The old service commands previously shown in this article are not retained because they are not established by the current evidence. After configuring startup, reboot the computer and confirm both that the device reconnects and that the selected tunnel is running. Do not assume that creating a tunnel causes it to start automatically.
Security Checklist
| Control | Why it matters | Recommended action |
|---|---|---|
| Supported Windows release | Remote access software has historically received critical security fixes. | Use a supported Windows release and install security updates promptly. |
| Network Level Authentication | NLA authenticates the user earlier in the RDP connection process. | Keep NLA required unless a documented compatibility need has been reviewed. |
| Strong unique credentials | The public relay endpoint can receive unauthenticated connection attempts. | Use a unique password, restrict RDP users, and follow organizational account-lockout and multifactor policies where applicable. |
| Least privilege | An administrative account increases the effect of credential compromise. | Use a standard account for routine remote work and elevate only when required. |
| Tunnel lifecycle | A running tunnel keeps the public endpoint available. | Stop or delete the tunnel when remote access is no longer needed. |
| Token protection | The Localtonet token identifies the client device. | Never publish the token, and rotate or replace it through supported account controls if exposure is suspected. |
Windows Home and Other Host Systems
Windows Home does not include Microsoft's supported Remote Desktop host capability. The safe options are to upgrade to a supported Windows edition or use a reputable remote-access server that officially supports the installed operating system. This article does not recommend RDP Wrapper or similar patches. Such tools modify unsupported Windows behavior, can break after Windows updates, and may create licensing and security concerns.
VNC is one possible cross-platform protocol, but its security model and configuration vary substantially by implementation. Do not assume that every VNC server encrypts all session traffic or uses TCP port 5900 in every configuration. If you choose VNC, follow the selected vendor's current documentation, require strong authentication and transport protection, verify the actual listening address and port, and then target that verified local service with an appropriate Localtonet TCP tunnel.
Troubleshooting
| Symptom | Likely cause | Check |
|---|---|---|
| The client cannot connect | The host is asleep, offline, or Remote Desktop is disabled. | Test RDP locally, verify power state, and confirm the Windows Remote Desktop setting. |
| The tunnel exists but is unavailable | The selected Localtonet device is disconnected or the tunnel was not started. | Check the device status and press Start for the intended tunnel. |
| Credentials are rejected | The wrong account format was used, the account lacks RDP permission, or a PIN was entered instead of the account password. | Verify the account locally and review the Remote Desktop user list. |
| A certificate warning appears | The endpoint name and Windows host certificate may not match. | Verify the dashboard endpoint and host identity before accepting the certificate. |
| The session is slow | Network latency, packet loss, display resolution, or visual effects may be contributing. | Select an appropriate Remote Desktop experience profile, reduce resolution or visual effects, and try an available relay region closer to the client or host. |
| A local user is interrupted | Desktop Windows editions do not provide Windows Server-style concurrent multi-user RDP sessions. | Coordinate with the local user. Do not use unsupported patches or Group Policy changes to circumvent desktop-session licensing limits. |
Frequently Asked Questions
Does Localtonet work behind CGNAT?
Yes. The client establishes an outbound connection to a Localtonet relay, so the host does not need a public IP address or an inbound router mapping. The local network must still permit the required outbound client connection.
Is port 3389 exposed directly through my router?
No inbound router rule is required. However, the Localtonet relay host and assigned port provide a public path to the selected RDP service while the tunnel is running. Treat that endpoint as internet-facing and retain all RDP security controls.
Will the public host and port always remain the same?
Do not assume that without checking the current tunnel configuration and plan. Use the endpoint displayed in the dashboard and verify it after recreating a tunnel, changing its settings, or changing subscription details.
Can Windows Home receive an RDP connection?
Windows Home can run an RDP client, but it does not include Microsoft's supported Remote Desktop host feature. Upgrade to a supported edition or use supported remote-access software designed for Windows Home. Avoid unofficial terminal-service patches.
Can I connect before anyone signs in locally?
RDP can present the Windows sign-in screen, but the Localtonet client and tunnel must already be running. Configure unattended startup only through the mechanism supported by the current Localtonet client, then test it after a full reboot.
Does the tunnel replace Windows authentication?
No. The tunnel provides network reachability to the RDP service. Windows still authenticates the remote user, and you should keep Network Level Authentication, account restrictions, least privilege, and current security updates in place.
Access Your Windows PC Without Router Port Forwarding
Connect the Localtonet client, create a tunnel to the verified RDP target, start it only when needed, and connect through the assigned public host and port. Keep RDP authentication and Windows security controls enabled at all times.
Get Started Free →
