# Connecting Ignition System over one-way network diode **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [April 15, 2025, 5:39pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128 "2025-04-15T17:39:45Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Kevin\_Ortega](https://avatars.discourse-cdn.com/v4/letter/k/c67d28/32.png) [@Kevin\_Ortega](https://forum.inductiveautomation.com/u/Kevin_Ortega)\ **Post date:** [April 15, 2025, 5:39pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/1 "2025-04-15T17:39:45Z")
Hello, I am working on a project where the end user would like to host two ignition systems on separate subnets, where the systems are connected over a One-Way outbound network diode. The idea would be to maintain a system that has monitoring only capabilities outside of their network hardened Scada network, so ideally, tags and data can move out to the external system, but data does not go back in. Is there an ideal protocol to use to implement a system like this. My thoughts were to use the store and forwarding system, since it uses web sockets, but maybe MQTT may be another option. If anyone has encountered an architecture like this, I am all ears. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 15, 2025, 5:48pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/2 "2025-04-15T17:48:44Z")
The only practical protocol is UDP, with scripted sockets. Anything using TCP (all ordinary protocols) requires bidirectional traffic. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 15, 2025, 6:00pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/3 "2025-04-15T18:00:22Z")
Data diodes involving software like Ignition that uses standard protocols and essentially does not have support for the concept is always going to require a custom solution or extra hardware/software. I've heard of these guys, which can make OPC UA data available over a data diode: [OPC UA Application Connector | Owl Cyber Defense](https://owlcyberdefense.com/resource/opc-ua-application-connector/) You have their hardware + software running on either side. On one side they are an OPC UA Client, subscribed to data in the Ignition OPC UA Server. This data is pushed over the diode one way, to another application of theirs that receives it, and acts as an OPC UA Server, that another Ignition application can connect to as OPC UA Client. The magic sauce they provide is the diode hardware, presumably proprietary protocol for pushing data over the diode, and the software on each side that can produce or consume it. ---
**Author:** ![Kevin\_Ortega](https://avatars.discourse-cdn.com/v4/letter/k/c67d28/32.png) [@Kevin\_Ortega](https://forum.inductiveautomation.com/u/Kevin_Ortega)\ **Post date:** [April 15, 2025, 7:45pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/4 "2025-04-15T19:45:02Z")
That's similar to what I am looking for. Is it possible to connect two Ignition gateways over OPC-UA? How would this work to configure tags to begin populating databases on the external side of the diode? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 15, 2025, 7:47pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/5 "2025-04-15T19:47:02Z")
> [@Kevin\_Ortega](#): > > Is it possible to connect two Ignition gateways over OPC-UA? Of course. Though to be clear: that's not actually what's happening if you use a diode. > [@Kevin\_Ortega](#): > > How would this work to configure tags to begin populating databases on the external side of the diode? It would look just like any other OPC UA connection to any other server. You get nothing for free. Bring in the OPC tags and build something with them. ---
**Author:** ![Kevin\_Ortega](https://avatars.discourse-cdn.com/v4/letter/k/c67d28/32.png) [@Kevin\_Ortega](https://forum.inductiveautomation.com/u/Kevin_Ortega)\ **Post date:** [April 15, 2025, 7:52pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/6 "2025-04-15T19:52:13Z")
> [@Kevin.Herron](#): > > Of course. Though to be clear: that's not actually what's happening if you use a diode. From what you mentioned earlier, the diode would host a client that would transmit the tags and data across the networks to make it accessible. So it would be similar to referencing a standard OPC client? > [@Kevin.Herron](#): > > It would look just like any other OPC UA connection to any other server. You get nothing for free. Bring in the OPC tags and build something with them. Thank you for the help. This gives me confidence in the architecture we are trying to build out. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 15, 2025, 7:53pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/7 "2025-04-15T19:53:34Z")
> [@Kevin\_Ortega](#): > > So it would be similar to referencing a standard OPC client? Not sure what you mean by this. ---
**Author:** ![Kevin\_Ortega](https://avatars.discourse-cdn.com/v4/letter/k/c67d28/32.png) [@Kevin\_Ortega](https://forum.inductiveautomation.com/u/Kevin_Ortega)\ **Post date:** [April 15, 2025, 8:29pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/8 "2025-04-15T20:29:00Z")
From my understanding, the architecture would be ignition opcua server -\> opcua client (data diode) ------ internal transmission ---\> opcua client (data diode) ---\> Igntion opcua server ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 15, 2025, 8:39pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/9 "2025-04-15T20:39:57Z")
No, not quite. ![diode](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/2/528a6929101f3f0e714372d00c1ba17d65bf7c71.png) ---
**Author:** ![Kevin\_Ortega](https://avatars.discourse-cdn.com/v4/letter/k/c67d28/32.png) [@Kevin\_Ortega](https://forum.inductiveautomation.com/u/Kevin_Ortega)\ **Post date:** [April 15, 2025, 10:34pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/10 "2025-04-15T22:34:39Z")
Thanks Kevin ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [April 15, 2025, 11:28pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/11 "2025-04-15T23:28:40Z")
I would think an alternative would also be MQTT as long as the diode can emulate a broker similar to OPC-UA in that data gets published from Ignition to the internal side of the diode which then sends it over to the external side where it also acts like a broker and Ignition on that side subscribes to the topics to get the data. I have a feeling a lot of this depends on protocol support by the diode vendor. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 15, 2025, 11:32pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/12 "2025-04-15T23:32:43Z")
Yeah, that same vendor I linked to has an MQTT adapter as well. I don't think Sparkplug would work, but generic MQTT should? ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [April 15, 2025, 11:41pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/13 "2025-04-15T23:41:19Z")
My worry with Sparkplug is that you really need the birth message to initialize the values, so you'd either have to do a rebirth every so often, or just use generic MQTT and realize that values could not exist until they're witnessed at least once by the external client. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 15, 2025, 11:44pm UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/14 "2025-04-15T23:44:54Z")
I am pretty sure there are elements of Sparkplug that fundamentally require bi-directional communication between Edge nodes and Primary Host, e.g. birth and death payloads published by Primary Host that the Edge nodes need to be able to receive. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [April 16, 2025, 12:06am UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/15 "2025-04-16T00:06:17Z")
I thought using the primary host ID was optional. Even then, the internal/safe side of the diode could just have a static "ONLINE" state published that looks like it's from the primary host causing all transmission modules to send their birth, LWT, and data to the internal "broker" which forwards them to the external broker for it to process/republish to the actual MQTT engine. Here's the page on MQTT. Looks like they do support SparkplugB. [https://owlcyberdefense.com/wp-content/uploads/2020/07/19-OWL-0105-Data-Sheet-Redesign-MQTT-V3.pdf](https://owlcyberdefense.com/wp-content/uploads/2020/07/19-OWL-0105-Data-Sheet-Redesign-MQTT-V3.pdf) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [April 16, 2025, 1:09am UTC](https://forum.inductiveautomation.com/t/connecting-ignition-system-over-one-way-network-diode/105128/16 "2025-04-16T01:09:34Z")
Yeah seems you can opt out of configuring primary host on the edges and opt the primary out of any scenario that would normally require a rebirth (missing or out of order sequences etc).