Remote Access Without Port Forwarding: Protocol Guide

Why protocol should come before router configuration

Traditional remote-access planning often starts at the network edge: find the router, assign an internal address, create a port-forwarding rule, and determine how external users will locate the connection. That approach focuses on transport before establishing what the user actually needs. It can also become impractical when the connection has no public IP address, the router is outside the administrator’s control, or inbound traffic cannot be forwarded.

A protocol-first design reverses the process. First identify the resource, its native protocol, its intended users, and the minimum necessary scope. A local web application generally needs an HTTP tunnel and a public HTTPS address. SSH and remote desktop normally need raw TCP connectivity. Real-time or datagram-oriented software may require UDP, while some applications need both TCP and UDP. File access can use a purpose-built File Server tunnel instead of exposing a broader administration service. Private access to multiple devices or LAN resources belongs in a mesh VPN design rather than a collection of public tunnels.

With Localtonet, the client application on the device establishes an outbound connection to one of our relay servers. A tunnel then provides a public URL or public host and port, depending on the selected tunnel family. Because the connection originates from the client side, the workflow does not require inbound router port forwarding, a public IP address, VPN setup, or firewall changes. The client device must still be able to make the required outbound connection.

The six remote-access models

Protocol and scope decision table

Choosing access for common developer scenarios

Web dashboards, development servers, and APIs

Choose an HTTP tunnel when the target already speaks HTTP or HTTPS and the remote user should interact through a browser or web client. Typical examples include a local development site, an API under active testing, a webhook receiver, and an IoT dashboard. HTTP and File Server tunnels support Random Sub Domain, Custom Sub Domain, or Custom Domain process types, and each serves content at a public HTTPS address.

A convenient public address does not make the underlying application safe by itself. Development servers may expose debugging information, administrative actions, sample credentials, or unfinished authorization logic. Before starting a tunnel, remove unnecessary endpoints, require application-level authentication, limit user privileges, and avoid exposing an administrative panel when private network access is the more appropriate design.

SSH and remote desktop

SSH is a TCP service, so a TCP tunnel is the direct protocol match. The tunnel points to the SSH server’s local IP address and port, and the remote client connects through the assigned public host and port. Keep SSH’s own security controls enabled. Prefer strong authentication, restrict the available accounts, apply least privilege, and maintain the operating system and SSH service.

Remote desktop selection depends on the protocol and its transport requirements. If the service uses TCP, a TCP tunnel can carry it. If it also depends on UDP, consult the application’s current documentation and select the matching UDP or combined UDP/TCP option. For a sensitive personal or infrastructure administration interface, consider whether VPN Manager offers a more suitable private access boundary than a publicly reachable raw endpoint.

Game servers and UDP applications

Do not select UDP merely because an application is described as real time. Confirm which transport and port the server actually listens on. Some game servers use TCP, some use UDP, and others use both for different functions. Localtonet supports TCP, UDP, and combined UDP/TCP tunnel categories, allowing the tunnel type to follow the application instead of forcing the application into the wrong transport.

Forward only the ports required by the service. A game server port does not require publishing its management console, file service, database, or host administration interface. Separating gameplay access from administration access reduces unnecessary exposure and creates a clearer lifecycle for each connection.

IoT devices and systems on another LAN host

The Localtonet client does not always need to run on the same machine as the target service. HTTP, TCP, UDP, combined UDP/TCP, and TLS tunnels can point to a local IP address and port that is reachable from the client device. This can be useful when the target is an embedded device that cannot run the client itself.

Reachability is not the same as suitability for internet exposure. Many embedded interfaces are designed for trusted local networks and may have limited authentication or infrequent security updates. If several devices must be administered, or if access should remain private, use VPN Manager and granular firewall rules rather than creating a public endpoint for every device.

When File Server is the narrower choice

If the real requirement is to retrieve, upload, organize, or share files, exposing a general remote desktop or machine administration service may grant more capability than the task requires. A Localtonet File Server tunnel publishes a selected local folder path rather than an arbitrary IP and port service.

The Default browser file manager includes global permissions for Upload, Download, Delete, Create Folder, Move, and Share, plus per-path overrides where the most specific path wins. Permission changes apply without restarting the tunnel. Public share links can have an expiry date, download limit, and separate link password. Its security defaults also 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.

Per-folder encryption in the Default web manager uses AES-256-CBC with a key derived through PBKDF2 using 100,000 iterations. The password and key are not stored. Only a salt and verification hash are kept in a hidden .fsvault file, and unlock tokens last 30 minutes. There is no administrator override or password recovery, so the folder password must be preserved safely. Current verified information does not establish whether this encryption behavior, Immich-compatible backup, or Smart Collections applies to the SFTP and WebDAV sub-types, so we do not assume that it does.

How to configure remote access with Localtonet

The exact tunnel fields depend on the selected family, but the supported workflow follows the same lifecycle. Current server and region choices must always be obtained from our dashboard rather than copied from an old guide.

A practical least-privilege checklist

Start by inventorying the remote user, target resource, required protocol, and permitted actions. If a collaborator only needs to preview a web application, do not provide SSH. If an automation job only needs one folder through SFTP, do not expose the desktop. If an administrator needs several private systems, avoid creating a separate public tunnel for every management interface when a mesh VPN and firewall rules better express the intended trust boundary.

Separate service access from administrative access. A public game endpoint can be independent from the server’s SSH tunnel. A browser application can be published while its database remains local. File Server permissions can distinguish downloading from uploading, deleting, moving, creating folders, and sharing. VPN Manager firewall rules can limit communication between peers and networks instead of treating every connected device as equally trusted.

Finally, test from outside the local network. Confirm the expected protocol works, unauthorized users cannot perform restricted actions, and unrelated local resources remain unreachable. Document who owns the tunnel, why it exists, which local target it reaches, and when it should be stopped. Our dashboard and REST API provide a central place to manage tunnel configurations, but operational ownership and periodic review remain important.

Frequently asked questions