<div dir="auto"><div>I am OK to switch to tunnel mode, if that will solve my problem, and I appreciate if you can share an example config.<div dir="auto"><br></div><div dir="auto">BR,</div><div dir="auto">Ahmed</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 15, 2021, 8:57 PM Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 9 Sep 2021, Ahmed Sameh wrote:<br>
<br>
> I am trying to enable IPsec for Kubernetes nodes, that uses IPVS for in-cluster load balancing, more details are here<br>
> <a href="https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/" rel="noreferrer noreferrer" target="_blank">https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/</a><br>
>  <br>
> In short, in the example below access to cluster IP 10.240.0.1 port 443 is redirected to one of Kubernetes master nodes<br>
> port 6443<br>
<br>
If you are NAT'ing then Opportunistic becomes very complicated. And you<br>
cannot really use Transport Mode anymore. I also do not fully understand<br>
how you want to do this. An OE node connecting to IP a.b.c.d expects an<br>
ipsec connection from its own IP to a.b.c.d. If that is NAT'ed to a<br>
different node, that node needs to be aware of the pre-NAT IP because<br>
it needs to use that as ipsec policy, and then it needs to be able to<br>
send/receive on that other IP address as well.<br>
<br>
Paul<br>
<br>
<br>
> [root@host ~]# ipvsadm -ln<br>
> Prot LocalAddress:Port Scheduler Flags<br>
>   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn<br>
> TCP  <a href="http://10.240.0.1:443" rel="noreferrer noreferrer" target="_blank">10.240.0.1:443</a> rr<br>
>   -> <a href="http://10.140.24.135:6443" rel="noreferrer noreferrer" target="_blank">10.140.24.135:6443</a>           Masq    1      0          0          <br>
>   -> <a href="http://10.140.24.204:6443" rel="noreferrer noreferrer" target="_blank">10.140.24.204:6443</a>           Masq    1      0          0          <br>
>   -> <a href="http://10.140.24.64:6443" rel="noreferrer noreferrer" target="_blank">10.140.24.64:6443</a>            Masq    1      1          0      <br>
> <br>
> BR,<br>
> Ahmed<br>
> On Thu, Sep 9, 2021 at 4:58 PM Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank" rel="noreferrer">paul@nohats.ca</a>> wrote:<br>
>       On Thu, 9 Sep 2021, Ahmed Sameh wrote:<br>
><br>
>       > Can anyone share an example of NAT-Traversal with IPsec transport mode ?<br>
><br>
>       Your quality of life with improve a lot if you avoid ever using<br>
>       Transport Mode with NAT. Everyone has moved away from it. Only use<br>
>       transport mode if you are not affected by NAT.<br>
><br>
>       > I have the following configuration working for normal traffic but not the NATed one.<br>
>       ><br>
>       > conn private-or-clear<br>
>       > auto=ondemand<br>
>       > type=transport<br>
>       > authby=rsasig<br>
>       > failureshunt=passthrough<br>
>       > negotiationshunt=passthrough<br>
>       > ikev2=insist<br>
>       > left=%defaultroute<br>
>       > leftcert={{ cert_name_pattern }}<br>
>       > leftid=%fromcert<br>
>       > leftrsasigkey=%cert<br>
>       > rightrsasigkey=%cert<br>
>       > rightid=%fromcert<br>
>       > right=%opportunisticgroup<br>
><br>
>       Opportunistic Encryption does not support transport mode plus NAT.<br>
><br>
>       It only supports NAT for the initiator, not for the responder.<br>
><br>
>       It might be worth explaining what you are trying to do so we can discuss<br>
>       different solutions to your problem.<br>
><br>
>       Paul<br>
> <br>
> <br>
><br>
</blockquote></div></div></div>