netdev - Re: PROBLEM: xfrm: XFRMINSTATEMODEERROR for transport mode IPsec SA when IP VTI is active

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 4 Jan 2019 07:22:02 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Lemon Lam <almk@...tn.net>
CC:     <herbert@...dor.apana.org.au>, <davem@...emloft.net>,
        <netdev@...r.kernel.org>
Subject: Re: PROBLEM: xfrm: XFRMINSTATEMODEERROR for transport mode IPsec SA
 when IP VTI is active

On Sat, Dec 22, 2018 at 06:38:57PM +0800, Lemon Lam wrote:
> Thanks Steffen, but I don't think it is the case.
> 
> I shut down VTI interface toward another VPS and GRE on top of it,
> enabled the plain GRE for transport SA. It works on one end, but not for
> the other end which has to leave VTI with `remote any` up. How can the
> transport SA match this `remote any` VTI?

You did not show your SADB, so I can't tell exactly if this is the
case. On the receive side, we do a VTI tunnel lookup first. If
the received packet matches the tunnel endpoints of a VTI, we
take the key from the VTI and do a SA lookup. The packet must match
a tunnel mode SA and the xfrm mark of that SA must match the key
we got from the VTI. If there is no such SA, the packet is dropped.

In your case, with a `remote any` VTI, only the local VTI tunnel
endpoint must match the src address of the received packet to match
the VTI. If that's the case, you need a tunnel mode SA as described
above.