How to Expose an OPC UA Server to Remote Clients Securely

What Is OPC UA and Why Does Remote Access Matter?

OPC UA (OPC Unified Architecture, standardised as IEC 62541) is a machine-to-machine communication protocol for industrial automation. Unlike older protocols such as Modbus, which only transfer raw register values, OPC UA carries a rich, self-describing information model. A client that connects to an OPC UA server can browse its address space to discover what data is available variable names, engineering units, data types, hierarchical relationships, and method definitions without any prior knowledge of the system.

This makes OPC UA the foundation of Industrial IoT data collection. ERP systems, MES platforms, data historians, cloud analytics pipelines, and digital twin frameworks all consume OPC UA data. The problem is that production OPC UA servers live inside tightly controlled OT network segments that have no direct path to the internet or the corporate IT network. Making that data available to systems and engineers outside the plant requires a controlled, secure bridge across that network boundary.

The Network Access Challenge

OPC UA uses the opc.tcp:// URI scheme and communicates over TCP, default port 4840. The protocol includes a Local Discovery Server (LDS) that clients query on port 4840 to enumerate all OPC UA servers running on a host. Each server endpoint is identified by a URL that includes the server's hostname or IP address.

This endpoint URL creates a specific challenge for tunnel-based remote access. When a client connects through a tunnel to a relay address, the OPC UA server returns endpoint descriptions that contain its local IP address not the relay address. The client then tries to use that local IP to establish the actual session, which fails because the local IP is unreachable from outside the plant.

There are three practical approaches to solve this, each appropriate for different situations.

Approach A: Direct TCP Tunnel with Endpoint URL Override

For development, testing, and vendor commissioning support scenarios, a direct TCP tunnel to port 4840 works well. The endpoint URL mismatch is handled by configuring the OPC UA client to use a fixed endpoint URL rather than relying on the discovery process. Most professional OPC UA clients; UaExpert, Prosys OPC UA Browser, and SDK-based clients support bypassing discovery and connecting directly to a specified endpoint URL.

curl -fsSL https://localtonet.com/install.sh | sh
localtonet --authtoken <YOUR_TOKEN>

# Endpoint URL format for direct connection via tunnel
opc.tcp://example.localto.net:34840

Approach B: Node-RED OPC UA to HTTP/REST Bridge

The cleanest production pattern for external OPC UA access is a Node-RED bridge running inside the plant network. Node-RED connects to the OPC UA server on the local OT network using the node-red-contrib-opcua palette, reads or subscribes to specific nodes, and exposes the data through a standard HTTP REST endpoint. A Localtonet HTTP tunnel then makes that REST endpoint accessible from outside. External clients never speak OPC UA directly they call a simple REST API.

This pattern solves the endpoint URL problem entirely because Node-RED connects to OPC UA over the internal network and external clients only see HTTP. It also gives you full control over which data nodes are exposed and how they are formatted.

sudo npm install -g --unsafe-perm node-red
cd ~/.node-red
npm install node-red-contrib-opcua
node-red

In the Node-RED editor, build a flow with these nodes:

// Format OPC UA read result as a clean REST response
msg.payload = {
    nodeId: msg.payload.nodeId || "ns=2;s=Temperature",
    value: msg.payload.value !== undefined ? msg.payload.value : msg.payload,
    timestamp: new Date().toISOString(),
    quality: "Good"
};
return msg;

Deploy the flow and test it locally:

curl http://localhost:1880/opcua/data

If it returns a JSON response with a value, the OPC UA to REST bridge is working. Now create a Localtonet HTTP tunnel for port 1880:

# Create tunnel for Node-RED (HTTP tunnel, port 1880)
# Use the Localtonet dashboard: http tunnel -> 127.0.0.1:1880

External clients now call the REST endpoint through the tunnel:

curl https://abc123.localto.net/opcua/data

Approach C: OPC UA to MQTT Gateway for Continuous Data Streaming

For scenarios where external systems need continuous real-time updates rather than on-demand reads, a Node-RED flow can subscribe to OPC UA node changes and forward them to a Mosquitto MQTT broker. The MQTT broker is then exposed through a Localtonet TCP tunnel. This is the pattern used in Industrial IoT data pipelines feeding cloud platforms, historians, and analytics engines.

This approach extends the monitoring stack described in the factory machine monitoring guide. The difference is the data source: instead of Modbus TCP, OPC UA subscriptions drive the data feed.

// Transform OPC UA subscription update to MQTT-ready JSON
var update = msg.payload;

msg.payload = JSON.stringify({
    nodeId: msg.topic,
    value: update.value !== undefined ? update.value : update,
    timestamp: new Date().toISOString(),
    source: "opcua"
});

// MQTT topic structure: plant/line/machine/variable
msg.topic = "plant/line1/cnc_01/spindle_speed";

return msg;

Connecting a Python OPC UA Client via Tunnel

For developers building integrations or writing data collection scripts, the asyncua Python library provides a clean interface to OPC UA. When connecting through a Localtonet TCP tunnel, specify the relay address as the endpoint and configure the client to use the tunnel URL rather than the server's local IP.

pip install asyncua

import asyncio
from asyncua import Client

# Replace with your actual Localtonet relay address
RELAY_URL = "opc.tcp://example.localto.net:34840"

async def read_opcua_data():
    async with Client(url=RELAY_URL) as client:
        print(f"Connected to OPC UA server via tunnel")
        print(f"Server product name: {await client.get_namespace_array()}")

        # Browse the root objects folder to discover available nodes
        root = client.get_root_node()
        objects = await root.get_children()
        print("Root node children:")
        for obj in objects:
            name = await obj.read_browse_name()
            print(f"  {name}")

        # Read a specific node by NodeId
        # Adjust ns and identifier to match your server's address space
        node = client.get_node("ns=2;s=Temperature")
        value = await node.read_value()
        print(f"Temperature: {value}")

        # Read multiple nodes at once
        nodes = [
            client.get_node("ns=2;s=Temperature"),
            client.get_node("ns=2;s=Pressure"),
            client.get_node("ns=2;s=MotorSpeed"),
        ]
        values = await client.read_values(nodes)
        print(f"Temperature: {values[0]}, Pressure: {values[1]}, Speed: {values[2]}")

asyncio.run(read_opcua_data())

For subscription-based continuous monitoring through the tunnel:

import asyncio
from asyncua import Client
from asyncua.common.subscription import SubHandler

RELAY_URL = "opc.tcp://example.localto.net:34840"

class DataChangeHandler(SubHandler):
    def datachange_notification(self, node, val, data):
        print(f"Node {node}: value changed to {val}")

async def subscribe_opcua():
    async with Client(url=RELAY_URL) as client:
        handler = DataChangeHandler()
        subscription = await client.create_subscription(500, handler)

        # Subscribe to specific nodes
        nodes = [
            client.get_node("ns=2;s=Temperature"),
            client.get_node("ns=2;s=Pressure"),
        ]
        await subscription.subscribe_data_change(nodes)

        print("Subscribed. Waiting for data changes...")
        await asyncio.sleep(60)  # Collect data for 60 seconds

asyncio.run(subscribe_opcua())

Security Considerations for Remote OPC UA Access

Frequently Asked Questions