OPC Devices Wont connect when new NIC connection added

I am running v8.06 on a server with two NIC’s. Until recently we were only using one NIC. We added the 2nd NIC card in, on a completely separate network from NIC #1. Now if we loose connection to a PLC it will not reconnect. All we have to do is disconnect the 2nd NIC and the device reconnects and stays connected. I have tried changing the OPC UA binding settings to the IP of NIC#1 (Pic below) but there is no change. Thank you in advance for your help.
OPC US Settings

Changing the bind address for the OPC UA server is irrelevant here.

Do these two networks have overlapping IP addresses or similar subnet or something? It sounds like what’s happening is that the new NIC has higher priority but is also indicating that it’s able to handle the target host when Java delegates to the OS to open a socket.

As a quick test/workaround you can try changing the network priority order of the 2 interfaces.

The networks are different
NIC 1 Static 192.168.200.X
NIC 2 DHCP 192.168.0.X

I tried changing the priority, with no change. NIC 2 is connected to a router with port forwarding selected to point to the Gateway.

I did change all of the bindings back to their default settings on the OPC UA server.

Can you run Wireshark while a device is stuck trying to reconnect so we can see which NIC the connection attempts are originating from?

Definitely going out the wrong port. is NIC 2, all the other IP addresses are my PLC’s going thru a router on NIC 1.

Are you on Windows? Did you set the interface you want prioritized to have a smaller metric value?

This article sort of talks about what’s going on: https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc137807(v=msdn.10)?redirectedfrom=MSDN

Basically… it’s out of our hands. When the socket is connected without an explicit local address the routing table is consulted to figure out which local interface to use, and something about your setup is resulting in the wrong interface being used because the routing table is indicating that it can be used to route to the destination IP.

It’s a reasonable request that all of our drivers gain a configuration setting that allows explicit configuration of the local bind address but that’s not going to happen immediately.

Windows Server 2016, and yes, NIC 1 is set at 1 and NIC 2 is set at 10.

Looks like we will need to find another route then. Thanks for the help.

You might be able to get the routing table corrected or add explicit routes or something. I don’t really know enough about Windows, but you can get a look at the routing table by running route print -4 and at least verify that the routes look wrong…

That’s where we are at now. We see the settings for the metrics have the priority for NIC 1, but there is no change on how the system works. We will keep trying. Thanks

Yes. Forcing the routing table with explicit routes worked for one site where I had this particular problem.

Because I have no router in the PLC network I used the server NIC as “gateway” ( In the last line you can see in the image below, you can check the command used:

Persisten route

1 Like

thank you foliveria