Hi Krzysztof, Definitely, AddressResolver can be used for the purposes when you need to connect nodes that are behind NAT with the other ones.
Basically, in an AddressResolver configuration each node should simply list a mapping of *its* private addresses to *its* external addresses. After that when a node joins a cluster it sends its mapped addresses to the rest of the cluster so that every other node can connect to it through TcpCommunicationSpi. In my understanding there is a miss-configuration at the level of AddressResolver, TcpCommunicationSpi or TcpDiscoverySpi. Please double check that: 1. Every cluster node provides private->public addresses mapping of its own IPs in the AddressResolver. 2. TcpDiscoverySpi of every node contains only public addresses. 3. All the ports that are used by both TcpDiscoverySpi and TcpCommunicationSpi are opened. If nothing helps please share a full configuration you use. -- Denis On Tue, Oct 11, 2016 at 4:27 PM, Krzysztof <yaz...@gmail.com> wrote: > Hello, > > We would appreciate confirmation that > GridDhtAssignmentFetchFuture::requestFromNextNode() makes impossible to > have > a client communicating via NAT, even with AddressResolver - or a pointer > where we make a mistake in the code/logic. > Judging by the code, GridDhtAssignmentFetchFuture has no notion of > AddressResolver at all and will always try to contact returned nodes from > behind the NAT.. > > Is there any way to make it work? WE must make a decision if to use Ignite > in our project and this seems to be a blocker.. > > Best Regards > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/Ignite-Cluster-Communication-with- > SSH-Tunnels-tp273p8225.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
