Reach a GNOME Wayland desktop through RDP without opening an inbound router port
GNOME Remote Login and Localtonet solve two different parts of remote desktop access: creating an authorized desktop session and making its RDP listener reachable. This guide uses an Ubuntu Desktop 24.04 LTS configuration baseline, a Settings-based GNOME setup, and our documented Linux package installation workflow. You will verify the local service, protect the device token, start a TCP tunnel, and test the complete remote login after reboot. RDP remains responsible for TLS, authentication, and session authorization, and release-specific client compatibility must be tested before relying on unattended access.
📋 What's in this guide
Tutorial scope and networking architecture
Wayland is a compositor protocol, not a universal remote desktop server. GNOME, KDE Plasma, and wlroots-based environments implement remote access differently. Their screen-capture permissions, login-session support, locking behavior, and reconnect handling are not interchangeable. The Wayland protocol documentation explains the underlying compositor architecture, but does not prescribe one remote desktop deployment.
Many screen-sharing applications use desktop portals to request capture and input access. Whether those permissions survive an application restart or work while a desktop is locked depends on the compositor, portal backend, and application. An attended screen-sharing demonstration therefore does not establish that the same application will work before login or after a cold boot.
This guide focuses on GNOME Remote Login, the system-level RDP workflow available in the GNOME 46 generation and later. It is distinct from sharing an existing desktop. Remote Login provides a login-oriented path associated with GDM; it should not be assumed to mirror the desktop visible on the physical monitor.
What the tunnel does and does not do
The RDP client opens a connection to the public endpoint assigned by Localtonet. Our relay forwards the traffic through the connected Linux device to the configured local target. When both applications run on the same machine and loopback is reachable, that target is normally 127.0.0.1:3389.
Localtonet does not approve Wayland capture requests, select a Linux account, validate the RDP certificate on behalf of the remote client, or grant a desktop session. Those responsibilities remain with GNOME, GDM, and the RDP client. Troubleshoot these layers separately: first the desktop service, then target reachability, then the public connection.
This guide does not claim that raw TCP tunneling adds encryption to an otherwise unencrypted application protocol. Configure RDP TLS and authentication before exposure. A tunnel removes the need for an inbound router port forward, but the service is still reachable through a public endpoint while the tunnel runs.
Prerequisites and compatibility checklist
The concrete package examples below use Ubuntu Desktop 24.04 LTS with its distribution-provided GNOME desktop and GDM. Use a fully updated installation rather than mixing GNOME packages from unrelated releases. This is a configuration baseline, not a claim that every Ubuntu point release, graphics adapter, and RDP client combination has been independently certified.
Our supplied official documentation establishes the Localtonet package requirements and commands. It does not establish a version-specific GNOME support matrix, credential-command syntax, or a guaranteed RDP client combination. For that reason, this guide uses Settings for credentials and certificate provisioning instead of presenting an unconfirmed grdctl command sequence as verified. The local and external acceptance tests below are mandatory.
| Component | Baseline or requirement | Acceptance check |
|---|---|---|
| Linux desktop | Ubuntu Desktop 24.04 LTS, GNOME and GDM from supported repositories | Record OS and GNOME versions; confirm Remote Login is present in Settings. |
| Remote desktop package | gnome-remote-desktop | Confirm the package, system service, and RDP listener exist. |
| Localtonet package | DEB for x64 or ARM64; systemd 247 or newer and OpenSSL 3 | Check architecture and runtime versions before installation. |
| RDP client | A fully updated Windows 11 built-in Remote Desktop Connection client is the example test client | Record its version and complete login and redirection locally and through the tunnel. |
| Administration | Local console or another trusted recovery connection, plus sudo access | Do not make RDP your only recovery method during setup. |
| Unattended operation | Power, networking, and boot completion without desktop login | Test an actual reboot while someone can still recover the machine. |
Record the actual installation
cat /etc/os-release
gnome-shell --version
dpkg --print-architecture
systemctl --version
openssl version
dpkg-query -W gnome-remote-desktop gdm3
systemctl status display-managerOn Ubuntu, amd64 corresponds to the Localtonet x64 package; arm64 corresponds to ARM64. Do not install one architecture’s package on the other. The DEB path here is not a 32-bit ARM or musl installation procedure.
Use the Windows client’s About dialog to record its version. Other maintained RDP clients may work, but “supports RDP” is not sufficient evidence of GNOME Remote Login compatibility. The client must handle the security negotiation and session handoff used by the installed server. A successful TCP probe is not a client compatibility test.
Install and configure GNOME Remote Login
Perform the initial configuration from the local graphical console. Keep the public tunnel stopped until you have completed a local RDP login. The Settings path avoids handling a private key manually and avoids putting an RDP password into shell arguments.
Install the Ubuntu package
sudo apt update
sudo apt install gnome-remote-desktop
command -v grdctlApply pending distribution security updates and any required reboot before testing. Installing this package on an older GNOME release does not by itself add the system Remote Login feature. If your desktop does not expose Remote Login, stop and resolve the distribution or package mismatch rather than substituting desktop sharing.
Configure Remote Login in Settings
- Open Settings → System → Remote Desktop at the local console.
- Select Remote Login, not Desktop Sharing. Unlock the administrative controls if prompted.
- Enable Remote Login. Allow the graphical workflow to provision its certificate rather than entering placeholder certificate paths.
- In the authentication area, set a strong, unique Remote Login username and password. Store them in a password manager, separate from the Linux account credentials.
- Record the displayed connection details and port. Use the certificate verification control, when available, to record the certificate fingerprint at this trusted console.
- Inspect the system service and listener using the commands below. If the expected controls or certificate details are absent, do not assume another release has the same workflow.
Settings labels and certificate-verification presentation can vary with distribution updates. The supplied evidence does not include primary distribution documentation confirming every control for every Ubuntu 24.04 package revision. Treat a mismatch as a reason to check the installed release’s help, not as permission to improvise credential syntax or certificate ownership.
Check system startup and permissions
sudo systemctl enable --now gnome-remote-desktop.service
sudo systemctl status gnome-remote-desktop.service
sudo systemctl show gnome-remote-desktop.service -p User -p Group
sudo journalctl -u gnome-remote-desktop.service -b --no-pagerThese commands target the system service, not a user service. The Settings workflow should leave certificate and credential storage usable by the service without making the private key public. The service identity and storage permissions must be inspected on the installed package; do not assume that a certificate created in your own home directory is readable by a system service.
If you later manage certificates manually, inspect the actual configured paths and service identity. Parent-directory traversal permissions matter as well as the file’s read permission. A useful diagnostic is namei -l /actual/path/to/rdp-tls.key, with the real path substituted. Correct ownership and security-policy labels through the distribution’s supported procedure. Never use world-readable permissions or disable AppArmor or SELinux to hide a configuration error.
Whether grdctl --system rdp set-credentials accepts interactive input or requires arguments depends on the installed implementation. The supplied evidence does not verify that syntax for this baseline. Use Settings, or first consult the installed grdctl --help and release-specific primary documentation. Do not copy an unverified command that could expose a password in process arguments.
Understand the authentication stages
The Remote Login credential protects entry to the system RDP workflow. The Linux account credential authorizes the desktop session through the login screen. Use the credential appropriate to the prompt you are seeing. Do not enable automatic login to avoid understanding the distinction.
Remote Login is not a guarantee of arbitrary simultaneous users, console-session takeover, or persistent disconnected sessions. The supplied evidence does not establish a primary-source release-by-release persistence contract. Test your actual build instead of relying on a general claim that all releases after a particular GNOME version behave identically.
Verify the RDP listener before exposing it
Check the process and listening address
sudo systemctl status gnome-remote-desktop.service
sudo journalctl -u gnome-remote-desktop.service -b --no-pager
sudo ss -ltnp | grep ':3389'Substitute the configured port if Settings reports something other than 3389. A running service without a listener is not ready for tunneling. Look for certificate errors, missing credentials, bind failures, or another process already using the port.
127.0.0.1:3389is IPv4 loopback and is reachable only from the same host.0.0.0.0:3389is an IPv4 wildcard listener, normally including loopback.[::]:3389is an IPv6 wildcard listener; IPv4 acceptance depends on the host configuration.- A specific LAN address requires a target and route that the Localtonet device can reach.
If desired, install Ubuntu’s netcat package and test the exact loopback target:
sudo apt install netcat-openbsd
nc -vz 127.0.0.1 3389This establishes only that a TCP connection opens. It does not verify certificate identity, authentication, desktop creation, or RDP redirection.
Complete a trusted local RDP login
Use a trusted LAN client if the existing listener and host policy allow it, or a compatible client on the host when testing a loopback-only service. Enter the GNOME machine’s local address and configured port. Verify the certificate through the trusted process in the security section, authenticate to Remote Login, and complete the Linux account login.
Confirm that the expected user owns the desktop, keyboard and pointer input work, and applications open. Disconnect without logging out, then reconnect. Record whether the same desktop survives. Save work before this test because persistence is not guaranteed.
Do not widen a loopback-only listener merely to make a LAN test convenient. Running Localtonet on the GNOME host avoids needing an additional LAN path. If a separate Localtonet device is required, permit only the intended device-to-service path under your network policy.
Install Localtonet and create the TCP tunnel
Our current Linux package documentation provides DEB and RPM packages for x64 and ARM64. The package workflow requires systemd 247 or newer and OpenSSL 3. The following DEB installation preserves its documented three-step sequence.
Install the client as a boot service
Download the correct DEB from the Linux packages area of our documentation. Open a terminal in the directory containing the downloaded file. These are package filenames, not download URLs.
Install the downloaded package
For x64, run the first command below. On ARM64, use the second command instead. Install only the package matching the architecture checked earlier.
sudo apt install ./localtonet-linux-x64.deb
# ARM64 alternative:
sudo apt install ./localtonet-linux-arm64.debSet and protect the device AuthToken, then validate configuration
Edit /etc/localtonet/auth-token as root. Replace DUMMY_AUTH_TOKEN with the intended device’s token on a single line. Do not include quotes or paste the token into shell commands, screenshots, or support messages.
sudoedit /etc/localtonet/auth-token
sudo chmod 600 /etc/localtonet/auth-token
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-configResolve any validation error before continuing. Mode 600 restricts the token file to its owner. Retain the package’s root-owned configuration rather than changing ownership to an ordinary desktop user.
Enable and start the client service
After configuration validation succeeds, enable the packaged service and inspect its journal.
sudo systemctl enable --now localtonet.service
sudo journalctl -u localtonet.serviceThis tutorial uses localtonet.service. Do not switch to localtonet-vpn.service: that is a different workflow. A TCP tunnel is not a private mesh VPN.
Configure the TCP target in the dashboard
Confirm that the intended device is connected before configuring its tunnel. Our supplied product workflow supports the sequence below. The evidence provided here does not include the current TCP-specific page’s exact screen layout or field order, so this is a functional workflow rather than a claimed verbatim reproduction of that page.
Run the installed client on the target-capable device
The package service above supplies the outbound connection. Confirm it is active on the GNOME host or another device that can reach the listener.
Select the intended device token
Choose the AuthToken belonging to that connected device, not another machine in your account.
Select an available relay
Use a server or region currently offered in the dashboard. Availability can vary; do not copy an old server code.
Create the TCP configuration
Use the TCP tunnel type and the locally tested address and port. For a same-host installation with a reachable loopback listener, enter 127.0.0.1 and 3389.
Start the tunnel and record its endpoint
Press Start. Confirm both device connectivity and tunnel runtime, then record the assigned public host and port for the RDP client.
If Localtonet runs on another machine, 127.0.0.1 refers to that machine, not the GNOME workstation. Use the workstation’s reachable LAN address and test that exact target from the Localtonet device. Localtonet does not bypass local routing or host access policy.
Verify the public RDP connection end to end
Move the client to an external network, such as a trusted mobile connection. On Windows, open Remote Desktop Connection and enter the assigned endpoint in the Computer field. You can also launch it as follows:
mstsc.exe /v:PUBLIC_HOST:PUBLIC_PORTPUBLIC_HOST:PUBLIC_PORT is a placeholder. Replace it with the actual assigned host and port, without https://. For example, rdp-endpoint.example:45678 illustrates the format only and is not a working Localtonet endpoint. Do not assume the public port is 3389 simply because the local target uses 3389.
- Confirm the GNOME system service is active and the target listener exists.
- Confirm the Localtonet device is connected and the intended tunnel is running.
- Connect to the public endpoint and verify the server certificate against the trusted record.
- Authenticate to the system Remote Login service.
- Complete the Linux account login and all client handoffs through the same public connection workflow.
- Confirm the expected desktop identity, display updates, keyboard input, and pointer input.
- Disconnect without logging out and reconnect to test session behavior.
The acceptance criterion is a usable desktop reached through the public endpoint, including the complete redirected login. A certificate prompt, successful port probe, or visible login screen alone does not pass. If a redirect attempts to use an unreachable private address or the client repeatedly returns to authentication, record the client and server versions and investigate compatibility. Do not expose extra ports speculatively.
Teardown and negative verification
Disconnect the RDP client, then stop the tunnel in the dashboard. After the state updates, attempt a fresh external connection. It should no longer establish an RDP session through that tunnel. Existing client windows or reused sessions are not reliable negative tests.
Use Stop to retain the configuration without continuing public exposure. Delete a temporary tunnel when it is no longer required. If a fresh connection still succeeds, check that you stopped the correct tunnel and that no second tunnel or direct inbound route exposes the service.
Compare remote desktop reachability approaches
| Approach | Reachability model | Operational responsibility |
|---|---|---|
| Direct inbound access | Public IPv4 or routed IPv6 with appropriate inbound policy | You maintain the network edge and exposed service. Carrier-grade NAT can prevent conventional IPv4 forwarding. |
| Self-managed VPS relay | A public VPS forwards traffic toward the desktop network | You provision, patch, monitor, and secure the relay as well as the desktop. |
| Localtonet TCP tunnel | The device connects outbound; clients use an assigned public endpoint | We operate the relay platform. You maintain RDP security, the client device, and tunnel runtime. |
| Private mesh VPN | Authorized members reach private addresses through a mesh | You manage membership, endpoint policy, and routing. This is a different access model from public TCP. |
Direct access does not necessarily require a static IPv4 address; dynamic DNS or globally routed IPv6 can support other designs. With Localtonet, the tunnel does not require inbound router port forwarding, a public device IP, firewall changes, or VPN setup. Outbound connectivity and permission to run the service are still necessary. For a private mesh rather than a public endpoint, evaluate our VPN Manager separately.
Verify certificates and harden the access path
Obtain the fingerprint through a trusted channel
At the physical console, use the Remote Login certificate verification control if your installed Settings version provides it. Record the fingerprint and its digest algorithm in a trusted password manager or transfer it through an already authenticated administrative channel. A fingerprint obtained only from the first untrusted RDP connection cannot independently authenticate that same connection.
If you know the actual configured public certificate file, OpenSSL can calculate its fingerprint. This command reads the certificate, not the private key:
openssl x509 -in /actual/path/to/rdp-tls.crt \
-noout -subject -issuer -dates -fingerprint -sha256The path is a placeholder because certificate storage is package-specific. Identify the configured certificate through the installed service configuration or supported GNOME administration tools rather than guessing a file. If the certificate is DER instead of PEM, add -inform DER.
At the client’s certificate prompt, open certificate details and compare the complete fingerprint using the same algorithm. Some Windows certificate dialogs display a SHA-1 thumbprint; in that case calculate -fingerprint -sha1 locally for an exact comparison, or use a client certificate viewer that displays SHA-256. Different digest algorithms produce different values for the same certificate. Ignore formatting differences such as colons or letter case, but never accept differing bytes.
A self-signed certificate can protect transport while still requiring explicit identity verification. A public tunnel hostname may also differ from the certificate’s subject name. Understand and record the expected warning; do not disable certificate checks globally. If a later prompt presents a different certificate, investigate before entering credentials.
Protect credentials and redirected resources
Use unique credentials for Remote Login, the Linux account, and Localtonet. Keep the device token in its protected file and redact logs before sharing them. Use an ordinary least-privilege desktop account instead of root. If a private key is exposed, replace it and re-establish certificate trust; changing only the password is insufficient.
Review the RDP client’s clipboard, drive, printer, and other resource-redirection settings. Enable only what you need. A remote desktop is an interactive access channel, not merely a picture of a screen.
Maintain deliberate exposure
Patch GNOME Remote Desktop, GDM, graphics components, the operating system, the RDP client, and Localtonet. Use access restrictions where your service, environment, or plan actually supports them. Do not assume a tunnel automatically provides an IP allowlist, application rate limiting, or multi-factor authentication.
The existing image assets are retained for editorial continuity. Their availability, technical accuracy, readability, and credential redaction must be checked in publication review; those properties cannot be established from the supplied HTML alone.
Reboot recovery, upgrades, and troubleshooting
Separate client startup from tunnel runtime
Enabling localtonet.service starts the client at boot. It does not prove that the intended tunnel is running. Likewise, enabling GNOME Remote Desktop does not start Localtonet. Check all three states independently: RDP service, Localtonet device connection, and tunnel runtime.
While a local recovery operator is available, save all work and perform a real reboot. Do not log into the local desktop before testing remote access. Inspect:
systemctl is-enabled gnome-remote-desktop.service localtonet.service
systemctl is-active gnome-remote-desktop.service localtonet.service
sudo ss -ltnp | grep ':3389'
sudo journalctl -u gnome-remote-desktop.service -b --no-pager
sudo journalctl -u localtonet.service -b --no-pagerThen confirm the intended token is connected in the dashboard, confirm the tunnel is running, and complete a fresh external RDP login. If dashboard intervention is needed, document that limitation rather than describing the installation as fully unattended.
Account for conditions a tunnel cannot repair
- Suspend: a sleeping host cannot maintain an ordinary client connection. Review automatic suspend and laptop lid behavior in Power settings.
- Power loss: the host must receive power and boot again. Firmware restart behavior and a UPS are separate operational decisions.
- Pre-boot disk encryption: a machine waiting for a local disk-unlock passphrase has not reached systemd services. Keep encryption and arrange an approved recovery method rather than disabling it for convenience.
- Networking: Wi-Fi or other connectivity must be available before desktop login. Test the actual boot-time network profile.
- Captive portals or upstream outages: these can prevent the outbound connection despite healthy services.
- Desktop or graphics failures: TCP reachability does not guarantee that GDM can create a usable session.
Upgrade Localtonet safely
Download the new architecture-matching package from our documentation and install it using the same package command. Our documented package upgrade preserves configuration. Restart the client afterward:
sudo apt install ./localtonet-linux-x64.deb
sudo systemctl restart localtonet
sudo systemctl status localtonet.service
sudo journalctl -u localtonet.service -b --no-pagerUse the ARM64 filename instead on ARM64 systems. Schedule this work because restarting the client interrupts remote connectivity. Afterward, verify device connection, tunnel runtime, and a fresh RDP login. Do not upgrade the only recovery channel without a fallback.
Diagnose by the last successful layer
| Symptom | First check | Next action |
|---|---|---|
| GNOME service fails | Current-boot service journal | Resolve certificate access, credential storage, package, or port-conflict errors. |
| No listener | Settings and ss | Confirm Remote Login rather than Desktop Sharing and use the actual configured port. |
| Localtonet device disconnected | Client service, token validation, outbound network | Inspect the journal without disclosing the token. |
| Device online, endpoint unavailable | Tunnel runtime and selected token | Start the intended tunnel and verify its exact local target. |
| Local RDP works, public login fails | Assigned endpoint and full redirect behavior | Compare client versions and server logs; do not infer compatibility from a port probe. |
| Authentication rejected | Which login stage failed | Use the Remote Login credential or Linux account credential as appropriate; check keyboard layout. |
| Unexpected certificate | Trusted fingerprint record | Stop, confirm the endpoint and server certificate, then establish trust again if the change is legitimate. |
| Reconnect loses desktop | Installed GNOME build and session test | Do not assume persistence. Save work and use a supported workflow matching the requirement. |
If the active local desktop differs from the remote desktop, that may reflect Remote Login’s session model rather than a tunnel fault. Collaborative viewing of the physical console is a separate desktop-sharing requirement. Test local-console interaction, lock and unlock, disconnect, reconnect, and reboot independently before committing to an unattended deployment.
Frequently asked questions
Does Localtonet bypass Wayland capture prompts?
No. We forward traffic to a reachable service. Localtonet does not approve portal requests or alter GNOME authorization. Remote Login is a system login workflow, not a tunnel-based workaround for screen-sharing permissions.
Is Remote Login the same as desktop sharing?
No. Desktop sharing targets an existing user session. Remote Login provides a system-level login path. Their console interaction, locking, and session persistence must be tested separately.
Does the TCP tunnel replace RDP TLS?
No. Keep RDP TLS enabled, protect its private key, and verify the server certificate. This guide makes no additional encryption claim for raw TCP tunneling.
Do I need port forwarding or a public IP?
No. The Localtonet device connects outward to our relay. The tunnel does not require inbound router port forwarding or a public IP on the device network, but permitted outbound connectivity is necessary.
When should I use 127.0.0.1 as the target?
Use it when Localtonet and GNOME Remote Desktop run on the same host and the listener accepts loopback connections. From another device, use the GNOME host’s reachable LAN address instead.
Will enabling the client service guarantee access after reboot?
No. Boot must complete, networking must return, GNOME must provide its listener, the Localtonet device must connect, and the tunnel must be running. Pre-boot disk unlock, suspend, and power loss can prevent access.
Can any RDP client complete GNOME Remote Login?
Not necessarily. Test the installed client’s security negotiation and complete session handoff through the public endpoint. A successful TCP connection or initial certificate prompt is not sufficient.
Is this a VPN connection?
No. This is a public TCP tunnel to one service. Localtonet VPN Manager is our separate private mesh VPN feature.
Connect GNOME Remote Login through Localtonet
Verify the desktop service and certificate locally, install our client with a protected token, and start a TCP tunnel to the tested listener. Complete an external login and a real reboot test before relying on unattended access.
Get Started Free →
