[Bug 1951832] Re: xl2tpd "Can not find tunnel" in jammy

Robie Basak 1951832 at bugs.launchpad.net
Fri Apr 29 21:21:59 UTC 2022 

I uploaded a rebuild of xl2tpd to fix this in Kinetic, but it is still
pending SRU review for Jammy (22.04).

** Changed in: xl2tpd (Ubuntu)
       Status: Triaged => Fix Committed

** Changed in: lto-disabled-list (Ubuntu Jammy)
       Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to lto-disabled-list in Ubuntu.
https://bugs.launchpad.net/bugs/1951832

Title:
  xl2tpd "Can not find tunnel" in jammy

Status in lto-disabled-list package in Ubuntu:
  Fix Released
Status in xl2tpd package in Ubuntu:
  Fix Committed
Status in lto-disabled-list source package in Jammy:
  Invalid
Status in xl2tpd source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Users cannot connect to L2TP VPNs at all, such as through network-
  manager-l2tp-gnome.

  [Development Fix]

  Addition to lto-disabled-list and a rebuild of xl2tpd in Kinetic. The
  upload to lto-disabled-list is in Unapproved, pending Kinetic opening.
  I've added a task for lto-disabled-list to this bug, so that I'll know
  to upload the rebuild of xl2tpd when that is built and published.
  Since the version of the Jammy upload is 1.3.16-1ubuntu0.1, the
  Kinetic upload will end up "lower" at 1.3.16-1build1, but that
  shouldn't be a problem because this issue will be fixed in both
  packages, and then any subsequent uploads to Kinetic will continue
  "higher" as normal. Alternatively 1.3.16-1ubuntu0.1 could just be
  copied forward to Kinetic after this SRU lands, but it would be better
  to avoid the delta in Kinetic so that the package will autosync in the
  future.

  [Stable Fix]

  Disabling of LTO in debian/rules. This is a more minimal fix that
  would not require coordination between two packages in a situation
  where xl2tpd needs to be rebuilt in Jammy anyway.

  [Fix method not adopted]

  It would be better to fix upstream so that LTO actually works.
  Upstream issues are https://github.com/xelerance/xl2tpd/issues/230 and
  https://github.com/xelerance/xl2tpd/issues/232 and this is tracked in
  bug 1970740. However these aren't fixed upstream and the change in the
  area of code suggested may not be the only necessary fix, so it seems
  safer for both the stable and development releases in Ubuntu to revert
  what regressed the package for now, until a proper fix confirmed to
  cover all cases by upstream.

  [Test Plan]

  Requirements : An L2TP VPN server (Windows Server)

  - Install Ubuntu 22.04
  - Install network-manager-l2tp-gnome (and requirements)
  - Configure a new L2TP VPN connection for your server
    (in my case, not sure if this detail is required)
    - Configure gateway address
    - Configure password auth
    - In the IPsec Options, enable IPsec tunnelling
    - Configure the PSK from your server
    - In the PPP Options, enable MSPPE, and disable MSCHAP (leaving MSCHAPv2 the only auth option)

  With thanks to Adrian Wilkins, who will also do the SRU verification
  for us, since it requires a configured Windows Server at the other
  end.

  In addition, racb will check the build log to ensure that LTO was
  actually disabled during the build.

  [Where problems could occur]

  There might be some other unreported users from whom LTO actually
  fixes something and we will regress them by disabling it. However this
  bug seems more important to fix since it is reported with 35 reported
  to be affected users already.

  LTO doesn't actually get disabled, and by some other non-determinism
  the problem is accidentally fixed and regresses again later.
  Mitigation: check the build log.

  [Original Description]

  My connection works in 20.04 and fails in 22.04.  Perhaps something
  i've been using is now depricated?  Or perhaps jammy xl2tpd is...still
  working on it?

  see my attached syslog extracts at comments #6 thru #11.  the er-x
  extracts were simple, the ubuntu extracts were thus:

  egrep -i "l2tp|swan|ipsec|charon|XFRM|layer 2|\<ike"
  /var/log/syslog|egrep -v "INFORMATIONAL_V1|packet: from"

  what seems to stand out is:

  These lines show up in syslog only in 20.04:
  Nov 22 06:22:04 e540 ipsec[782]: 12[KNL] 3.i.p.4 appeared on ppp0
  Nov 22 06:22:04 e540 ipsec[782]: 14[KNL] 3.i.p.4 disappeared from ppp0
  Nov 22 06:22:04 e540 ipsec[782]: 09[KNL] 3.i.p.4 appeared on ppp0
  Nov 22 06:22:04 e540 ipsec[782]: 05[KNL] interface ppp0 activated

  These lines show up in syslog only in jammy:
  Nov 24 20:11:45 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
  Nov 24 20:11:45 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 105 Dumping.
  Nov 24 20:11:46 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
  Nov 24 20:11:46 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 12 Dumping.
  Nov 24 20:11:46 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
  Nov 24 20:11:46 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 105 Dumping.
  Nov 24 20:11:48 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
  Nov 24 20:11:48 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 12 Dumping.
  Nov 24 20:11:48 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
  Nov 24 20:11:48 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 105 Dumping.
  Nov 24 20:11:52 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
  Nov 24 20:11:52 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 12 Dumping.
  Nov 24 20:11:52 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
  Nov 24 20:11:52 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 105 Dumping.
  Nov 24 20:12:00 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
  Nov 24 20:12:00 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 12 Dumping.
  Nov 24 20:12:00 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
  Nov 24 20:12:00 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 105 Dumping.
  Nov 24 20:12:16 e540 xl2tpd[983]: Maximum retries exceeded for tunnel 39202.  Closing.
  Nov 24 20:12:16 e540 xl2tpd[983]: Connection 0 closed to 2.i.p.7, port 1701 (Timeout)
  Nov 24 20:12:16 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
  Nov 24 20:12:16 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 45 Dumping.
  Nov 24 20:12:17 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
  Nov 24 20:12:17 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 45 Dumping.
  Nov 24 20:12:19 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
  Nov 24 20:12:19 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 45 Dumping.
  Nov 24 20:12:23 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
  Nov 24 20:12:23 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 45 Dumping.
  Nov 24 20:12:31 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
  Nov 24 20:12:31 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet.  call = 39202, tunnel = 45 Dumping.
  Nov 24 20:12:47 e540 xl2tpd[983]: Unable to deliver closing message for tunnel 39202. Destroying anyway.

  my /etc/ipsec.conf:
  config setup

  conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev1
    authby=secret
    ike=aes256-sha1-modp2048!
    esp=aes-sha1!

  conn myvp7
    right=2.i.p.7
    rightprotoport=17/1701
    leftprotoport=17/1701
    left=%defaultroute
    keyexchange=ikev1
    type=transport
    authby=secret
    auto=add

  my /etc/ipsec.secrets:
  : PSK ...

  my /etc/xl2tpd/xl2tpd.conf:
  [lac myvp7]
  lns = 2.i.p.7
  ppp debug = yes
  pppoptfile = /etc/ppp/options.l2tpd.client
  length bit = yes

  my /etc/ppp/options.l2tpd.client:
  ipcp-accept-local
  ipcp-accept-remote
  refuse-eap
  require-chap
  noccp
  noauth
  mtu 1280
  mru 1280
  noipdefault
  defaultroute
  usepeerdns
  connect-delay 5000

  name ...
  password ...

  my startup commands:
  ipsec up myvp7&&
  echo>/var/run/xl2tpd/l2tp-control c myvp7&&
  while i=$(ip route) j=${i#*3.i.p.}
     [[ $j = "$i" ]]
  do echo -n .;sleep .3
  done
  i="ip route add 3.i.p.0/21 via 3.i.p.${j%% *}"
  echo $i;$i

  er-x /etc/ipsec.conf:
  config setup

  conn %default
          keyexchange=ikev1

  conn remote-access
    authby=secret
    type=transport
    keyexchange=ikev1
    left=2.i.p.7

    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    auto=add
    dpddelay=15
    dpdtimeout=45
    dpdaction=clear
    rekey=no
    ikelifetime=3600
    keylife=3600

  er-x /etc/ipsec.secrets:
  2.i.p.7 %any : PSK ...

  er-x /etc/xl2tpd/xl2tpd.conf:
  [global]
  listen-addr = 2.i.p.7

  [lns default]
  ip range = 3.i.p.4-3.i.p.9
  local ip = 10.255.255.0
  refuse pap = yes
  require authentication = yes
  name = VyattaL2TPServer
  ppp debug = yes
  pppoptfile = /etc/ppp/options.xl2tpd
  length bit = yes

  er-x /etc/ppp/options.xl2tpd:
  name xl2tpd
  linkname l2tp
  ipcp-accept-local
  ipcp-accept-remote
  ms-dns 8.8.8.8
  ms-dns 8.8.4.4
  noccp
  auth
  nodefaultroute
  debug
  proxyarp
  connect-delay 5000
  idle 1800

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lto-disabled-list/+bug/1951832/+subscriptions

More information about the foundations-bugs mailing list