Publish a web client via a Static IP from my server to the internet

I have an Ignition SCADA installed at a cement plant control room. It has already linked with existing Siemens WinCC DCS stations in plant network. But now, the customer wants to view the Ignition Runtime via internet from virtually anywhere. For that purpose, kindly suggest how can I publish Ignition Runtime to be accessible via Internet through a separate port configuration on the plant firewall, such that the client launcher is available on that static IP & port with specific user credentials for restricted access. I have already published a few clients in existing network.

Basic way…

Open port 8088 on the firewall and point it to the IP address of the ignition server.

In the client launcher use the external ip:8088. Assuming your external ip is fixed.

I’m not sure how you would restrict access to users logging in from outside the network. The only other way would be to VPN into the network and use the internal IP, that way you can restrict who gets in.

1 Like

User credentials is a concern because he wants to give it restrictive access. Will the existing users created in the project work as logins when tried from outside the network?

May be this article can throw some light…

I have developed a module for Ignition which allows monitoring of any selected Ignition parameters remotely on any HTML5 browser using PubNub secure cloud services. You can view parameters in dash boards, or tabular list including event list on a remote device including mobile phones. However its supports its own display screen not an Ignition client screen. Please see demo of modules RM SCADA and mSCADA on Its also possible to configure control like momentary push buttons.

1 Like

Is there any other way besides VPN? Customer might be skeptical about using VPN & would ask for a login similar to what he does on the local Runtime.

My RM SCADA & mSCADA modules use PubNub cloud (www.pubnub,com) , requiring just an internet connectivity on the machine where its installed. VPN is not required. You have to create a (free) account in PubNub though and obtain pub/sub keys.

Though it has a different user interface than Ignition. It does offer login feature but the users have to be configured separately for the remote clients. It also has a virtual tour interface for monitoring and control of the plant ( I am in the process of making download of an eval version of all these modules on github. You can then try it out your self.

1 Like

Banks are using 2 factor OTP authentication for normal accounts. For special accounts they provide biometric authentication. May be we may have to wait a bit longer to get an affordable unbreakable quantum security solution.

Existing users would be able to login from outside the network depending on how you setup your authentication and the users/roles. I don’t believe you can restrict certain users or groups based on location. However, I do believe you may be able to limit what they can do in your projects. I haven’t done this, but I think I would be looking at using the Security Zones. In this, we can define IP addresses, Hostnames, or Gateway names that we “trust.” If we match this zone, the Service Security details would apply. If the conditions do not match, we move along to the next until we find a match, with default being uneditable or removable and will eventually land here.

For your example, I would most likely create a Trust Zone with the IP addresses you want to trust (internal IP ranges) and setup your Service Security for the Trust Zone to be as it is today. I would then edit the default such that it is blank on IP/Hostname/Gateway Names (so it matches everything), turn on Secure Connections, and remove the Scopes you don’t want to give internet access to (I think you want Client only). Then in Service Security for the default zone, set Service Access to Deny for all items you don’t want available externally and set Access Levels for items that you Allow in Service Access. If you want it so they can only Monitor, then ReadOnly on everything would probably be appropriate.

You will probably want to test this as you set it up, but I think it provides some level of security you are needing. Otherwise, you will probably be depending on the projects to implement some sort of checking to limit what they can do (i.e. auto login a user account, and based on IP addresses, restrict their ability to login with elevated permissions - this would give you the ability to restrict project objects as necessary), but would be labor intensive if you must go this route.

Another option would be to stand up another Ignition Gateway intended for Internet facing access and remotely serve tags from the other gateway and create a new project that is designed for this purpose.

Let us know what path you take.

It depends on what security you need.

If you skipped the Main Ignition login page and made your own custom login page. You could write a script to detect the IP address and either send them to your login page or a blocked page. You would have to add another user role so if their IP address is external and their role allows direct them to the log in page. If not then send them to an access restricted page.

The internal ip address should normally be in the same range, if there is multiple ranges you can add them to the script. The external IP would be different.

Maybe your firewall can block traffic across port 8088 based on mac address? I know you can block traffic over a port based on IP address but it will be hard to control that as the external ip address of the device can change all the time depending where the machine is connecting from.

  • Why are two SCADA’s required in the plant (WinCC & Ignition)?
  • How are they interconnected , if they interconnected at all and how?
  • Does your customer want to see data from both SCADAs or only Ignition remotely?
  • Does he want two way communication (i.e. control and monitoring?) or only monitoring?.(knowing how generally the customer’s are, my guess is he would like Ignition or WinCC to work seamlessly everywhere without any change, I don’t care what you do!. Correct me if I am wrong! Then VPN is the best solution).
  • Security is more of a concern for control, monitoring is not so vulnerable in my opinion.
  • PubNub does allow encryption and security.

I like this approach. It’s NOT possible to switch over from a proven existing installation. But they need extra functionalities like internet access, disaster management, ML and so on. This is where Linux based Ignition comes as a fantastic partner for Windows based SCADA systems. You can have best of both the worlds.

1 Like

Is it possible to access Ignition server via PubNub using Ignition native client?.

Ignition client connects to its server on HTTPS protocol where as PubNub on Sockets so it may be difficult to run it over PubNub, but not impossible. We need to have HTTP converter at both ends of PubNub. However I am not sure if PubNub has maximum data size limitation per packet! A web launch client for loading Ignition designer takes huge amount of data from server to client before starting! But I guess run time may be smaller once you have the project and designer data fetched over PubNub. It may be possible to achieve this.

My ARSCADA, mSCADA and RMSCADA clients work over PubNub as well as on LAN , but the ARSCADA’s images have to be stored locally, only run time data comes over PubNub, where as mSCADA’s project data cones as a JSON file(being small). as well as run time data

Do you have a PubSub client on both ends?. Do you PubSub as JSON payload end to end?. Can it work without PubNub as well?.

yes of course its JSON. It works without PubNub on LAN on the same JSON! It uses on LAN.

Very interesting. If you don’t mind, kindly do this test for me. It won’t take more than 20 mins for you.

  1. Read my Kafka post.
  2. Publish your 1000 tags JSON payload to Kafka broker at 500ms per message.
  3. Subscribe to the Kafka broker and take a snapshot of the output on the terminal.
  4. Post the snapshot.


Perhaps I will make the local version available to you so that you can configure the 1000 tags and do the test your self. It will be faster for you as I am busy with the LAN version.

1 Like

Serving Ignition tags and alarms directly as real time JSON payload is indeed a breakthrough in SCADA technology. This opens up a massive opportunity to integrate several clients like Analytics, ML, Android, MQTT, Kafka and so on with Ignition.

If it works as you claim, i can say that you have contributed something very significant for Ignition.

In fact what I send to PubNub dash boards are nothing but JSON paylaods from NJSCADA server. Of course these are small payloads, but we can send even bigger payloads over or HTTP to web clients from NJSCADA.

Let me finish the LAN version of GCM and send the eval to you.

1 Like