When a TCP socket connection is made (for any socket by any software, not just a DataHub instance), the original connection is made between a (usually) random port on the TCP client side and a published (listening) port on the TCP server side.

In the case of a DataHub tunnel, the tunnelling slave is the TCP client, which makes an outbound connection from a random port. The tunnelling master is the TCP server, which requires an inbound firewall port to be open for its published port number.

When a TCP client connects to a TCP server, it first makes contact through the published port. The server application then allocates a socket associating the client's random port with the server's listening port. More than one socket can be associated with the server's listening port, but the combination of client IP, client port and server port will always be unique. Data on the established socket can flow in either direction if the software is configured to allow it. Any subsequent conversation between a client and the server will again be initiated through the published port.

All modern firewalls understand this mechanism. They maintain "state" information for TCP connections. When a socket conversation is initiated, the client's firewall sees this and updates its tables to allow traffic from the server to the client on the client's randomly selected port, but just for that one socket conversation. When the socket closes, that port is again blocked. While the conversation is open, the firewall will reject any packets to that port that have not originated from the server application. See https://en.wikipedia.org/wiki/Stateful_firewall.

This is the fundamental nature of TCP communication. It is safe. You do not need to open any inbound firewall ports on the DataHub tunnelling slave's firewall. You do need to open one inbound port in your firewall for the DataHub tunnelling master.

If that is too much exposure on the DataHub master computer, you can further isolate it by using a DMZ running a DataHub instance, acting as an isolation layer between the two networks. The DataHub instance on the DMZ becomes the tunnelling master, and each of the connected DataHub instances act as tunnelling slaves. This allows you to communicate between both ends of the tunnel without opening any inbound firewall ports on either end. The only open inbound firewall ports would be on the DMZ itself, where the DataHub tunnelling master is located.

In summary, a simple DataHub tunnel requires:

A DataHub tunnel using a DMZ requires: