What Is an OPC Tunnel?

Back to Blog

Why DCOM makes remote OPC hard

OPC Classic (OPC DA, HDA, and A&E) is built on Microsoft COM/DCOM. That is fine when the OPC client and server run on the same machine, but connecting them across a network exposes DCOM's problems: it negotiates dynamic port numbers that firewalls block, it depends on matching Windows security and domain settings, and it can hang for minutes when a connection is lost because of long DCOM timeouts.

These issues make direct DCOM connections between plant and remote sites fragile and hard to secure. Opening the wide port ranges DCOM needs is also a security concern. Tunneling exists specifically to eliminate DCOM from the network path.

How a tunnel replaces DCOM

A tunnel uses two components. On the server-side machine, a tunnel agent runs as a local OPC client - it talks to the OPC server over local COM, which needs no network security. On the client-side machine, the partner agent presents itself as a local OPC server to the real client application. Again, that connection is local COM.

The two agents then communicate with each other over a single, defined TCP port using their own efficient protocol, often with TLS encryption. Because only one known port crosses the network, firewall rules are simple. The tunnel also detects a dropped link quickly and re-establishes it, and it reports a clear bad-quality status to the client instead of leaving it hung - a major reliability improvement over raw DCOM.

OPC tunnels in oil and gas SCADA

Many oil and gas facilities still run OPC Classic servers embedded in older DCS and SCADA products. When operators want to pull that data to a central control room, a corporate historian, or a cloud platform, they rarely can - or should - open DCOM across the WAN. A tunnel bridges the plant OPC server to the destination over one encrypted TCP connection.

Tunnels are also used to cross the OT/IT boundary. Placing the two agents on either side of a firewalled DMZ means the only thing traversing the boundary is a single authenticated, encrypted stream, which security teams can inspect and control. This is far more defensible than the sprawling DCOM permissions a direct connection would require.

Where possible, new integrations skip this entirely by using OPC UA, which is designed for secure networked communication and needs no tunnel. But because so much installed equipment is OPC Classic, tunneling remains a common and practical tool on brownfield sites.

What to Evaluate When Selecting a Tunnel

Tunneling products differ more than their one-line descriptions suggest, and the differences surface at the worst moments - during outages and audits. The evaluation questions that separate them:

1. Which OPC Classic interfaces it carries - DA alone, or HDA and A&E as well - since a tunnel that drops alarms and history forces a second integration later.
2. Whether it buffers data during a link outage and replays it afterwards, or simply drops the gap.
3. How TLS certificates are issued, renewed, and monitored over years of unattended operation.
4. What the client application sees during a drop - immediate bad quality, or stale values that look alive.
5. Whether subscriptions resume automatically after either end restarts, with no login and no human touch.
6. What diagnostics the tunnel itself exposes: link state, buffer depth, and the age of the last update.

The failure and restart story deserves the hardest look. A tunnel is infrastructure, and anything that needs a human after a power blip is a liability on an unattended site. It should start with the operating system, reconnect on its own, and make its own health visible to the monitoring layer.

Deployment Patterns That Keep Security Teams Happy

The direction of connection initiation is the detail that matters most at the firewall. A well-planned tunnel has the connection originate from the more-trusted side outward, or from each side out to a relay in a DMZ, so no inbound hole into the control network exists at all. With a DMZ relay, the plant agent connects outward to the relay and the business-side agent does the same from its side, and the OT firewall's inbound rule set stays empty.

That pattern also gives the security team a single inspection and control point. The relay is where the connection can be monitored, terminated in an emergency, and audited, which aligns tunneling with the same zone-and-conduit thinking applied to every other OT boundary crossing. The contrast with DCOM is stark: instead of wide dynamic port ranges opened inbound, there is one outbound TCP connection per agent, on a known port, to a known host, carrying TLS.

Failure Modes and What They Look Like

Tunnels fail in characteristic ways worth knowing in advance. Certificate expiry is the classic silent killer: the link runs untouched for a long stretch, then refuses to reconnect after a restart, and the fix is calendar discipline - track certificate lifetimes like any other maintenance item. Buffered store-and-forward can bite after a long outage, when the backlog replays into the historian and briefly floods it with old timestamps; the historian side has to be configured to accept late data sensibly.

Stale-but-good-looking data is the subtlest failure. If the tunnel's server-side agent loses its local connection to the real OPC server while the tunnel link itself stays up, a badly built chain can keep serving the last values with good quality. Test this failure deliberately during commissioning: stop the source server and confirm the client sees bad quality within the expected time. The monitoring layer should also watch the tunnel's own diagnostics - link state, buffer depth, last-update age - rather than trusting the process values alone.

Tunnel Now or Migrate to OPC UA?

The strategic question is when tunneling stops being the answer. A tunnel preserves the OPC Classic world; it does not modernize it. Where the source system will be replaced soon anyway, or where a native UA server is available for the same data, going straight to UA removes the DCOM problem at the root, with security built into the protocol itself - the trade-offs are laid out in OPC Classic vs OPC UA. Where the source is a frozen legacy system with years of life left, a tunnel is the pragmatic bridge, and many sites run both: UA for new integrations, tunnels for the remainders. Securing the UA side properly is its own discipline, covered in the OPC UA security guide.

Frequently Asked Questions