xl2tpd "Can not find tunnel" in jammy

Bug #1951832 reported by gregrwm
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xl2tpd (Ubuntu)
Undecided
Unassigned

Bug 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

Revision history for this message
Lucas Kanashiro (lucaskanashiro) wrote :

Thanks for taking the time to report this bug and trying to make Ubuntu better.

AFAIU both, your systems running Focal and Jammy, are connection to a VPN that you already have set up, am I right? If yes, could you please share the config you used to set it up? In this way, we could try to reproduce the issue locally. I checked the upstream changelog and I did not notice any deprecated config option or something similar that might be impacting your setup.

I am setting the status of this bug to Incomplete but once you add any information on how to reproduce your full setup please set it back to New and we will take a look again.

Changed in strongswan (Ubuntu):
status: New → Incomplete
Revision history for this message
gregrwm (gregrwm) wrote :

yes. focal on HD, vs a jammy iso, connecting to the same colo ("right"). i'm less familiar with the details at the colo, other than the focal config i have on my end works for it. with some difficulty i could likely get more details about the colo config.

sorry the description above didn't show the following section in my ipsec.conf:
conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev1
    authby=secret
    ike=...
    esp=...
if you want to see any of the "..." let's find a way less public.

the extent of my configuration is ipsec.conf, ipsec.secrets, xl2tpd.conf, options.l2tpd.client, and issuing a couple commands to open the connection. as it's the first stage that fails, i presume only the ipsec.conf, ipsec.secrets, and the command "ipsec up myvp7" are relevant.

Revision history for this message
Simon Déziel (sdeziel) wrote (last edit ):

For some reason, strongswan can't find the PSK to use for the connection as hinted in:

no shared key found for '1.i.p.2'[1.i.p.2] - '2.i.p.7'[2.i.p.7]
no shared key found for 1.i.p.2 - 2.i.p.7

Can you share the strongswan-starter logs? Maybe it will explain what's wrong with the ipsec.secrets.

If you could also share obfuscated ipsec.conf and ipsec.secrets that'd be useful to reproduce the issue.

[Update]: looking at the bug subject you already knew about the missing shared key.

Revision history for this message
gregrwm (gregrwm) wrote :

i've gained access to the "ER-X" which receives my connection at the colo, if you want info from it just ask.

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Thanks for the heads up, gregrwm. As Lucas and Simon said, it would be great if you could provide:

- The configuration files for both sides (client and server), with proper obfuscation in place. ipsec.conf and ipsec.secrets are a good start.

- The log files for both sides, with obfuscation in place where needed.

The first step for us here is to be able to reproduce the bug you're seeing in your environment. If you could provide a step-by-step guide to trigger the problem, that would be ideal. Otherwise, we will need as much information about your setup as you can provide.

Thank you in advance.

gregrwm (gregrwm)
affects: strongswan (Ubuntu) → xl2tpd (Ubuntu)
summary: - no shared key found in 22.04
+ xl2tpd "Can not find tunnel" in jammy
Revision history for this message
gregrwm (gregrwm) wrote :
description: updated
Revision history for this message
gregrwm (gregrwm) wrote :
description: updated
gregrwm (gregrwm)
description: updated
gregrwm (gregrwm)
description: updated
description: updated
Revision history for this message
gregrwm (gregrwm) wrote :
Revision history for this message
gregrwm (gregrwm) wrote :
Revision history for this message
gregrwm (gregrwm) wrote :
Revision history for this message
gregrwm (gregrwm) wrote :
Changed in xl2tpd (Ubuntu):
status: Incomplete → New
gregrwm (gregrwm)
description: updated
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions