Reverse Connect

In a standard OPC UA session, the Client initiates the connection to the Server. Reverse Connect inverts this: the Server initiates an outbound connection to a pre-configured Client endpoint. This is critical for edge gateways or machines sitting behind Network Address Translation (NAT) or strict firewalls that block all inbound traffic. The Server acts as the TCP initiator, establishing a Secure Channel from the inside out, eliminating the need for IT to open inbound ports or configure complex VPN tunnels. Once the raw socket is established, the standard OPC UA session handshake proceeds normally.

For a Reverse Connect Server to know where to connect, the target Client must first register a Reverse Connect Endpoint URL. This URL typically follows the format opc.tcp://[ClientHost]:[Port]. The Server maintains a configured list of these URLs. Upon startup or a connection loss, the Server iterates through its configured endpoints, attempting to establish an outbound TCP socket. Once the raw connection is established, the Secure Channel negotiation and Session creation proceed as defined by the standard OPC UA TCP Binary protocol. This mechanism is defined in Part 6 of the OPC UA specification.

The foundational communication pattern where a Client initiates a session to a Server to browse its Address Space, read data, and call methods. Reverse Connect inverts this topology: the Server acts as the initiator of the socket connection, while the Client waits for incoming connection requests. This inversion is critical for NAT traversal and firewall-friendly architectures without opening inbound ports on the Client side.

A long-lived, encrypted communication path established between an OPC UA application and a host. In Reverse Connect, the Secure Channel is established over a socket initiated by the Server toward the Client's listening endpoint. The channel provides:

• Message signing for integrity
• Encryption for confidentiality
• X.509 certificate exchange for mutual authentication All subsequent Session traffic multiplexes over this pre-established channel.

A logical connection between a Client and Server that manages authentication, continuity, and state across service requests. Even with Reverse Connect, the Session lifecycle remains unchanged:

• The Client activates the Session after the Server-initiated socket connects
• The Server authenticates the Client's user credentials
• The Session maintains subscriptions and continuation points across network interruptions Reverse Connect only changes the transport-layer direction, not the application-layer Session semantics.

A network address and security configuration that describes how a Client can connect to a Server. In Reverse Connect scenarios, the Endpoint concept extends to include a Reverse Connect URL (opc.tcp://ServerHost:4841) that the Client advertises. The Server reads this URL from its configuration and initiates the outbound socket. Key considerations:

• The Client's listening Endpoint must be reachable from the Server's network
• Security Policies (e.g., Basic256Sha256) apply identically regardless of connection direction
• Multiple Servers can connect to a single Client Endpoint, enabling hub-and-spoke aggregation topologies

A centralized registry that maintains a list of available OPC UA Servers and their discovery Endpoints. In a Reverse Connect architecture, the GDS can store the Reverse Connect URL for each Server, enabling Clients to advertise their availability without direct network visibility. The workflow:

• A Client registers its Reverse Connect Endpoint with the GDS
• Servers query the GDS to discover waiting Clients
• Servers initiate connections to the discovered Clients This pattern enables zero-configuration edge-to-cloud connectivity at scale.

An alternative connectivity pattern that uses the lightweight MQTT broker to distribute DataSet messages. While Reverse Connect solves the firewall problem for the Client-Server model, PubSub over MQTT solves it for message-centric architectures:

• The Publisher (edge device) initiates an outbound TCP connection to an MQTT broker
• Subscribers connect to the same broker to receive messages
• No inbound ports are required on either side Choose Reverse Connect when you need Session-based interactions (browsing, method calls). Choose PubSub over MQTT when you need fire-and-forget telemetry streaming.