I'm been looking at the corosync source code to see if I could figure out a way to get it to run behind a NAT (or in my case, within a docker container). I'm only interested in the unicast UDP case. It looks like corosync is sending commit tokens to all discovered nodes, and these commit tokens include the IP addresses of all discovered nodes, including the 'this' node. That is, in a two node case, if node A is a machine with an interface with IP 192.168.0.1, and machine B is on the WAN with IP 7.7.7.7, node A sends a commit token like this: dest: 7.7.7.7 nodeid: 0 ip: 192.168.0.1 node B sees this token, updates it's own commit token with the IP 192.168.0.1 and in turn tries to contact 192.168.0.1, which of course fails because there is no corosync host running on B's network. I'm a little fuzzy on the details because I've only just started to look at this, but it looks like node B forgets about the configured WAN address of A and overwrites it with A's internal IP. Why would a node on a corosync cluster send its own IP address as part of a commit token? Why wouldn't each node implicitly know there was a sender node in addition to the list of nodes that already exists in the received commit token? I'm guessing I'm not the first person to want to run corosync behind a NAT, but a google search hasn't turned up much as to why this isn't supported. I can't think of a technical reason, and it bothers me. Thanks, Chris _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss