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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181221083833.GA8742@gauss3.secunet.de>
Date:   Fri, 21 Dec 2018 09:38:33 +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 15, 2018 at 07:02:41PM +0800, Lemon Lam wrote:
> Hello,
> 
> I recently joined DN42 with my virtual private servers, and decided to use
> GRE
> and IPsec to form interconnects between servers.
> I can use GRE over IPsec VTI tunnel fine, but when I simplified some tunnels
> down to GRE over IPsec transport, no incoming traffic is possible.
> Please look into full description below.
> 
> [1.] One line summary of the problem:
>      XFRMINSTATEMODEERROR for transport mode IPsec SA when IP VTI is active
> 
> [2.] Full description of the problem/report:
>      I built tunnels according to StrongSwan's guide on VTI, i.e. using
>      `ip tun add ipsecvti mode vti key <hex key>`, then I add GRE on top of
>      it for MPLS. Everything works great at this stage.
> 
>      I want to strip it down to GRE over IPsec transport between my VPS but
>      have to leave one as-is since there's endpoint with dynamic IP, need
> this
>      as workaround. After necessary configurations, I pinged between
> transport
>      mode tunnel, received no response. `swanctl -l` showed increased
> outgoing
>      traffic counter, but incoming counter stayed at zero. `tcpdump` showed
>      incoming ESP packets on physical interfaces but no corresponding
> packets
>      on GRE tunnel.
> 
>      Hinted to look at `/proc/net/xfrm_stat` by developers from StrongSwan,
>      found out that XFRMINSTATEMODEERROR increases by any traffic on
>      transport tunnel. Later experiments discovered that merely
>      `ip link set ipsecvti down` will let incoming traffic went through.

This looks like you have a transport mode SA that matches
the src and dst endpoint of the vti tunnel. If this is
the case, it is a conceptional problem. VTI behaves like
an IP tunnel, it can not handle transport mode packets.