ipsec: Fix incorrect CIDR in XFRM IN policy for proxy
ipsec: Fix incorrect CIDR in XFRM IN policy for proxy

When IPsec is enabled, we have one XFRM IN policy with mark 0x200 (proxy
redirect) configured to allow proxy traffic through. That is needed
because that traffic is redirected through the INPUT netfilter chains
and the XFRM lookup as part of TPROXY.

In EKS & AKS, the CIDR to match destination IP addresses of those
packets is incorrect. Instead of being the CIDR(s) encompassing all pod
IP addresses, it's the CIDR for the encryption interface.

The IP address from the encryption interface should only be used as the
outer destination IP address of IPsec encapsulation, as shown below (/16
to match packets in dst; 116.92 IP address as tmpl dst).

Before:

    src 0.0.0.0/0 dst 192.168.116.92/19
        dir in priority 0 ptype main
        mark 0x200/0xf00
        tmpl src 0.0.0.0 dst 192.168.116.92
            proto esp reqid 1 mode tunnel
            level use

After:

    src 0.0.0.0/0 dst 192.168.0.0/16
        dir in priority 0 ptype main
        mark 0x200/0xf00
        tmpl src 0.0.0.0 dst 192.168.116.92
            proto esp reqid 1 mode tunnel
            level use

This bug was causing packet drops when using IPsec with L7 policies
(including FQDN policies).

It was introduced by a9f18f36e ("datapath/linux/ipsec: Insert additional
In rule when tunneling") which introduced this XFRM IN policy for proxy
traffic. This new policy was copied from the XFRM IN policy used to
decrypt traffic. But in the XFRM IN policy for decryption it's okay to
use this /19 CIDR because it's before decryption & decapsulation so that
CIDR will match the outer destination IP address (even a /32 would).
That's not the case for the inner packet, after decryption.

Fixes: a9f18f36e ("datapath/linux/ipsec: Insert additional In rule when tunneling")
Signed-off-by: Paul Chaignon <a027184a55211cd23e3f3094f1fdc728df5e0500@cilium.io>

cilium/cilium,cilium/cilium,cilium/cilium,cilium/cilium,cilium/cilium