Date:   Sat, 15 Dec 2018 19:02:41 +0800
From:   Lemon Lam <almk@...tn.net>
To:     steffen.klassert@...unet.com, herbert@...dor.apana.org.au,
        davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: PROBLEM: xfrm: XFRMINSTATEMODEERROR for transport mode IPsec SA when
 IP VTI is active

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.

[3.] Keywords (i.e., modules, networking, kernel):
      N/A

[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
        Linux version 4.19.5 (root@...one) (gcc version 6.3.0 20170516 
(Debian 6.3.0-18+deb9u1)) #1 SMP Fri Nov 30 21:01:21 CST 2018

[4.2.] Kernel .config file:
        Please see attachment.

[5.] Most recent kernel version which did not have the bug:
      Unknown, problem exist from Debian supplied 4.9.110 to 
self-compiled 4.19.5

[6.] Output of Oops.. message (if applicable) with symbolic information
      resolved (see Documentation/admin-guide/bug-hunting.rst)
      There's no oops.

[7.] A small shell script or example program which triggers the
      problem (if possible)
      I provided a generalized step-by-step, you need to adapt your
      parameters. Please see attachement.

[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
Linux ayaka 4.19.5 #1 SMP Fri Nov 30 21:01:21 CST 2018 x86_64 GNU/Linux

GNU C                   6.3.0
GNU Make                4.1
Binutils                2.28
Util-linux              2.29.2
Mount                   2.29.2
Module-init-tools       23
E2fsprogs               1.43.4
Linux C Library         2.24
Dynamic linker (ldd)    2.24
Linux C++ Library       6.0.22
Procps                  3.3.12
Net-tools               2.10
Kbd                     2.0.3
Console-tools           2.0.3
Sh-utils                8.26
Udev                    232

Rest of "kernel.org format" report seems not relevant so I omitted them.

Thank you for your time reading this email, I look forward to hear from 
you.

Regards,
Lemon Lam
View attachment "kernel_config" of type "text/plain" (104548 bytes)

View attachment "reproduction.txt" of type "text/plain" (1979 bytes)

Powered by blists - more mailing lists