# Gateway network with firewall restrictions **URL:** \ **Category:** Ignition\ **Created:** [January 3, 2019, 10:54am UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662 "2019-01-03T10:54:06Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![lettierf](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lettierf/32/7431_2.png) [@lettierf](https://forum.inductiveautomation.com/u/lettierf)\ **Post date:** [January 3, 2019, 10:54am UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/1 "2019-01-03T10:54:06Z")
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? ---
**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:** [January 3, 2019, 12:43pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/2 "2019-01-03T12:43:40Z")
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. ---
**Author:** ![lettierf](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lettierf/32/7431_2.png) [@lettierf](https://forum.inductiveautomation.com/u/lettierf)\ **Post date:** [January 3, 2019, 12:49pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/3 "2019-01-03T12:49:36Z")
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 ---
**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:** [January 3, 2019, 12:53pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/4 "2019-01-03T12:53:16Z")
> [@lettierf](#): > > 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. ---
**Author:** ![lettierf](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lettierf/32/7431_2.png) [@lettierf](https://forum.inductiveautomation.com/u/lettierf)\ **Post date:** [January 3, 2019, 12:56pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/5 "2019-01-03T12:56:17Z")
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 ---
**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:** [January 3, 2019, 12:57pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/6 "2019-01-03T12:57:43Z")
> [@lettierf](#): > > 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. ---
**Author:** ![mgross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mgross/32/3311_2.png) [@mgross](https://forum.inductiveautomation.com/u/mgross)\ **Post date:** [January 3, 2019, 2:52pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/7 "2019-01-03T14:52:49Z")
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. ---
**Author:** ![lettierf](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lettierf/32/7431_2.png) [@lettierf](https://forum.inductiveautomation.com/u/lettierf)\ **Post date:** [January 3, 2019, 3:36pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/8 "2019-01-03T15:36:49Z")
yes. I already changed that port on the gw of network B but it’s still the same ---
**Author:** ![mgross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mgross/32/3311_2.png) [@mgross](https://forum.inductiveautomation.com/u/mgross)\ **Post date:** [January 3, 2019, 6:06pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/9 "2019-01-03T18:06:48Z")
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. ---
**Author:** ![lettierf](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lettierf/32/7431_2.png) [@lettierf](https://forum.inductiveautomation.com/u/lettierf)\ **Post date:** [January 4, 2019, 9:51am UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/10 "2019-01-04T09:51:30Z")
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 ---
**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:** [January 4, 2019, 11:58am UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/11 "2019-01-04T11:58:37Z")
> [@lettierf](#): > > 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 You've pretty much confirmed that your setup won't work without opening ports from B to A. ---
**Author:** ![lettierf](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lettierf/32/7431_2.png) [@lettierf](https://forum.inductiveautomation.com/u/lettierf)\ **Post date:** [January 4, 2019, 12:19pm UTC](https://forum.inductiveautomation.com/t/gateway-network-with-firewall-restrictions/21662/12 "2019-01-04T12:19:14Z")
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