Control.com - Nerds in Control

We use OPC server in my company to gather data from devices and control stations in the field. The OPC server sends these data to what is called PI server (from OSIsoft). The PI server interface to OPC server through what is called PI-OPC Interface.

We are planning to install a firewall between the PI and OPC server to protect the control network. How does that affect the data flow between the PI and OPC server? What are the ports/application that we need to block?

Thanks

I'm not really an expert in this field, but I believe you don't block particular ports. Instead you close all the ports, and then open up just the ones you need. You need to ask your OPC software vendor what ports you need for their product. You also need to take into account any other software which may need to use the same network (e.g. for diagnostics and configuration).

I suggest that you talk to someone who does PC networks about your application. A standard firewall isn't the only approach to this problem, and it may not be the best for what you are trying to do.

You should contact OSIsoft to ask their recommendation to expose the OPC data through a firewall. They may have a proprietary solution for this. If they use standard Microsoft DCOM you will find that call backs in asynchronous communications are blocked by your firewall.
For details Microsoft may be of help.

It will be more convenient to configure the firewall to open the http port 80 to connect to a web service.

1) OPC XML
The OPC XML web service can be installed on IIS (internet information server) behind the firewall. OPC XML clients can now get the OPC Data Access information through SOAP/XML.

In case your current OPC DA clients are not OPC XML compliant, ICONICS could help by providing DataWorX32 as a data agregation component to route the DCOM OPC communications over OPC XML.
http://www.iconics.com/products/dataworx32.asp

2) OPC A&E, OPC HDA, OPC DA over XML
The OPC Foundation XML service currently only supports the OPC Data Access spec. In case your OPC Server would also like to expose OPC Historical Data and OPC Alarms&Events you can use GENESIS32 to have Client Components that features DA,A&E,HDA communications over SOAP/XML. These components can be placed in web pages or integrated in 3rd party software.

Regards,
Raymond van der Tas

You're likely going to run into problems using OPC with firewalls, OPC is built on COM or Distributed COM (DCOM) for communications between clients and servers. DCOM requires many ports available to operate making it unfriendly with firewalls or risking your system to attack by enabling too many ports in your firewall.

I haven't tried it yet but right but OPC tunnelling may help you overcome this issue. I last read this article on tunnelling:
http://ethernet.industrial-networking.com/opc/articledi splay.asp?id=43

Alternatively, OPC XML with Web Services is a lot more friendly with firewalls. This might not be feasible with your application if you want to retro-fit a solution using your existing client/servers.

Hope the above helps.

Scott

There are a couple of options you can consider: 1) Depending on how your network is setup (A-Automation network B-Corporate network) then your CIT should be able to control access from OPC server on the A network to your PI server on B network using ACL on the switches. 2) If you are on only 1 network, there should be specific port(s) designation between the PI server and OPC server with the PI-OPC interface for hand shaking. Those ports should be open at a minimum.

Like some have already told you, you will face problems using OPC with firewalls. Like somebody said, a firewall is used to block ports. Since OPC
use DCOM, and DCOM uses lots of dynamically assigned ports it will not work with a firewall.

To get OPC through a firewall you must either use proprietary tunnelling solutions from Iconics or Matricon, using web services through port 80. The
tunneler converts back to DCOM on the other side of the firewall. Otherwise use the standard OPC-XML-DA which may not be supported by OSI yet.

To understand the issues of OPC, firewalls, and security, take a look at chapters 5 and 10 of the book "Software for Automation: Architecture,
Integration, and Security". http://www.isa.org/autosoftware

Jonas Berge
SMAR
===========
jberge@smar.com.sg
www.smar.com
Learn fieldbus and Ethernet at your own pace: www.isa.org/fieldbuses
Learn OPC and automation software at your own pace: www.isa.org/autosoftware

OSI's recommendation is to put the PI-OPC interface and the OPC server on the same side of the firewall. It is much more straightforward to configure and maintain. You could have the PI-OPC interface running in the process control network behind the firewall while having the PI server running on the business side of the firewall. You can refer to our support solution posted on our tech support site to find out which ports are to remain open on the firewall so that the PI-OPC interface can communicate with the PI server: http://techsupport.osisoft.com/supportsolution_detail.aspx?ID=7A928A04 585C47D6A3562B7E8F630FA5

You can also reach us at our general support hotline (510) 297-5828 or email us at techsupport@osisoft.com should you have more questions.

Hello Salem,

Do you still need help on this subject? If yes drop me an email. For your information we recently provided a project to a major O&G Company where we connected PI Server/PI-OPC Interface to 10 DCS using an OPC tunneled solution. It works with no issue.

Regards,
Saber

As long as someone's reviving this thread I'll throw in my $.02.

The more important firewall is on the other side of your OPC server. If you still need a firewall there, from a real world perspective, use something like Kepware's OPC tunneler (as previously recommended). Single port applications are much easier to secure and administer.

If you're really bent on trying to make this deprecated technology work for you it is possible. This MS article describes how to "lock down" DCOMs dynamic port allocation range. You still need to open 135 and if you need to support callbacks all ports must be open from the server to the client (you might be able to force the servers DCOM range in a similar fashon). In any event, this is good to know, but knarly in practice. It doesn't even address the DCOM security pains. USE OPC TUNNELER!

http://msdn2.microsoft.com/en-us/library/ms809327.asp x

----
Nathan Boeger
Inductive Automation
Total SCADA Freedom
http://demo.inductiveautomation.com