Expose a CoAP Device with a Localtonet UDP Tunnel

How a Localtonet UDP tunnel fits into CoAP remote access

A CoAP server in a development lab is commonly reachable only from its own computer or local network. It might listen on a loopback address, a LAN address, a container network, or an interface attached to an embedded-device gateway. A remote client cannot normally send a datagram directly to that private address because private addresses are not routed across the public internet and inbound NAT or firewall rules may not exist.

With Localtonet, our client application runs on a device that can reach the CoAP server. The client establishes an outbound connection to a Localtonet relay server. A UDP tunnel then provides a public host and port and points incoming UDP traffic toward the configured local IP address and port. This removes the need to configure inbound router port forwarding, make firewall changes for a new public listener, deploy a VPN, or obtain a public IP address for the lab network.

The placement of the Localtonet client matters. It does not have to run inside the same process as the CoAP server, but the selected client device must be able to route traffic to the local target. If the server listens only on 127.0.0.1, the Localtonet client normally needs to run on that same host. If the server listens on a LAN interface, the client can run on another reachable device, subject to the server host's local firewall and routing rules.

This architecture changes how the remote client reaches the service, but it does not change CoAP into a connection-oriented protocol. CoAP message correlation, retransmission, timeout, duplicate detection, Observe, block-wise transfer, and DTLS behavior remain the responsibility of the participating CoAP implementations. Those behaviors should be tested across the complete public path instead of inferred from a successful one-packet request.

CoAP behavior that matters across a UDP tunnel

The Constrained Application Protocol, or CoAP, is a compact application protocol designed for constrained nodes and constrained networks. It offers a resource model familiar to developers who use HTTP, including methods such as GET, POST, PUT, and DELETE, but its common transport is UDP. Its binary framing and application-level exchange rules are designed around datagrams rather than a persistent TCP byte stream.

A CoAP message includes a message type, code, message ID, token, options, and an optional payload. The message ID helps with acknowledgment and duplicate detection. The token associates a response with a request from the client's perspective. These fields have different jobs, so a test should not assume that matching message IDs alone is sufficient for every response pattern.

Confirmable and Non-confirmable exchanges

A Confirmable message asks the recipient to acknowledge receipt at the CoAP layer. If the sender does not receive the expected result, the CoAP implementation can retransmit according to its configured algorithm. A Non-confirmable message does not request that acknowledgment. It reduces exchange overhead but does not provide the same application-level indication that a datagram reached the recipient.

An acknowledgment can carry the response in a piggybacked exchange, or a server may acknowledge the request and send a separate response later. A Reset indicates that a message was received but could not be processed in the expected context. A useful tunnel test therefore covers more than a basic request. It should verify that acknowledgments and separate responses can return to the initiating client and that retransmission does not create unintended duplicate application work.

Observe is longer-lived than a simple request

CoAP Observe allows a client to register interest in a resource and receive notifications when the resource state changes. This is useful for sensor readings, status values, and device state, but it creates a longer-lived relationship than a single GET request. A successful initial registration proves only that the first exchange worked. It does not establish how the deployment behaves after a long quiet interval, a network transition, a relay interruption, a server restart, or a Localtonet client reconnection.

Test Observe with realistic update intervals. If a sensor normally changes once every several hours, a brief laboratory test that emits a notification every second does not represent the production lifecycle. At the same time, avoid inventing artificial keepalive traffic without understanding the client and server implementations. Idle-session behavior, any UDP association tracking, and recovery rules are deployment-specific and should be measured.

Block-wise transfer does not remove path-size constraints

CoAP block-wise transfer divides a larger payload into smaller exchanges. It can help with firmware fragments, configuration documents, and larger sensor batches without switching to TCP. It does not mean that arbitrary UDP datagram sizes will work across every network.

The effective path may include the remote access network, a carrier, NAT devices, the public relay path, the Localtonet client host, a LAN, and the constrained device itself. Each part can have different MTU and fragmentation behavior. Start with the block size already supported and recommended by the endpoint implementations, then test the complete transfer. Do not assume that a size working on the local LAN will behave identically over a public path.

Prerequisites and local preparation

Prepare the CoAP service before creating public reachability. Tunnel configuration cannot correct an endpoint that is not listening, is bound to the wrong interface, has incompatible credentials, or fails during a local request.

A working CoAP endpoint

Identify the exact local IP address and UDP port used by the server. Plain CoAP conventionally uses UDP port 5683, while CoAP secured with DTLS conventionally uses UDP port 5684. These are protocol defaults, not a requirement that every deployment follow them. Use the port configured by your implementation rather than changing the Localtonet target to a conventional value without checking the server.

Confirm whether the service uses plain CoAP or CoAP over DTLS. A plain CoAP client cannot validate a DTLS deployment, and a DTLS client requires compatible protocol versions, cipher configuration, identity material, and trust settings. Record the URI path, method, expected response code, content format, and any request payload needed for a safe test resource.

A Localtonet client device that can reach the server

Install and run the Localtonet client on the machine that hosts the CoAP service or another device with network access to it. If the target is an embedded board on a private LAN, a gateway computer can run our client as long as that gateway can send UDP traffic to the board and receive the replies.

The selected device is identified by its Localtonet authentication token. Tokens are device-specific secrets. Obtain the token through the current Localtonet product workflow, keep it out of screenshots and logs, and never paste it into source code, issue reports, or public test instructions.

A compatible remote test client

Use a CoAP client that supports the features being tested. At minimum, it should let you choose the destination host and port, method, resource path, and message type. For DTLS, it also needs to support the same authentication mode and DTLS version as the server. For Observe or block-wise testing, confirm that the client actually implements those extensions.

Client command syntax varies between CoAP implementations and versions. This guide does not invent a universal command because no such command applies safely to every client. Substitute the public host and port assigned by Localtonet into your client's documented destination fields, then retain the original CoAP resource path and endpoint security settings.

Information to collect before configuration

• The Localtonet device that will run the tunnel.
• The device-specific authentication token, handled as a secret.
• A relay server or region currently available in the Localtonet dashboard.
• The local IP address reachable from the selected client device.
• The actual UDP port on which the CoAP or CoAPS service listens.
• A read-only or otherwise low-risk resource for initial verification.
• The expected response code, payload, and content format.
• The CoAP message modes, Observe behavior, block sizes, and DTLS settings that need validation.

Available Localtonet relay choices can vary, so obtain the current server or region value from the product rather than copying a hardcoded code from an old guide. The same caution applies to plan-specific availability. Do not assume that every option or region is included in every subscription.

Configure the Localtonet UDP tunnel

The setup sequence follows the standard Localtonet workflow: run our client on a device that can reach the service, identify that device, select a current relay, create the UDP target, start the tunnel, and use the assigned public host and port. The precise dashboard presentation may change over time, but the networking decisions remain the same.

General product documentation and currently available tunnel categories can be reviewed in the Localtonet documentation. Always use the current dashboard for authentication tokens, relay choices, assigned public endpoints, and account-specific availability.

Verify the public CoAP path methodically

Verification should proceed from the simplest known-good exchange to the most stateful behavior. This isolates configuration mistakes and prevents a complex Observe or DTLS failure from being misdiagnosed as a basic tunnel problem.

1. Capture a local baseline

Before using the public endpoint, send a request from a host that already has direct access to the server. Record the destination, method, resource path, message type, response code, token handling, content format, payload, and approximate response time. If DTLS is enabled, also record the intended server identity and authentication mode without recording secret keys.

This baseline establishes that the application works independently of Localtonet. It is particularly important for embedded targets that may sleep, permit only one security association, restrict clients, or require an initial provisioning step.

2. Replace only the network destination

On the remote client, replace the private destination address with the public host and port assigned to the Localtonet UDP tunnel. Keep the resource path, method, payload, CoAP options, message type, and security policy consistent with the local test unless the client requires a deliberate identity adjustment for DTLS.

Avoid changing several variables at once. If the remote request uses a different URI path, different credentials, a different content format, and a different message mode, a failure will not identify which change caused it.

3. Start with a low-risk request

A read-only GET against a health, version, telemetry, or diagnostic resource is usually safer than beginning with PUT, POST, or DELETE. Confirm that the response code and payload match the expected application result. Receiving any UDP response is not enough if it is an authorization error, protocol Reset, malformed payload, or response from an unexpected endpoint.

4. Test both CoAP message styles that the application uses

If production traffic uses Confirmable messages, verify acknowledgment and response behavior. If it uses Non-confirmable messages, test under realistic packet-loss expectations and ensure the application does not assume delivery. Where separate responses are possible, introduce a normal server-side delay and confirm that the delayed response reaches the client and is correlated by token.

5. Check duplicate handling

Confirmable requests may be retransmitted. An application that performs a non-idempotent action must account for duplicate delivery according to its CoAP implementation and application design. The tunnel does not replace duplicate detection. Use a harmless test resource or a request carrying an application-level operation identifier when the server supports that design.

6. Test from a genuinely remote network

A request from the same LAN may not reproduce the route used by a field device. Test from an authorized external network, such as a separate development connection, while respecting organizational policy. Where cellular or constrained access is part of the intended deployment, include that path in the test plan because latency, packet loss, fragmentation, and NAT behavior may differ from a wired desktop connection.

Use logs at both endpoints when possible. The client log should show request creation, retransmission decisions, response correlation, and DTLS errors. The server log should show whether a datagram arrived, whether parsing succeeded, which resource was selected, and why a request was accepted or rejected. If packet capture is permitted in your environment, capture only what is needed and protect the resulting files because plain CoAP captures can contain application data.

DTLS, identity validation, and the tunnel security boundary

A UDP tunnel provides network reachability. It does not automatically turn plain CoAP into CoAP secured by DTLS, and it does not make an unauthenticated resource authorized. For traffic crossing public networks, endpoint security must be designed and tested separately.

DTLS provides security for datagram-based applications. In a CoAP deployment, the DTLS association is negotiated by the CoAP client and server according to the versions, authentication modes, credentials, trust anchors, identities, and cryptographic capabilities they support. Localtonet forwards the UDP service; it does not remove the need for those endpoints to authenticate each other correctly.

Public destination and authenticated identity are different concepts

The public host and port tell the network where to send UDP traffic. The authenticated DTLS identity tells the client which endpoint it trusts. Depending on the CoAP library and credential model, the identity expected by the client may be configured independently from the transport destination. Do not disable identity verification merely because the client now connects through a different public host.

If the endpoint's credentials were provisioned around a private hostname, IP address, or device identity, determine how the chosen DTLS implementation validates that identity when the transport destination changes. The correct answer is implementation-specific. Test it with the actual client and server versions instead of assuming that certificate-style HTTPS behavior, pre-shared-key behavior, or raw-public-key behavior applies universally.

DTLS handshake and retransmission behavior

DTLS must operate over an unreliable datagram transport, so handshake flights and retransmission timers matter. Added latency or packet loss can expose timer assumptions that were invisible on a local LAN. A small constrained device may also limit the number of simultaneous security associations or the memory allocated to handshake state.

Validate initial handshakes, resumed or repeated communication where supported by the implementation, invalid credential rejection, timeout behavior, and recovery after the Localtonet client or CoAP server restarts. Do not report success based only on a packet arriving at the UDP port. Success means the intended authentication completed and protected application data was exchanged.

Authorization remains necessary after authentication

Authentication establishes an identity according to the chosen security model. Authorization decides what that identity may do. Apply least privilege to CoAP resources. A telemetry reader should not automatically receive access to actuator commands, firmware replacement, credential rotation, network reconfiguration, or factory-reset operations.

Where the server supports resource-level controls, grant only the methods and paths needed by the remote client. If those controls are not available, use an application gateway or separate endpoint designed for the limited remote workflow. Treat unauthenticated discovery endpoints and verbose diagnostic resources as potentially sensitive because they can reveal device capabilities and software details.

Observe, NAT behavior, retransmissions, and routine operations

UDP has no TCP-style connection that proves an ongoing session exists. Networking equipment and application components may still maintain temporary association state for request and response routing. The duration and behavior of that state can vary. For that reason, long-lived CoAP workflows need operational testing beyond initial setup.

Test Observe across quiet intervals

Register an Observe request, verify the first representation, and then allow the relationship to remain quiet for an interval representative of the real device. Trigger a resource change and confirm that the notification reaches the same client. Repeat after restarting the remote client, Localtonet client, CoAP server, and relevant network interface one at a time.

Document whether the client automatically re-registers, whether the server removes stale observers, and whether the application requires an explicit recovery action. Localtonet tunnel availability depends on the selected client being connected and the tunnel running, so an interruption can require the application-level Observe relationship to be established again.

Measure retransmissions rather than guessing

CoAP libraries usually manage Confirmable retransmissions internally, but exact timers and limits can be configurable or implementation-dependent. Record the values actually used by your client and server. During a controlled test, introduce representative latency or loss only in an authorized environment and observe whether the exchange completes without creating duplicate side effects.

Excess retransmission can indicate a missing return path, an overloaded endpoint, an incorrect timeout assumption, an application response delay, or packet loss. It is not automatically evidence of a tunnel failure. Compare the remote client log with the server's receipt log to establish whether the original request arrived and whether the response left the server.

Validate message and block sizes

Test the smallest normal request first, then representative payloads, and finally the largest supported operation. For block-wise transfer, verify every block and the completed body. A successful tiny GET cannot establish that a large request body, firmware block, or multi-block response will work.

Message-size limits can exist in the CoAP library, DTLS implementation, embedded network stack, gateway, operating system buffers, or path MTU. Localtonet-specific UDP size limits are not established in the supplied product information, so this guide does not state a numeric limit. Validate the required sizes in the actual deployment and keep block sizes conservative enough for the complete path.

Plan for endpoint and tunnel lifecycle

• Monitor whether the Localtonet client device is connected.
• Confirm that the UDP tunnel is running before scheduling a remote test.
• Expect active reachability to end when the tunnel is stopped or the selected device disconnects.
• Define how clients recover after tunnel, network, server, or device restart.
• Re-establish Observe and DTLS state when the application protocol requires it.
• Stop the tunnel when public reachability is no longer needed.
• Delete obsolete tunnel configurations and rotate any endpoint credentials that may have been exposed.

Use realistic acceptance criteria

A production-oriented acceptance test should include successful and failed authentication, an authorized read, a rejected unauthorized operation, Confirmable request handling, Non-confirmable behavior where used, separate responses, Observe recovery, block-wise transfer, endpoint restart, Localtonet client reconnect, and the expected response to malformed traffic. Run only tests permitted by the owner of the endpoint and network.

Also establish what the application should do when the public endpoint is unavailable. A sensor may queue data, discard stale readings, back off, or switch to another approved path. An actuator client may need to fail closed. Those are application decisions, not behavior that a UDP tunnel can safely choose on the application's behalf.

Troubleshooting common CoAP tunnel failures

Troubleshoot from the inside out. First prove the CoAP service locally, then prove that the Localtonet client can reach it, then verify tunnel state and public addressing, and only after that investigate protocol extensions or security negotiation.

Loopback and LAN binding mistakes

A common mismatch occurs when a server listens on 127.0.0.1 but the Localtonet client runs on another device. Loopback refers to the device itself, not to another host on the LAN. Either run the client on the CoAP server host or configure the server to listen on a suitable LAN interface after applying local firewall and authorization controls.

The reverse mistake is targeting the LAN address from a local configuration when the service actually listens only on loopback. Use the exact address on which the UDP service accepts traffic and verify it from the machine running our client.

Container and virtual-network targets

If the CoAP endpoint runs in a container or virtual machine, the Localtonet client must target an address and port reachable from its own network namespace. A container's internal address may not be reachable from the host, and a host-published UDP port may differ from the container's internal port. Check the actual runtime network configuration. No universal container path or command can be given because it depends on the selected runtime and deployment.

Protocol mismatch

Plain CoAP and CoAP over DTLS are not interchangeable. Sending an unprotected CoAP request to a DTLS listener will not produce a normal CoAP response. Similarly, directing a DTLS client at a plain CoAP endpoint will fail negotiation. Check the server's actual protocol mode and configured UDP port at both the local target and remote client.

Timeout does not identify the failed layer

A timeout can mean that the request never reached the server, the service rejected it silently, the DTLS handshake failed, the response was lost, the server was asleep, the processing time exceeded the client timer, or the client could not correlate the response. Use logs from both sides and change one variable at a time.

Frequently asked questions