What Is a DNP3 Virtual Terminal?

Back to Blog

Tunneling a Character Stream Over DNP3

DNP3 virtual terminal objects carry bytes rather than points. Group 112 is the virtual terminal output block, used to send characters toward a device, and group 113 is the virtual terminal event, used to return characters back. Together they open a bidirectional character channel over the DNP3 link, effectively tunneling a serial-console-style session inside the protocol.

The typical use is remote access to a device's text interface without a separate connection - reaching a maintenance console on the outstation, or on a device the outstation fronts, using the DNP3 channel already in place. It is a niche capability compared to reading analog inputs, but it exists precisely because remote sites often have no other back channel. Conceptually it is similar to what a serial-to-ethernet converter does for a console, but carried inside DNP3 instead of over a separate socket.

Why Virtual Terminal Needs Scrutiny

The power to pass arbitrary characters to a device is also a risk. A virtual terminal channel can carry configuration commands, so anything reachable through it is only as protected as the DNP3 link itself. On an unauthenticated link, virtual terminal is a pathway that deserves the same caution as any remote console, and many secure designs disable it unless there is a clear operational need.

This is where virtual terminal intersects with DNP3 security. If the link uses DNP3 Secure Authentication, virtual terminal traffic is authenticated along with everything else, which raises the bar considerably. Deep-packet-inspection controls that do command filtering may also flag or block virtual terminal function codes. The point for an integrator is simple: know whether virtual terminal is enabled on your outstations, and treat it as a remote-access surface, not a harmless data feature.

How a Session Flows on the Wire

A virtual terminal exchange is just writes and events. The master sends a write carrying a group 112 virtual terminal output block to a specific point index; the outstation passes those bytes to whatever that index is mapped to, typically a physical serial port or an internal command interpreter. Characters coming back queue as group 113 virtual terminal events, and they reach the master the same way any events do: collected by a poll, or delivered in an unsolicited response if the outstation is configured to report them spontaneously. The point index is what distinguishes multiple consoles behind one outstation - index by index, each is a separate character channel.

Because the return path rides the event mechanism, a virtual terminal session inherits event behavior: responses can arrive in pieces, interleaved with process events, and buffered characters can sit waiting until the next poll if unsolicited delivery is not enabled for them. That is why an interactive session over VT can feel unlike a direct console - the characters are not a stream, they are batched event objects. It also means VT traffic can compete for the same event resources as process data on some implementations, which is worth knowing before anyone runs a long console session on a busy outstation in the middle of an upset.

Auditing Virtual Terminal on Your Outstations

Because VT is easy to forget about, a periodic audit is worth the hour it takes:

1. Check each outstation's device profile for support of object groups 112 and 113; if the profile does not mention them, verify with the vendor rather than assuming absence.
2. Review the outstation configuration for any point indexes mapped to serial ports or command interpreters.
3. Capture live traffic and filter the application layer for groups 112 and 113 to learn whether anything is actually using the channel today.
4. In a maintenance window and under the site's change control, attempt a benign VT exchange from a test master to confirm whether the feature responds at all.
5. Record the finding per device, and disable the feature wherever there is no documented operational need for it.

The audit matters because VT support can ship enabled by default on devices where nobody has ever used it. A capability no one knows exists is the worst kind of attack surface: it appears in no risk assessment, no firewall rule discussion, and no operator training, yet it is reachable by anyone who can speak DNP3 to the outstation. Finding it yourself, on your own schedule, is considerably better than the alternative.

Alternatives When You Genuinely Need Console Access

If remote console access is a real operational need, weigh VT against the alternatives before defaulting to it. A separate management path - an out-of-band connection or a dedicated, access-controlled channel to the device's maintenance port - keeps console traffic off the SCADA protocol entirely and lets you apply the normal remote-access controls: authentication, authorization, logging, and session recording. The cost is a second path to engineer and maintain, which is exactly what VT was invented to avoid, so genuinely remote sites with a single telemetry link may not have that option in practice.

Where VT remains the only practical back channel, treat it as the remote console it is: enable it only on the outstations that need it, authenticate the link, log its use, and include it explicitly in the security review that covers the site's other remote access paths. The deciding question is not whether VT is dangerous in the abstract - it is whether this specific channel, on this specific link, with these specific controls, is one the site's security policy and its qualified security personnel are prepared to stand behind in writing.

Frequently Asked Questions