Gateway network with firewall restrictions

Hi
I am building my test bench in order to compare the performances between MQTT and OPC-UA.
Here is the configuration:
->My laptop connected to network A
->Edge device (another laptop) connected to network B
->A firewall that deny all the connections from network B to network A and allow connections from network A to network B only on port from 3101 to 3105

I am able to test the MQTT way by changing the port of the broker from the default one to 3101
Now I want to test the OPC-UA way by configuring a remote tag provider from network A to network B. When I go to the gateway network configuration I set up an outgoing connection from network A to network B. On network B I see and approve the certificate (so I guess A is able to reach B). From A I can also see the correct gateway name that I have on B and it’s redundancy role (independent) but the connection is still faulted.
I also try to change the SSL port in order to use one of the open ports but nothing change.
By looking at logs in A I see:
-> outgoing local=’{name_of_the_gateway_on_a}’ remote=‘name_of_the_gateway_on_b’ method=outgoingConnect: Connecting to 'wss://{ip_laptop_network_b}:3102/main/system/ws-control-servlet?name=name_of_the_gateway_on_a&uuid=f096c179-87b5-4fdf-a07d-474913130106&url=https://{ip_laptop_network_a}:8060/main/system
Maybe it’s not the case but is it possible that the handshake phase for this kind of connection is also to establish an outgoing connection from network b to network a on the port 8060 (default port of laptop on network A). If this is the case this kind of connection will never work.
Any ideas on this?

Someone else (maybe @mgross) will have to confirm the Gateway Network stuff, but I can tell you that this test you’re setting up doesn’t actually have anything to do with OPC UA.

maybe my post was not clear. the opc-ua is referred to the way I expose data to the central Ignition server. In the MQTT way is the edge device that collect data from plc and then the ignition main server on the network A is subscribed to it. In the OPC-UA way the edge installation on the field read data from plc then the remote ignition server on network A use a remote tag provider. To have a remote tag provider I have to set up the gateway network first

Yes, that's correct. I just wanted to make it clear the remote tag provider does not use OPC UA.

In this scenario OPC UA is only used for the loopback connection on the Edge device.

yes. I use to set up gw network in other project and it worked perfectly. The only difference now is the firewall in the middle and the Ingnition Edge version on the network B. If there is no differences in the edge installation it has to be something related to the firewall that blocks the ports from network B to network A

Someone else should be able to come along and confirm/deny this in a few hours. I was unable to sleep and now I'm up waaaay too early.

1 Like

If you are trying to make an SSL gateway network connection from A to B, you are going to have to change the metro SSL port on B. To do so, you need to access gateway B’s file system and navigate to the ignition data folder. Open gateway.xml and change the catapult.metroSSLPort property from 8060 to one of your open firewall ports (3101-3105). Then restart gateway B. I would also verify that your firewall allows both http and websocket traffic on your open ports, as the gateway network uses both. If it seems like things partially work, there is a good chance that one or the other can’t get through.

yes. I already changed that port on the gw of network B but it’s still the same

Just to verify the behavior, I set up a Linux virtual machine with a firewall enabled via iptables. I did see the same behavior that you did, where the remote gateway name was retrieved, but the connection never reached the running state. In my case, the firewall was resetting connections for http ssl traffic but allowing websocket ssl traffic. I had to adjust iptables to not reset http ssl connections. So maybe you can try enabling ssl on the general gateway settings on your B gateway, and see if you can reach B’s home page on gateway A. If you can’t see B from A, then that is another troubleshooting step.

I just set up the SSL on Gw B and I can reach the home page from GW A without any issue. Unfortunately the connection is still faulted
What is interesting is that in my case the connection seems to stay in running for few seconds (at least this what I understood from the logs):

04Jan2019 10:56:35 [100] {name_of_the_gateway_on_a} connection status has been updated from Running to Faulted: onClose has been called on web socket:Shutdown
04Jan2019 10:56:32 [100] {name_of_the_gateway_on_a} connection status has been updated from Initialized to Running: Web socket session established for {name_of_the_gateway_on_a}|f096c179-87b5-4fdf-a07d-474913130106
04Jan2019 10:56:32 [100] {name_of_the_gateway_on_a} connection status has been updated from Faulted to Shutdown: shutdown() has been called
04Jan2019 10:56:15 [100] {name_of_the_gateway_on_a} connection status has been updated from Running to Faulted: onClose has been called on web socket:Shutdown
04Jan2019 10:56:12 [100] {name_of_the_gateway_on_a} connection status has been updated from Initialized to Running: Web socket session established for {name_of_the_gateway_on_a}|f096c179-87b5-4fdf-a07d-474913130106
04Jan2019 10:56:12 [100] {name_of_the_gateway_on_a} connection status has been updated from Unknown to Initialized
04Jan2019 10:56:12 [100] {name_of_the_gateway_on_a} connection status has been updated from Faulted to Shutdown: shutdown() has been called
04Jan2019 10:55:55 [100] {name_of_the_gateway_on_a} connection status has been updated from Running to Faulted: onClose has been called on web socket:Shutdown
04Jan2019 10:55:52 [100] {name_of_the_gateway_on_a} connection status has been updated from Initialized to Running: Web socket session established for {name_of_the_gateway_on_a}|f096c179-87b5-4fdf-a07d-474913130106

You've pretty much confirmed that your setup won't work without opening ports from B to A.

For sure it won’t work without opening ports. That’s why I am using the open ports in the range 3101-3105 . the probem is that ports are open only from A to B and not from B to A. So if the gw need to start a connection from B to A, it can’t do it