<div dir="ltr">Hi,<br><br>It seems to be incompatibility¬†between kube-ipvs and ipsec, but is there a chance that we can solve this by a different configuration¬†from ipsec side?<br><a href="https://github.com/cloudnativelabs/kube-router/issues/877">https://github.com/cloudnativelabs/kube-router/issues/877</a><br><br>BR,¬†<br>Ahmed</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 16, 2021 at 10:14 PM Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 16 Sep 2021, Ahmed Sameh wrote:<br>
<br>
> I am OK to switch to tunnel mode, if that will solve my problem, and I appreciate if you can share an<br>
> example config.<br>
<br>
I don't know enough about kubernetes to give you a working config. One<br>
of the main issue is whether the nodes know their "public IP" that does<br>
not live within their own container. Eg you would need to define a<br>
leftsubnet= and rightsubnet= to get the native IPs of the nodes, but<br>
I'm not sure how you could communicate that to generate the config.<br>
<br>
there might be tricks to play, like using <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a> with narrowing=yes<br>
but then there is a security issue of how do you know/trust the remote<br>
node's IP address. What if they pick <a href="http://8.8.8.8/32" rel="noreferrer" target="_blank">8.8.8.8/32</a> ?<br>
<br>
Paul<br>
</blockquote></div>