<div dir="ltr">I'll try to make an example<div>cluster 1 node 1 has private IP1 and VIP1 </div><div>cluster 2 node 2 has private IP2 and VIP2</div><div class="gmail_extra"><br></div><div class="gmail_extra">each node uses it's private ip for outbound connections. </div><div class="gmail_extra">each node can receive inbound connection on its VIP.</div><div class="gmail_extra"><br></div><div class="gmail_extra">so the wireguard config file for node1 is going to look like:</div><div class="gmail_extra"><br></div><div class="gmail_extra">[peer]</div><div class="gmail_extra">endpoint: VIP2:port</div><div class="gmail_extra"><br></div><div class="gmail_extra">and for node 2:</div><div class="gmail_extra">[peer] </div><div class="gmail_extra">endpoint: VIP1: port</div><div class="gmail_extra"><br></div><div class="gmail_extra">the problem is that after the handshake, wireguard updates the config to the following (for example for node2):</div><div class="gmail_extra">[peer]</div><div class="gmail_extra">endpoint: IP1:port</div><div class="gmail_extra"><br></div><div class="gmail_extra">but IP2 cannot route to IP1...</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think a well configured SNAT rule may work, although is not elegant because it forces the cluster to exchange information about their private IPs.</div><div class="gmail_extra">This should not be needed and in the cloud private IPs are ephemeral....</div><div class="gmail_extra"><br></div><div class="gmail_extra">anyway thanks for the advice, I am going to try to use it  in my prototype. </div><div class="gmail_extra"><br></div><div class="gmail_extra">I still think there is need for a better technical approach for a long term solution.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Thanks,<div>Raffaele</div><div><br></div><div>Raffaele Spazzoli</div><div>Senior Architect - <a href="https://www.openshift.com" target="_blank">OpenShift</a>, <a href="https://www.redhat.com/en/services/consulting/paas" target="_blank">Containers and PaaS Practice</a></div><div>Tel: +1 216-258-7717</div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, Sep 16, 2018 at 12:54 PM, Ivan Labáth <span dir="ltr"><<a href="mailto:labawi-wg@matrix-dream.net" target="_blank">labawi-wg@matrix-dream.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Sun, Sep 16, 2018 at 08:21:02AM -0400, Raffaele Spazzoli wrote:<br>
> ... then the IP that a  node uses for its outbound<br>
<span class="">> connection is not the same that its peer need to use for its inbound<br>
> connections.<br>
<br>
</span>Who uses what for whose connection? You lost me here.<br>
Looks like a broken network to me. Does TCP even work?<br>
<br>
Anyway, SNAT/DNAT should be able to fix things up, if you want to go<br>
that route.<br>
<br>
Regards,<br>
Ivan<br>
</blockquote></div><br></div></div>