OK. So the 10.116.12.0/22 is not known to the Judah hEX yet, but for some reasons, you want the two flowmeters you plan to ultimately place in Judah to have addresses from this range. Can you explain the reasons why it is overall easier to have overlapping subnets and handle it using NAT than just giving Judah a LAN subnet of its own?
If an IP host device (like the flowmeter) is placed in some subnet (like 10.116.12.0/22) and needs to talk to other devices outside that subnet, it must use a gateway device that has an IP address within the same subnet. So indeed, the hEX in Judah must have an address inside 10.116.12.0/22 in order that the flowmeters could use it to talk to the world. However, if the flowmeter is supposed to talk to another host inside its own subnet, it does not use a gateway for that - instead, it broadcasts an ARP request from the interface, saying “whoever has this IP address, please tell me your MAC address” and expects to get a single MAC address in response. There are ways to make the router respond with its own MAC address if the actual destination device is in the same address range but in another physical network, and there are ways to use yet another NAT rule to make the flowmeter see the request from the PC as coming from an address outside its own subnet, but both approaches add complexity to the setup. That’s why I ask whether the ability to use the same subnet that is used in Stebbins also for the flowmeters in Judah is so important that it is worth the burden required to make that possible.
Unfortunately none of these answers my question regarding who is the initiator (client) and who is the responder (server) in the connection that delivers the data from the flowmeter to the Kepware. Kepware supports various data acquisition protocols so the mere fact that it is Kepware gives no clue about this. Since the firewall chooses the NAT treatment for the whole connection when processing its first packet, the information about the roles of the PC and the flowmeter in establishing the connection is critical.
It would be easiest to use an L2 tunneling protocol and indeed extend the 10.116.12.0/22 from one site to the other, but you can afford things like this in a datacenter, not across a bad quality mobile connection, due to all that broadcast traffic that would pass through the tunnel and stress the bad link even more.
But on top of the NAT way, there is also a possibility to let the flowmeters think they are connected to the whole 10.116.12.0/22 but let the routers treat 10.116.12.134/31 as a separate subnet.
Each approach has its pros and cons and each may fit better or worse to your understanding of networking, affecting your ability to eventually troubleshoot it in future, so it is very important to understand whether this is a proof of concept you want to replicate to tens of sites similar to Judah or a one-shot solution for Judah alone.
Just a side note, whilst the flow of the application data (the measured values) is always unidirectional, from the flowmeter to the Kepware, the transport protocols that guarantee delivery use a reverse channel to send the acknowledge messages. So the communication will always be bidirectional.
Yet anothet site that asks me to register just to see a single drawing? No, thanks. Please export it (or make a printscreen if that’s not possible) and attach it as a png here (there’s an Attachments tab just below the editing window here).
