xl2tpd "Can not find tunnel" in jammy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lto-disabled-list (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Invalid
|
Undecided
|
Unassigned | ||
xl2tpd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Users cannot connect to L2TP VPNs at all, such as through network-
[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:/
[Test Plan]
Requirements : An L2TP VPN server (Windows Server)
- Install Ubuntu 22.04
- Install network-
- 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|
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-
esp=aes-sha1!
conn myvp7
right=2.i.p.7
rightprotopor
leftprotoport
left=
keyexchange=ikev1
type=transport
authby=secret
auto=add
my /etc/ipsec.secrets:
: PSK ...
my /etc/xl2tpd/
[lac myvp7]
lns = 2.i.p.7
ppp debug = yes
pppoptfile = /etc/ppp/
length bit = yes
my /etc/ppp/
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/
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
conn remote-access
authby=secret
type=transport
keyexchange=ikev1
left=2.i.p.7
leftprotoport
right=%any
rightprotopor
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/
[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/
length bit = yes
er-x /etc/ppp/
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
affects: | strongswan (Ubuntu) → xl2tpd (Ubuntu) |
summary: |
- no shared key found in 22.04 + xl2tpd "Can not find tunnel" in jammy |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in xl2tpd (Ubuntu Jammy): | |
status: | Fix Committed → Fix Released |
Changed in xl2tpd (Ubuntu Jammy): | |
status: | Fix Released → Fix Committed |
tags: |
added: lto verification-needed verification-needed-jammy removed: verification-done verification-done-jammy |
Changed in xl2tpd (Ubuntu Jammy): | |
status: | Fix Released → Fix Committed |
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.