Build a controlled connectivity path to remote IoT gateways without opening inbound ports
Secure over-the-air maintenance requires more than a public endpoint. A dependable design separates firmware signing, artifact delivery, rollout orchestration, device health, rollback, and audit records from the network path used to reach devices. In this guide, we explain how outbound Localtonet tunnels can connect an existing OTA system or maintenance operator to IoT gateways behind NAT or CGNAT. We also cover protocol selection, staged deployment, least privilege, verification, incident response, and closing tunnels after maintenance.
📋 What's in this guide
Start with the right OTA architecture
IoT devices are commonly deployed on private networks that operators do not control. A gateway might receive a private address from a retail router, sit behind a corporate firewall, or use a cellular connection placed behind carrier-grade NAT. In all three cases, an operator on the public internet normally cannot initiate a direct connection to the device. A public IP address may not exist, and inbound port forwarding may be unavailable or prohibited.
With Localtonet, the client running on the device establishes an outbound connection to a Localtonet relay server. A running tunnel then provides either a public URL or a public host and port, depending on the selected tunnel type. This avoids requiring inbound router port forwarding, firewall changes, a public IP address, or a separate VPN setup for the tunnel workflow.
That solves a connectivity problem, but connectivity is only one part of secure OTA fleet management. Localtonet does not sign firmware, decide which release should be installed, maintain a device inventory, evaluate device health, or orchestrate deployment waves. Those responsibilities remain with the OTA platform and operational controls selected by the fleet owner.
Keeping these responsibilities separate limits the consequences of a failure. A tunnel should not automatically imply permission to install arbitrary firmware. Similarly, possession of an artifact should not be enough to activate it. The maintenance service should authenticate and authorize every sensitive operation, while the device boot and update process should independently verify that the artifact is approved.
A typical connection path
A practical design places the Localtonet client on the IoT gateway itself or on a management host that can reach the gateway's private service. The local maintenance service listens on an intentionally selected interface and port. The Localtonet tunnel points to that local IP address and port. An authorized operator or OTA component then uses the assigned public URL or host and port to reach the service.
Installing the client directly on a gateway gives that device its own connectivity identity. Installing it on a site management host can centralize connectivity, but it also expands that host's reach. If one site host can connect to many controllers, compromise of that host may expose a larger part of the site network. Choose the placement based on trust boundaries rather than convenience alone.
A public URL or host and port creates reachability. The target service must still enforce authentication, authorization, input validation, rate controls where appropriate, and safe update policy. Do not expose an unauthenticated administrative interface or rely on an unguessable address as the only protection.
Prerequisites and design decisions
Before configuring a tunnel, document the local service that needs to be reached and the exact purpose of that access. Avoid starting with a broad requirement such as “remote access to every device.” A safer requirement is specific, such as allowing the OTA controller to call an authenticated HTTPS maintenance API on a gateway during a scheduled deployment window.
The following items should be available before the first field test:
- A gateway or management host capable of running the Localtonet client.
- Outbound internet connectivity from that host to the Localtonet relay selected in the current dashboard.
- An existing OTA service, update agent, maintenance API, or raw TCP service that can be tested locally before it is exposed.
- A known local IP address and port reachable from the machine running the Localtonet client.
- A device-specific Localtonet authentication token obtained from the current product workflow.
- An available relay server or region selected from the current dashboard rather than hardcoded into deployment documentation.
- A documented method for authenticating operators or machines to the target maintenance service.
- A firmware signing and device-side verification process appropriate for the hardware platform.
- A device inventory that records hardware revision, bootloader compatibility, installed software, deployment group, and recovery status.
- A tested rollback or recovery mechanism for interrupted downloads, failed installation, unsuccessful reboot, and post-update health failure.
Exact Localtonet installation commands, package names, and operating-system support details are not included here because those values must come from the current Localtonet download and product workflow. We do not guess client commands or claim support for an unverified hardware architecture. Confirm that the target gateway operating system and processor have a current compatible client before defining the fleet design around it.
Verify the service locally first
Test the maintenance service from the gateway itself and, if relevant, from the machine that will run the Localtonet client. Confirm that the expected endpoint responds, authentication succeeds only with valid credentials, unauthorized actions are rejected, and the service survives a normal restart. If a local request fails, adding a tunnel will not repair the application, routing, certificate, or firewall issue.
Record the service's actual bind address. A service bound only to loopback is reachable from a Localtonet client running on the same host, but not necessarily from a separate management host. A service bound to a LAN address may be reachable from another machine at the site, but that also changes local exposure. Use the narrowest binding compatible with the design.
Define the maintenance window
Decide whether a tunnel should be continuously available or started only for planned maintenance. The safer choice depends on operational requirements. On-demand access reduces exposure time, while continuous connectivity can support unattended OTA activity and emergency recovery. In either case, define who may start and stop the tunnel, what should happen after a gateway reboot, and how an unexpectedly disconnected tunnel is handled.
In Localtonet, tunnel creation and tunnel operation are separate lifecycle states. After configuration, the tunnel must be started with the Start button. It remains available only while the selected client or device is connected and the tunnel is running.
Choose between HTTP and TCP connectivity
Select the tunnel family based on the protocol spoken by the local maintenance service. Do not choose TCP merely because it appears more general. Protocol-aware HTTP access is normally the clearer fit for a web dashboard, REST API, or browser-based management service. Raw TCP is appropriate when the application uses a non-HTTP stream protocol or an administrative protocol carried directly over TCP.
| Option | Best fit | Public access form | Important consideration |
|---|---|---|---|
| HTTP tunnel | Web dashboards, webhooks, REST APIs, and HTTP-based maintenance services | Public HTTPS address | The application must still authenticate and authorize sensitive OTA actions. |
| TCP tunnel | Non-HTTP services that communicate over a raw TCP connection | Public host and port | The client application must understand the target protocol and enforce its own access controls. |
| Site gateway pattern | A controlled management host that reaches one or more private devices | Depends on the selected HTTP or TCP tunnel | The gateway becomes a high-value trust point and should not provide unrestricted lateral access. |
| Per-device pattern | Devices that can each run the Localtonet client and require separate identities | One configured endpoint per required device service | Token handling, inventory mapping, lifecycle management, and endpoint ownership must scale with the fleet. |
HTTP process types
Localtonet HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain as their Process Type. These process types serve the same local content at a public HTTPS address. Availability can vary, and exact custom-domain DNS requirements must be checked against current Localtonet documentation before implementation.
A generated address is useful for a controlled proof of concept, but production automation should not assume that an address is permanent unless the selected configuration explicitly provides the required stability. Store endpoint ownership in the device inventory and avoid embedding an unverified address permanently into firmware.
When not to expose a device service
A tunnel is unnecessary if every device securely pulls signed updates from an artifact service and no inbound-style maintenance session is needed. In that design, the OTA agent initiates all communication. Add remote connectivity only for a defined use case, such as diagnostics, a local management API, an operator-approved recovery action, or access to an existing controller that cannot initiate the complete workflow.
Also avoid exposing a broad site administration panel when a smaller purpose-built endpoint can perform the required operation. A narrowly scoped service that reports version, accepts an approved deployment command, and returns health status is easier to authorize and audit than a general shell or unrestricted device console.
Configure the Localtonet connectivity layer
The Localtonet portion of this architecture follows the standard tunnel workflow. The steps below intentionally avoid fabricated client commands, relay codes, domain records, and dashboard values. Obtain all account-specific and current values from our platform.
Install and run the Localtonet client
Install the current client on the IoT gateway or management device that can reach the local OTA or maintenance service. Confirm that the client can make its required outbound connection. Use the current Localtonet installation workflow for the device operating system and architecture.
Authenticate or select the device
Associate the client with its device-specific authentication token. Treat the token as a secret, keep it out of firmware images, screenshots, tickets, and source repositories, and do not reuse guessed values. Record the device-to-token relationship in a protected operational inventory without exposing the token itself.
Select an available relay server or region
Choose from the values currently presented by the Localtonet product or dashboard. Do not hardcode a server code copied from an unrelated device or an old deployment guide because available values may change by plan, version, region, or deployment.
Create the appropriate tunnel configuration
Choose HTTP for an HTTP-based management service or TCP for a raw TCP service. Enter the local IP address and port of the service as reachable from the Localtonet client device. For HTTP, select the appropriate available Process Type. Keep the target as narrow as the maintenance workflow permits.
Start the tunnel and test the assigned endpoint
Use the Start button after reviewing the target. Test the resulting public URL or host and port with an authorized maintenance client. Confirm both successful access and rejection of unauthorized requests before using the endpoint in an OTA rollout.
Stop or delete the tunnel when appropriate
Stop the tunnel after an on-demand maintenance window. Delete configurations that are no longer required. If the design requires a persistent tunnel, document that exception, monitor its state, and periodically confirm that the endpoint still targets the intended local service.
Everything is managed from a single Localtonet dashboard or REST API, but an API-driven fleet workflow should only be implemented against current API documentation. This guide does not invent request schemas, endpoints, or token formats. Automation credentials should be separated from device tokens and restricted according to the controls available in the current environment.
Map connectivity to inventory
For each device or site, the inventory should record a stable internal device identifier, hardware model, hardware revision, installed software version, deployment group, local service type, responsible owner, and the Localtonet tunnel identifier or endpoint assignment needed for operations. Do not make a public URL the sole device identity because endpoints and tunnel configurations can change.
The inventory should also distinguish between a tunnel that has been created, a client that is connected, and a tunnel that is actually running. These are operationally different states. An OTA scheduler that treats “configured” as “reachable” can start a deployment against an unavailable target.
Design a staged OTA rollout
Fleet-wide updates should progress through deliberately limited groups. The exact group sizes depend on fleet scale, failure tolerance, device criticality, connectivity cost, and the ability to recover a failed unit. A safe process starts with laboratory hardware, then a small canary set, then progressively larger production groups only after explicit health gates pass.
Sign artifacts and verify them on the device
The artifact delivery channel and the authenticity of the artifact are separate concerns. A protected network path does not prove that a firmware image was produced and approved by the fleet owner. Sign release artifacts using a controlled signing process, and configure the device or bootloader to verify the signature before installation or activation.
The signed metadata should bind the release to the intended artifact and relevant compatibility constraints. Depending on the OTA implementation, those constraints may include product family, hardware revision, bootloader level, version, or anti-rollback policy. The precise metadata format and cryptographic algorithm are platform-specific and must follow the hardware and OTA system documentation. They are not provided by the Localtonet tunnel.
A device should reject a modified, unsigned, untrusted, corrupted, or incompatible artifact before changing its active software. Download completion alone is not deployment success. Success should include signature verification, installation, activation, reboot where required, and post-update health confirmation.
Plan for interrupted connectivity
Field links can disappear during download or installation. An OTA design should define whether downloads resume, restart, or fail safely. It should prevent a partial artifact from being treated as complete and preserve enough state to report the failure after connectivity returns.
The tunnel is available only while the selected Localtonet client is connected and the tunnel is running. If a reboot stops the client or temporarily removes network connectivity, the public endpoint may be unavailable during that period. The OTA workflow must expect this transition rather than declaring immediate failure solely because the endpoint disappears during an intentional reboot.
Apply least privilege across the complete path
Least privilege should cover the Localtonet account, device token, tunnel target, maintenance application, OTA service, signing process, and human operators. No single credential should unnecessarily grant control over the entire fleet.
Protect device authentication tokens
A Localtonet authentication token identifies the client device that runs the tunnel. Tokens are device-specific and must not be guessed, published, or embedded in examples. Provision them through a protected process, restrict who can retrieve them, and avoid placing them in shared firmware images. If a token is exposed, follow the current Localtonet account workflow to replace or invalidate it and update the affected device securely.
Do not print tokens into ordinary application logs. Diagnostic bundles collected from field devices should redact secrets. Support personnel should be able to identify a device through an inventory ID without viewing its raw token.
Constrain the local target
Point the tunnel only to the required local IP address and port. Do not expose a broad administrative listener when the OTA workflow needs one narrow API. If the Localtonet client runs on a site gateway, use host firewall and application policy to prevent that gateway from becoming an unrestricted route to unrelated systems.
The target application should use separate roles for status checks, deployment approval, update initiation, rollback, and general administration where the application supports those distinctions. Machine-driven OTA access should not automatically inherit the privileges of a human fleet administrator.
Authenticate every request
Require application-layer authentication at the maintenance service. For machine-to-machine access, use a credential mechanism supported by the OTA product and rotate credentials according to fleet policy. For human maintenance, require individually attributable identities rather than shared passwords. Apply IP restrictions or other access controls when supported by the selected application and deployment.
Never place maintenance credentials, signing keys, Localtonet tokens, or private endpoint details in firmware source code, public repositories, documentation screenshots, or support messages. A tunnel address should be treated as operational information, not as an authentication factor.
A device generally needs the trusted public verification material, not the private key used to sign production releases. Protect signing keys in a controlled signing environment and separate release approval from routine tunnel operation. Compromise of a gateway should not provide the ability to create firmware accepted by the rest of the fleet.
Separate duties
Consider requiring different permissions for creating connectivity, approving a release, initiating a production rollout, and authorizing rollback. Separation of duties reduces the chance that one compromised account or operator mistake can both publish an artifact and deliver it fleet-wide.
Emergency procedures should remain controlled. A recovery event may justify fast action, but it should not eliminate artifact verification, identity checks, or recording of operator decisions. Pre-approved recovery images and documented break-glass access are safer than inventing a new process during an outage.
Verify connectivity before trusting it with updates
Verification should proceed from the inside out. First prove that the local service works. Then prove that the Localtonet client can reach it. Next test the public endpoint with valid and invalid credentials. Finally test the complete update sequence on non-production hardware.
Confirm local service health
From the gateway or client host, connect to the configured local IP address and port. Verify expected status responses, authentication behavior, version reporting, and safe rejection of malformed or unauthorized requests.
Confirm device and tunnel state
Verify that the correct Localtonet client is connected, the intended tunnel configuration is selected, and the tunnel has been explicitly started. Check that the configured target matches the reviewed local service.
Test authorized remote access
Use the assigned public URL or host and port from a controlled maintenance client. Confirm that an authorized status or diagnostic operation reaches the intended device and returns the expected device identity.
Test negative security cases
Verify that missing, invalid, expired, or insufficient application credentials are rejected. Confirm that low-privilege identities cannot initiate deployment, rollback, or unrelated administrative actions.
Run a non-production OTA cycle
Deliver an approved test artifact to representative hardware. Observe download, verification, installation, reboot, reconnection, version reporting, and post-update health checks. Also test a deliberately invalid artifact and confirm that the device rejects it safely.
Exercise failure and rollback paths
Simulate realistic failures supported by the test environment, such as interrupted connectivity or an unhealthy application after activation. Confirm that the device retains or restores a known-good state and that operators can determine what happened.
Define success precisely
A successful tunnel test proves only that traffic reached a local service. A successful OTA test should prove more: the correct device received the intended artifact, verified it, installed it, entered the expected runtime state, restored connectivity if a reboot occurred, and reported healthy operation for the required observation period.
Include device identity in the verification response wherever the maintenance service supports it. Before sending a state-changing command, compare that identity with the inventory record associated with the tunnel. This helps detect accidental endpoint-to-device mapping errors.
Use connectivity state as a signal, not a complete diagnosis
Localtonet provides platform-wide Token/Tunnel webhooks that can report Connected or Disconnected changes for a selected Token Group. The POST body is a WebHookRequest containing Id, ActionDate, Type, and Status. The type is Token or Tunnel, and the status is Connected or Disconnected.
These events can help an operations system notice connectivity transitions, but they do not prove firmware installation success or device health. A disconnected event may result from a planned reboot, loss of site internet access, client shutdown, or another operational condition. Correlate connectivity events with OTA state and device telemetry before taking automated recovery action.
Platform-wide Token/Tunnel webhooks report connection state. Localtonet File Server webhooks report file-level events such as upload, delete, rename, and move. They are separate systems. An HTTP or TCP OTA tunnel should not be documented as producing File Server file-event notifications.
Operate, troubleshoot, and recover safely
Production reliability depends on routine practices after initial setup. Assign ownership for every tunnel, review whether each endpoint is still needed, and remove obsolete configurations. Include Localtonet connectivity in device retirement procedures so that a decommissioned gateway does not retain an active token or tunnel configuration.
Routine maintenance checklist
- Confirm that each endpoint maps to the expected inventory record and owner.
- Review whether the local target IP address and port still correspond to the approved maintenance service.
- Verify that persistent tunnels are still justified and that on-demand tunnels are stopped after use.
- Remove access for departed operators and rotate application credentials according to policy.
- Review OTA deployment records, failed devices, rollback events, and unexplained connectivity changes.
- Test recovery on representative hardware after bootloader, partitioning, hardware, or OTA-agent changes.
- Keep secrets out of support bundles and redact them before sharing diagnostic information.
Troubleshooting common failures
| Symptom | Likely area | Checks |
|---|---|---|
| The public endpoint is unavailable | Client or tunnel lifecycle | Confirm the selected device is connected and the tunnel has been started. A created configuration is not automatically running. |
| The tunnel is running but the service does not respond | Local target | Test the configured IP address and port from the Localtonet client host. Check service state, bind address, local routing, and host firewall policy. |
| The wrong device answers | Inventory mapping | Stop state-changing activity. Compare the tunnel, token-associated device, application-reported identity, and asset inventory before proceeding. |
| Access works locally but authorization fails remotely | Application security | Check the maintenance client's credentials, role, request format, and application policy. Do not weaken authentication merely to make the tunnel test pass. |
| The endpoint disappears during an update | Reboot or connectivity transition | Determine whether the device rebooted as planned, lost site connectivity, stopped the Localtonet client, or entered recovery. Correlate tunnel state with OTA logs. |
| The device rejects the firmware | Artifact validation | Check signature validity, artifact integrity, release metadata, hardware compatibility, version policy, and trusted verification material. |
| The device installs but fails health checks | Application or rollback | Pause the rollout, preserve diagnostics, activate the tested rollback process, and do not expand the deployment wave until the cause is understood. |
Respond to a suspected token or endpoint compromise
Stop the affected tunnel when operationally safe, preserve relevant records, and use the current Localtonet account controls to replace or invalidate exposed access. Rotate credentials accepted by the target maintenance service as well, because stopping a tunnel does not remediate an application credential that may have been copied.
Determine which device, tunnel, local service, and maintenance operations were in scope. Review the OTA system for unexpected deployment attempts, artifact changes, rollback requests, or inventory modifications. Re-enable connectivity only after the target service and credentials are in a known state.
Handle offline devices deliberately
A device that is offline during a rollout should not automatically be treated as safely updated or permanently failed. Keep it in a pending or exception state according to OTA policy. When it reconnects, re-evaluate whether the original release is still approved for that hardware and deployment group. Do not blindly replay a stale maintenance command.
For safety-critical or operationally sensitive devices, define a maximum time a unit may remain on an older release and a field-service process for devices that cannot be recovered remotely. Remote connectivity can reduce site visits, but it cannot guarantee recovery from failed storage, loss of power, damaged hardware, or a boot failure that prevents the operating system and Localtonet client from starting.
Know when a different network pattern is appropriate
A per-service tunnel is useful when a specific gateway service needs controlled public reachability. If the requirement is private communication among multiple networks or broad access to many internal services, evaluate whether Localtonet VPN Manager is the more appropriate product family. VPN Manager is our private mesh VPN feature with granular firewall rules and LAN bridging. Standard HTTP and TCP tunnels should not be described as VPN connectivity.
Even when a mesh network is used, OTA signing, device authorization, staged deployment, inventory, health checks, and rollback remain separate responsibilities. Changing the network topology does not remove those requirements.
Frequently asked questions
Can Localtonet perform firmware signing or OTA orchestration?
No. Localtonet provides the connectivity layer that can expose a local maintenance service through an outbound tunnel. Firmware signing, artifact storage, deployment grouping, rollout policy, device health evaluation, inventory, and rollback orchestration must be supplied by your OTA system and operational processes.
Do IoT gateways need public IP addresses or inbound port forwarding?
Not for the Localtonet tunnel workflow. The client on the gateway or reachable management host establishes an outbound connection to a Localtonet relay. This can expose the selected local service without an inbound router rule or public device IP. The network must still permit the client's required outbound connectivity.
Should an OTA maintenance service use an HTTP or TCP tunnel?
Use an HTTP tunnel for an HTTP-based API, dashboard, or webhook service. Use a TCP tunnel for a non-HTTP service that communicates over a raw TCP stream. The selected protocol does not replace application authentication or authorization.
Does creating a tunnel make the device immediately reachable?
No. Creating the tunnel stores its configuration. The tunnel must also be started, and the selected Localtonet client device must be connected. If either the client connection or running tunnel is unavailable, the assigned public endpoint will not provide access to the local service.
Should every IoT device receive its own Localtonet token?
A Localtonet device token identifies the client device that runs a tunnel. If the client runs separately on each IoT gateway, each client must use its appropriate device-specific token. A site-gateway design can instead run the client on a management host that reaches local devices, but that centralizes trust and requires strict controls against lateral access.
Can a tunnel remain active continuously?
A tunnel is available while its selected client is connected and the tunnel is running. Whether it should remain active is an operational decision. Persistent access can support unattended workflows, while on-demand access reduces exposure time. In either case, protect the target service, monitor ownership and state, and remove configurations that are no longer needed.
Can Localtonet connectivity recover a device that no longer boots?
Not if the failure prevents the operating system, network connection, or Localtonet client from running. Recovery from that condition requires a device-level mechanism such as a working fallback image, bootloader recovery, out-of-band hardware management, or physical service. Test that mechanism before production rollout.
Are Localtonet connection webhooks proof that an OTA update succeeded?
No. Token/Tunnel webhooks report Connected or Disconnected state. They can help correlate a reboot or loss of connectivity, but update success must come from the OTA system and device health checks. Verify the installed version, application state, and required post-update behavior.
Connect your OTA maintenance service with Localtonet
Start with one representative gateway, verify the local service and rollback path, then create a narrowly scoped HTTP or TCP tunnel through an outbound Localtonet connection. Keep firmware trust and rollout control in your OTA system, and expand only after the complete workflow passes security and recovery testing.
Get Started Free →
