All cluster nodes should have a dedicated connection to all other nodes in the cluster. However the cluster can propagate the data as long as all nodes are connected to at least one other node.
The network connection is done via the GRE protocol (IP protocol number 47. For more information, refer to Wikipedia: List of IP protocol numbers. Since GRE is an IP protocol, it is not based on either TCP or UDP and has no concept of ports. It is an IP protocol by itself. That means that it can not simply be made available with a port forwarding behind a NAT (Network Address Translation). A fully transparent VPN solution will be required if the cluster is supposed to be installed over different locations.
If you do have network equipment that is able to encapsulate the protocol, you might still run into the issue of network address complications. This is easiest worked around by setting up the systems in a simpler network configuration (e.g. same site) and later shipment/reconfiguration.
A cluster node will never forward traffic between two other nodes to avoid networking loops. Compared to using the spanning tree protocol (STP), this means that a broken network connection between two nodes will not trigger any downtime of other connections.
If you prefer the dynamic loop prevention behavior, you could add managed switches in front of the Application Interfaces of the Hardware Appliances. Please note that if the network topology change prevents network traffic between the nodes for too long, your cluster nodes might stop operation and require manual interaction. Rapid Spanning Tree Protocol (RSTP) might be an interesting alternative to STP in this case.