• Not Answered

OPC UA OPC Remote Connection Between Two Domains No Trust Ports Required For Communications

Hello,

I am trying to set up OPC remote on a server from a different domain to read/write to our DeltaV OPC server. We have a physical firewall between the two domains, when we open all ports we can communicate, but we are not sure which ports are required. It seems to be a range. However, we want to narrow down how many ports we leave open on the client for security purposes. We are on DeltaV 13.3.1. I set it up according to AP-0500-0023.

Does anyone know which ports should be open, or is it going to be up to the third-party application and how it communicates over OPC?

Thanks,

Michael

6 Replies

  • I would suggest monitoring the network traffic through the firewall and building your rules based on those observations.
    This can typically be done at the firewall level, however, you could also use the wireshark application on the client which would allow you to monitor and filter traffic based on the specific devices.
  • Since you are on v13.3.1 you are using OPC DA which uses a wide range of ports. Port 135 should be open both directions for the initial communications handshake and then all ports 1024 and higher outgoing from the OPC server for continuous update. I think there are some registry hacks that force DCOM to use a certain range of outgoing ports but by default it is random.

    OPC UA is not available until DeltaV v14.LTS and only needs three ports open.
  • OPC DA uses DCOM. Ole for Process Control (OPC) is based on microsoft's Distributed Component Object Modeling (DCOM). A google search, you will find lots of information about OPC and DCOM security. None of this is DeltaV specific. On the OPCti.com web site, I found the following:

    DCOM uses Port 135 to establish communication. Once the OPC Client and Server are able to communicate, they will negotiate new port numbers for communication dynamically. OPC applications typically use 4 ports. Once, the OPC Client and OPC Server applications find the available ports, they use them and release traffic from port 135.

    On Microsoft technet, there are multiple references to campus.barracude.com "how to configure the firewall to allow dcom connections.

    The dcom port issues led to the creation of "tunneling" solutions which use local client on the OPC Server and OPC Client machines to route OPC communciations through this tunnel that uses a defined port in the firewalls. One issue with this is all client connections are to a single connection into the OPC Server so there is no individual user security for the clients. They all have the same DeltaV security. Not really an issue if the connection is always read only such as an enterprise historian.

    Anyway, OPC UA does away with the DCOM underpinnings, and also introduces security certificates and encryption of added data security. Without the underlying microsoft OS features of DCOM, OPC UA can be more readily deployed on non-Windows platforms, including transmitters, analyzers, etc. It is the defacto standard for IIoT, in my opinion.

    Also, Microsoft security patches now disable network features of DCOM by default. Moving to OPC UA is one way to solve your firewall issues. If you do secure your firewall ports for OPC DA, be aware that you need to ensure DCOM remains functional following windows OS patches. Emerson has a KBA that discusses this :NK-2200-0042.

    Andre Dicaire

  • In reply to Andre Dicaire:

    DeltaV Smart Firewall have a special functionality specifically for OPC. It knows about the rendezvous port that will eventually be used after the initial port 135.
  • In reply to Andre Dicaire:

    DeltaV Smart Firewall have a special functionality specifically for OPC. It knows about the rendezvous port that will eventually be used after the initial port 135.
  • If the firewall supports DCE/RPC inspection, this feature when configured as needed then automatically follows the dynamically assigned ports that DCOM uses. There's arguments both ways as to if this is more or less secure than the other solutions (like about any security option).