Network setup with 1783-NATR

So this is the proposed setup, minus the port forwarding, that may or may not work, but at least you can test it locally i.e. in your office. It does put only one address on the customer's network.


On your test setup, the [Test PLC, 192.168.16.100] will connect to 192.168,16.254, which will be the WAN port of the router in your office;


At the customer's site, the [Customer PLC, 102.2.245.81] will connect to 102.2.245.10, which will be the WAN port of the router at their site.


The [PLC 192.168.216.98] will need to have its gateway set to 192.168.216.1.



The fiddly bit will be the port forwarding, so the [Test/Customer PLC] can initiate a connection to the WAN TCP port 44818 of the router (192.168.16.254 or 102.2.245.81), and the router will pass that connection request to the [Target PLC, 192.168.216.98 TCP port 44818] on the LAN side of the router. To do that you need to [Port-Forward TCP 44818 to 192.168.216.98 TCP 44818] on the router. You may also need to do something with port UDP 2222.

The [LAN PLC] will need to be configured with 19.168.216.1 as its gateway. I don't know if the built-in NAT will handle the pull from the PLC on the LAN.


Everything may need to use the Ethernet driver, instead of the Ethernet/IP driver.



...

Michiel said:

Thanks a lot, I will surely take a look into this.
On the other hand I'll also ask our customer if we can get a second address for our HMI in their network.

Click to expand...

Tell them it will cost another 50% if there is only one address available.

Michiel said:

Exactly what I was afraid of

Click to expand...

One final hail mary for the 1783-NATR: it looks like the customer is interested in communications between the new PLC only on the private side and the customer PLC on the public side; that being the case, is it possible that the NATR will allow translation of the private PLC to the public IP of the NATR itself?



E.g.

• NATR public IP is 102.2.245.10
• Private PLC IP is 192.168.16.98
• Translate private PLC (192.168.16.98) to 102.2.245.10

Which is what the OP was suggesting several posts ago; that way there would be only one public IP used, but I do not know if the NATR would allow it.

drbitboy said:

So this is the proposed setup,
...

Click to expand...

With this, I am pretty sure it needs to use Unicast for the Produce/Consume tages.

Yeah, safe bet that anytime devices aren't on the same subnet, unicast is going to be far easier to get working than multicast.

Can the internal addresses be 169...? Got a project to do just that with 4 169...(non-route-able) addresses. What does the the NATR do with that?