Match the remote access path to the protocol, resource, and intended audience
Remote access is safest and easiest to operate when you begin with the resource that a user actually needs. A website, SSH server, game service, shared folder, proxy exit node, and private LAN require different access models. This guide explains how to choose a protocol, verify the local target, configure browser-based file access or a private mesh, and test the resulting access boundary. With Localtonet, our client establishes an outbound connection to a relay server, so you can publish a selected resource without inbound router port forwarding or a public IP address.
📋 What's in this guide
Why protocol should come before router configuration
Traditional remote-access planning often starts at the network edge: identify the router, reserve an internal address, create a port-forwarding rule, and determine how remote clients will find the public connection. That sequence focuses on transport before establishing what the user needs. It can also fail when the router is outside the administrator’s control or the internet connection lacks a directly reachable public address.
A protocol-first design reverses that process. Identify the resource, its native protocol, its listening address and port, its intended users, and the minimum operations those users require. A web application generally belongs behind an HTTP tunnel. SSH needs TCP connectivity. Datagram-oriented software may require UDP, while some applications need both transports. A file-only task can use File Server instead of exposing a desktop. Access to several private devices may fit a private mesh better than multiple public administration endpoints.
A tunnel does not replace the application’s authentication, authorization, update process, or safe configuration. Publishing a narrowly scoped service avoids unnecessarily publishing unrelated resources, but the selected service must still be treated as remotely reachable.
How outbound tunneling changes the network requirement
The Localtonet client runs on the device hosting the target or on another device that can reach it. The client establishes an outbound connection to our relay server. When the tunnel is configured and started, remote users connect through a public URL or public host and port, depending on the tunnel family.
No inbound router port-forwarding rule is required. Users connect to the assigned endpoint rather than your router’s changing public address. Carrier-grade NAT, or CGNAT, does not require a customer-controlled inbound mapping for this outbound connection. However, a change in local connectivity can still interrupt the client connection.
This is different from claiming that every network permits tunneling. An organization or provider can filter outbound traffic, require a proxy, restrict DNS, or apply other controls. Use remote access only with the network owner’s permission.
Our standard tunnels do not require an inbound router rule. The client still needs permitted outbound connectivity to the selected relay. Local firewall rules must also permit the client to reach a target hosted elsewhere on the LAN.
The remote access models and what each publishes
HTTP, TCP, UDP, combined UDP/TCP, TLS, and File Server tunnels publish selected resources. They do not join devices into a private network. Our VPN Manager provides private mesh connectivity.
HTTP, HTTPS, and TLS are not interchangeable choices
An HTTP tunnel is the web-oriented choice for an application that needs a browser-compatible public address. HTTP and browser-based File Server publishing support Random Sub Domain, Custom Sub Domain, and Custom Domain process types. These determine the public naming approach and serve content at a public HTTPS address. Custom-domain DNS requirements must be checked against current documentation before configuration.
TLS is a security layer used by many protocols. A TLS tunnel targets a local IP address and port, but should not be assumed to provide HTTP routing or the same naming options as an HTTP tunnel. Choose it only when it matches the service and current product configuration. Do not infer identical encryption or certificate behavior across all tunnel families.
Public endpoints versus private connectivity
If a webhook provider must call one development URL, HTTP publishing is appropriately narrow. If an administrator needs several internal hosts, a private mesh can describe that requirement more clearly than public management ports. A proxy serves a different purpose again: it lets authorized users send traffic through the connected device as an exit node.
Available options, relay locations, and subscription coverage can vary. Check the current dashboard rather than assuming every protocol or capability is included in every plan.
Prerequisites before creating remote access
Before opening a public path, record the target, protocol, intended users, and access lifetime. Prepare these practical requirements:
- A running target: the application must listen on the expected address and port. File Server instead needs an existing folder with appropriate filesystem permissions.
- A suitable client device: install and run Localtonet on the host or another device able to reach the target.
- An account and device token: select the token belonging to the intended client, not a value copied from an example.
- A current relay selection: choose an available server in the product interface. Do not hardcode an old server code.
- An external test client: prepare a browser or protocol client on another network.
- Application access controls: configure authentication and least privilege before publishing, not after testing public reachability.
Install the client on a suitable device
Use the supported installation package for your operating system from the current Localtonet product and installation documentation. The supplied installation evidence does not establish a universal command or complete operating-system matrix, so this guide does not invent an installer command. VPN Manager has additional version and privilege requirements explained below.
The client need not run on the service host. For example, a client on a server can target an embedded device on the LAN. However, local routing, VLAN rules, Wi-Fi isolation, and the target firewall must allow that connection. A tunnel cannot repair an unavailable local route.
Identify the bind address and listening port
A service bound to 127.0.0.1 accepts connections from the same machine. That is suitable when Localtonet runs there. A client on another LAN device cannot reach that loopback listener. For a separate target, configure an appropriate reachable interface and retain restrictive local firewall rules.
Confirm the port from the application’s configuration or logs rather than assuming a familiar default. Test from the device running Localtonet using exactly the address, port, and protocol you intend to configure. A successful test from a different computer does not prove that this client has the same route or permissions.
Protect the device token
The authentication token identifies the client device and must remain secret. Do not publish it in screenshots, repositories, tickets, chat transcripts, or shared shell history. Keep it separate from application credentials, and review screenshots for credentials before sharing them.
Protocol and scope decision guide
| Resource or goal | Likely approach | Target or access model | Key question |
|---|---|---|---|
| Website, API, webhook, dashboard | HTTP | Local IP and port; public HTTPS address | Does the app enforce authentication and authorization? |
| SSH | TCP | SSH listener; public host and port | Are accounts, keys, and privileges restricted? |
| Remote desktop | TCP, UDP, or combined | Actual transports required by the service | Should administration remain private through VPN Manager? |
| Non-HTTP TLS service | TLS where appropriate | Local TLS-speaking target | Does the remote client expect that protocol? |
| Game or real-time service | TCP, UDP, or combined | Required gameplay transport and ports | Which ports are essential? |
| IoT interface | HTTP or matching raw transport | One reachable device interface | Is the device safe for public exposure? |
| Selected folder | File Server | Default, SFTP, or WebDAV | Which paths and operations are allowed? |
| Device as an internet exit | HTTP or SOCKS5 proxy | Connected device becomes the exit node | Who is authorized to use it? |
| Multiple private resources | VPN Manager | Private mesh and optional LAN bridging | Which peers and destinations may communicate? |
Web applications and APIs
Development servers may expose debugging information, administrative actions, permissive cross-origin settings, or unfinished authorization. Before publishing, disable unnecessary debugging, remove unneeded routes, and use suitable authentication. Test host validation, redirects, cookies, and webhook verification with the public address, not just the local URL.
SSH and remote desktop
SSH uses TCP. A remote SSH client connects to the tunnel’s assigned public host and port, while the tunnel targets the actual local SSH listener. Keep SSH’s own security controls enabled, verify the server identity, restrict accounts, and maintain the server.
Remote desktop protocols differ, so confirm whether TCP, UDP, or both are required. Because desktop access can grant broad machine control, private VPN access is often the better trust boundary. Do not publish a desktop merely to retrieve one file.
Games and IoT devices
Do not choose UDP solely because an application is described as real time. Verify the game server’s actual transports, including any separate query or administration ports. Expose only necessary gameplay services; administration can use a separate, restricted path.
Embedded devices can be targeted from a reachable Localtonet client without installing our client on each device. However, many device consoles assume a trusted LAN and receive infrequent updates. Reachability is not proof that a camera, controller, or storage interface is safe to publish. Consider VPN Manager for these private resources.
When File Server is the narrower choice
For retrieving, uploading, organizing, or sharing files, remote desktop often grants more capability than necessary. File Server publishes a selected folder rather than an arbitrary IP-and-port service. Its three subtypes serve different clients:
Our File Server subtype guide describes these access models. The browser workflow below is not an SFTP or WebDAV configuration recipe. Use the endpoint and authentication requirements established for the selected subtype, not an assumed HTTPS URL, port, or credential format. Also check automation compatibility: standard rsync is not itself an SFTP client.
Default web manager capabilities
The Default File Server feature guide covers upload, download, rename, move, copy, delete, folder creation, search, preview, tags, archives, sharing, and keyboard cut/copy/paste. It has no upload size limit, although disk space and connection availability still matter.
Global permission flags include Upload, Download, Delete, Create Folder, Move, and Share. Per-path overrides take precedence according to the most specific matching path, and permission changes apply without restarting the tunnel. Public share links support expiry dates, download limits, and separate link passwords.
File-event webhooks report upload, delete, rename, and move events, with optional path filtering and HMAC signing. They are distinct from platform-wide connection lifecycle webhooks. Security defaults include path-traversal protection, per-IP rate limiting, hidden dotfiles, blocked executable extensions with an optional allowlist mode, and TLS termination at the tunnel edge.
Other Default capabilities include a recycle bin, version history with diff, full-text document search, inline document viewing, an integrated code editor, real-time updates, directory statistics, Smart Collections, disk spanning, and backup to S3 or S3-compatible storage, FTP, or SFTP.
Per-folder encryption uses AES-256-CBC with a key derived through PBKDF2 using 100,000 iterations. Neither password nor key is stored; a hidden .fsvault file holds a salt and verification hash. Unlock tokens last 30 minutes. There is no administrator override or password recovery, so preserve the password safely.
The supplied evidence does not establish whether per-folder encryption, Immich-compatible mobile backup, or Smart Collections applies to SFTP and WebDAV. The documented browser setup below is limited to Default. Separate subtype configuration and endpoint handling must be confirmed before using SFTP or WebDAV.
Configure the selected access model
Conceptual lifecycle, not a universal setup wizard
The common lifecycle is to run the client, select its device token and an available relay, configure the appropriate resource, start access, verify it, and stop or delete it when finished. This describes operating states, not a tunnel-specific sequence of dashboard fields.
Conventional tunnels target an IP address and port. File Server targets a folder. Proxy modes use the device as an exit node and should not be given an invented local service target. VPN Manager has its own workflow below. Creating a configuration does not mean it is running.
HTTP example: mapping a verified local application
Suppose your application already responds at http://127.0.0.1:3000 on the machine running Localtonet. This is an example target, not a required port. With curl installed, a local check can be:
curl --fail --show-error --include http://127.0.0.1:3000/Use a route appropriate to your app, and interpret the expected response rather than assuming every application returns success at its root. If this fails, fix the local service first. When configuring HTTP publishing, the local target in this example is 127.0.0.1 and port 3000, the device is the client on that machine, and the relay is one currently available in your dashboard. Random Sub Domain is the naming choice when you want a generated public name.
After configuration, explicitly start the tunnel and copy its displayed HTTPS address. Open that address from an external network and repeat a meaningful application action. Stop the tunnel and confirm that a new request through that endpoint no longer reaches the application.
This example explains verified target mapping and lifecycle behavior, not a verified reproduction of the HTTP setup screen. The supplied evidence does not contain the complete tunnel-specific field sequence. Follow the current HTTP tunnel documentation for that sequence; no undocumented buttons, installer commands, or DNS instructions are assumed here.
Documented Default File Server setup
The following six-step browser-oriented sequence follows our File Server documentation. Before starting, create a dedicated sharing folder containing only intended files. For example, use C:\LocaltonetShare on Windows or /srv/localtonet-share on Linux, with permissions set for the account running the client.
Install the Localtonet app for your operating system
Install and run the app on the device with access to the sharing folder.
Open the File Server Tunnel page
Use the browser-oriented Default File Server workflow, not a conventional IP-and-port tunnel.
Select the Process Type
Choose Random Sub Domain, Custom Sub Domain, or Custom Domain as applicable. A generated subdomain avoids introducing custom-domain DNS configuration into this example.
Select the AuthToken and server
Select the token for the intended device and a currently available server. Keep the token private.
Enter the dedicated local folder path
Enter your prepared sharing directory. Grant the client account only necessary filesystem access: read access for download-only use and write access only where intended. Do not publish a system directory, an entire home directory, or a folder containing credentials.
Press Start
Start the tunnel and test the resulting HTTPS address in a browser. Verify allowed operations and expected denials before sharing the address.
Filesystem permissions and File Server permissions are separate controls. A web permission cannot grant a filesystem operation denied to the client process. Conversely, broad filesystem access is not a reason to grant every browser operation. Use a disposable file to test uploads or deletion without risking real data.
Set up VPN Manager for private access
Our VPN Manager setup guide documents a free private mesh using existing Localtonet tokens, automatic Virtual IP assignment, optional LAN bridging, and granular firewall rules.
VPN Manager requires Desktop app v7.7 or later or Mobile app v10.0 or later, as applicable. It also requires administrative privileges on the machine running the client because creating virtual network interfaces is an operating-system operation. Update older clients before setup.
Prepare at least two intended devices for a connectivity test. Decide which client may reach which destination and service port. Do not bridge a whole LAN merely because the option exists; direct mesh-client connectivity may already meet your need.
Sign in to your Localtonet dashboard
Use your existing account or register an account if needed.
Open VPN Manager and create a VPN
Enter a VPN Name, choose an available Server Relay Node appropriate for your clients, and press Create. Select from current relay choices rather than copying a region code.
Confirm the assigned mesh subnet is active
The VPN appears with an assigned subnet and Active status. Client Virtual IPs are assigned from this subnet; use the actual displayed values.
Add clients using existing Tokens
Click Add Client on the VPN row, select the Token Name installed on the intended device, and click Add. The client remains Offline until its app connects with that token, then shows Online and receives a Virtual IP.
Optionally bridge a client’s local LAN
Open LAN on the client row and create a LAN entry using the intended local subnet and the client’s real gateway IP on that LAN. Skip this step’s optional configuration when only mesh devices need access. Review the wider resource scope before bridging.
Set firewall rules
Open Firewall on a client row, click Create Rule, and define Action, Protocol, target client, and Ports. Save the rule. Changes take effect immediately without a restart.
Firewall actions include Allow and Deny. Protocol choices include All, TCP, UDP, and ICMP; port specifications can be a single port, comma-separated list, or range. Targets can cover all clients or one specific client. Prefer narrow rules for the required connection. Do not assume undocumented rule ordering or conflict behavior.
Verify an allowed connection and an expected denial
First confirm that both test clients show Online. From the intended source, connect to the destination’s displayed Virtual IP using the real application protocol and port. For example, test SSH only if an SSH server is running and your rules permit that connection. Confirm the server identity and complete the expected authenticated action.
Then test a connection your policy should deny, such as the same service from an excluded test client or a separate listening service on a restricted port. Establish that the denied target is actually running and reachable through an authorized path; otherwise, failure proves only that the service may be unavailable. Do not use a failed ping as proof that TCP or UDP is blocked.
For LAN bridging, separately test an intended LAN destination and an out-of-scope destination that should remain denied. Host firewalls and application authentication still apply. Repeat these checks after membership, route, or firewall changes.
Verify locally, remotely, and after stopping access
Prove the local application
Check more than a listening socket. Load a meaningful web route, complete an SSH login with the expected server identity, or use the actual game client. For a LAN target, run the test from the Localtonet client device. For File Server, confirm the folder exists and the client account has the intended permissions.
Test the assigned public endpoint
For HTTP and Default File Server, open the exact public HTTPS address from another network, such as a phone on cellular data. Verify the page, certificate behavior, login, authorization, and important application operations. Signed-out users should not receive protected content. Read-only file access should not permit uploads or deletion. Webhook receivers should reject invalid signatures according to their application design.
For raw transport tunnels, use the assigned public host and port, not the local LAN address or an assumed public port. Test SSH with an SSH client, a game with its game client, and UDP with an application-aware UDP test. A successful TCP connection cannot establish UDP functionality. For SFTP or WebDAV, use the endpoint and client settings documented for that subtype rather than translating a browser address by guesswork.
Test lifecycle and revocation
The endpoint is available only while the selected client is connected and the tunnel is running. After testing, stop the tunnel and attempt a new connection through its public endpoint. Start it again only if continued access is needed. Delete obsolete configurations and separately remove credentials or user permissions that should no longer work.
Check existing router port forwards, automatic mappings such as UPnP or NAT-PMP, IPv6 inbound firewall policy, other tunnels, and other remote-access agents. A globally addressed IPv6 service can have an ingress path without an IPv4 port forward. Remove unintended routes and test from outside the LAN with authorization. Tunnel shutdown proves only that the tested tunnel path has stopped.
Least privilege and routine operation
Record the owner, purpose, target, protocol, permitted users, and intended end date for every access path. If a collaborator only needs a web preview, do not provide SSH. If a job only needs one folder, do not expose the desktop. Keep administration separate from public gameplay, application traffic, or file delivery.
Router consoles, hypervisors, storage administration, and camera management often provide broad control. Keep them private unless there is a reviewed reason to publish them. A private mesh still requires restricted peer access, host firewalls, and application authentication.
A public endpoint address is not a password. Maintain strong, separate service credentials and remove access when a collaborator or device no longer needs it. If a token may have leaked, treat that as a credential incident and revoke or replace access through the supported account workflow, not merely by stopping one tunnel.
Monitor the right events
Our Token and Tunnel webhook documentation describes connection lifecycle notifications for a selected Token Group. The POST body uses Id, ActionDate, Type with Token or Tunnel, and Status with Connected or Disconnected.
These notifications help track connectivity, but do not prove application health or authorized use. File Server’s separate file-event webhooks report uploads, deletes, renames, and moves and support optional HMAC signing. Do not assume those signing capabilities apply to platform-wide lifecycle webhooks.
Periodically review active configurations, patch targets, remove stale access, and retest denials. After a restart or network change, verify both client connectivity and running state before assuming a public endpoint has recovered.
Troubleshooting common failures
The client is disconnected or the tunnel is stopped
Confirm that the machine is awake, the app is running, the intended token is selected, and outbound connectivity is permitted. A saved tunnel may still need Start. Review its target before restarting an old configuration. For VPN Manager, check supported app versions, administrative privileges, and each client’s Online status.
The local target cannot be reached
Test directly from the Localtonet client device. Check the actual listener, port, bind address, LAN address, routes, VLAN boundaries, Wi-Fi isolation, and host firewall. A loopback-only service cannot be reached by a client on another host. Do not solve this by broadly opening interfaces without reviewing the resulting LAN exposure.
The protocol or public endpoint is wrong
Compare the tunnel type with the application’s real transport. TCP cannot carry a UDP-only service, a browser cannot validate arbitrary TCP, and TLS should not be assumed to provide HTTP behavior. Copy the current public endpoint exactly, including its assigned port where applicable.
The tunnel delivers traffic but the application rejects it
Inspect application logs for failed authentication, insufficient permissions, host validation, origin checks, incorrect paths, unsupported negotiation, or account lockout. Compare the request with a successful local test. Do not disable authorization to make a connectivity test pass.
A restrictive network blocks the client
Check egress filtering, DNS restrictions, required proxies, captive portals, and endpoint security software. Work with the network owner using current Localtonet guidance. Outbound tunneling is not permission to bypass organizational policy.
File Server opens but operations fail
For Default, check the folder path, filesystem permissions, global operation flags, and more-specific path overrides. The most specific path rule wins. An encrypted folder needs the correct password; there is no administrator recovery. For SFTP or WebDAV, troubleshoot against that subtype’s documented behavior rather than assuming browser features apply.
VPN access fails or reaches too much
Confirm Online status, the actual Virtual IP, the destination listener, and firewall scope. For LAN bridging, check the configured subnet, gateway value, and local reachability. If a denied connection succeeds, narrow the access policy and inspect alternate routes before relying on the mesh boundary.
Frequently asked questions
Can I use Localtonet without opening router ports or having a public IP?
Yes. Our client initiates an outbound relay connection, so an inbound router mapping or directly reachable public IP is not required. The network must still permit that outbound connection, including on CGNAT connections.
Should I use HTTP, TCP, or TLS?
Use HTTP for web applications needing a public HTTPS address, TCP for raw TCP services such as SSH, and TLS when it matches the specific TLS-based service and configuration. A TLS tunnel is not interchangeable with HTTP publishing.
Can a tunnel reach another device on my LAN?
Yes, for local-target tunnel types, if the Localtonet client can reach that device’s address and port. Test from the client device before publishing.
When should I use VPN Manager?
Use it for private connectivity between approved devices or to selected LAN resources. It requires Desktop v7.7 or later or Mobile v10.0 or later, as applicable, plus administrative privileges for interface creation. Configure firewall rules and verify both allowed and denied connections.
Is File Server narrower than remote desktop?
It can be when users only need a selected folder. Use a dedicated directory and least-privilege permissions. Default, SFTP, and WebDAV are distinct access models; the browser setup in this guide is not a universal subtype recipe.
Does creating or stopping a tunnel control all service exposure?
No. Creation does not start the tunnel, and stopping it removes only that access path. Check other tunnels, existing port forwards, automatic mappings, and IPv6 ingress independently.
Does an outbound tunnel make an insecure application safe?
No. The published application still needs authentication, authorization, updates, and safe configuration. Choose the narrowest access model and remove temporary access when the task ends.
Build a protocol-first remote access path
Verify your target locally, choose the matching service tunnel, dedicated folder, proxy, or private mesh, and test the access boundary before sharing it. With Localtonet, you can manage that workflow without opening an inbound router port.
Get Started Free →
