Thank you for testing the fix! I've now uploaded the fix for inclusion in an update to 22.04. This is now awaiting SRU team review (I shouldn't do that myself as I prepared it). Once the fix is accepted, we will ask for testing again of the final package binary before it is published to updates.
** Description changed: + [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. 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 ** Changed in: xl2tpd (Ubuntu Jammy) Status: Triaged => In Progress ** Tags removed: bitesize ** Tags added: regression-release ** Description changed: [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. 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. + 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) + (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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1951832 Title: xl2tpd "Can not find tunnel" in jammy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lto-disabled-list/+bug/1951832/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
