[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <0f84b334bcd076ae993cdeb6740b304b@rmntn.net>
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