Bug 1894381

Summary: Libreswan 4.1-2 breaks l2tp connection to Windows VPN server
Product: [Fedora] Fedora Reporter: Mikkel Lauritsen <renard>
Component: libreswanAssignee: Paul Wouters <pwouters>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: doug, ivo, jan.public, komusubi, nicolas, pwouters, sahana, wijngaarde
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: libreswan-4.1-3.fc34 libreswan-4.1-3.eln105 libreswan-4.1-3.fc33 libreswan-4.1-3.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-23 17:11:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mikkel Lauritsen 2020-11-04 07:43:54 UTC
After upgrading Libreswan from 3.32-2.fc33 to 4.1-2.fc33 I can no longer connect to a Windows VPN server using l2tp. Downgrading Libreswan to 3.32-2 makes the VPN connection work again.

With 4.1-2 the log says

Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Using l2tp kernel support.
Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: xl2tpd version xl2tpd-1.3.15 started on localhost.localdomain PID:7157
Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Forked by Scott Balmos and David Stipp, (C) 2001
Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Inherited by Jeff McAdams, (C) 2002
Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Listening on IP address 0.0.0.0, port 1701
Nov 04 08:15:03 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Connecting to host ###, port 1701
Nov 04 08:15:17 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: death_handler: Fatal signal 15 received
Nov 04 08:15:17 localhost.localdomain NetworkManager[7157]: xl2tpd[7157]: Connection 0 closed to ###, port 1701 (Server closing)

(IP address of server replaced by ###)

whereas the 3.32 log says

Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Using l2tp kernel support.
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: xl2tpd version xl2tpd-1.3.15 started on localhost.localdomain PID:3211
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Forked by Scott Balmos and David Stipp, (C) 2001
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Inherited by Jeff McAdams, (C) 2002
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Listening on IP address 0.0.0.0, port 1701
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Connecting to host ###, port 1701
Nov 04 08:31:22 localhost.localdomain kernel: l2tp_ppp: PPPoL2TP kernel driver, V2.0
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Connection established to ###, 1701.  Local: 9008, Remote: 426 (ref=0/0).
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Calling on tunnel 9008
Nov 04 08:31:22 localhost.localdomain NetworkManager[3211]: xl2tpd[3211]: Call established with ###, Local: 40885, Remote: 4, Serial: 1 (ref=0/0)

Comment 1 Paul Wouters 2020-11-05 16:12:16 UTC
You are only showing xl2tpd logs, but not actually libreswan/pluto logs.

I suspect you are using DH2, which got disabled because it is simply too weak.

Comment 2 Nicolas Dufresne 2020-11-06 18:20:18 UTC
Hi there, we are experimenting the same issue against Ubiquity USG L2TP/IPSEC VPN. It's using PSK (which I guess means DH2) indeed. I don't know myself how to retrieve more logs then what is originally posted. But we could see on the server that it ends with:

Nov  6 13:11:46 07[MGR] ignoring request with ID 2077820847, already processing

Comment 4 Mikkel Lauritsen 2020-11-10 15:49:24 UTC
Sorry; I wasn't aware that there would be additional logging output besides that shown by journalctl.

/var/log/pluto.log contains information about the first connection attempt, again with IP addresses replaced with ###:

Nov  4 08:15:03.412874: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #1: initiating IKEv1 Main Mode connection
Nov  4 08:15:03.412970: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #1: sent Main Mode request
Nov  4 08:15:03.429836: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #1: sent Main Mode I2
Nov  4 08:15:03.465687: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #1: sent Main Mode I3
Nov  4 08:15:03.475599: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #1: Peer ID is ID_IPV4_ADDR: '192.168.10.241'
Nov  4 08:15:03.475682: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #1: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA1 group=DH20}
Nov  4 08:15:03.475706: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: initiating Quick Mode PSK+ENCRYPT+UP+IKEV1_ALLOW+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:86b559ad proposal=AES_CBC_256-HMAC_SHA1_96, AES_CBC_128-HMAC_SHA1_96, 3DES_CBC-HMAC_SHA1_96 pfsgroup=no-pfs}
Nov  4 08:15:03.475861: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: sent Quick Mode request
Nov  4 08:15:03.487379: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: ignoring informational payload IPSEC_RESPONDER_LIFETIME, msgid=86b559ad, length=28
Nov  4 08:15:03.487403: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: NAT-Traversal: received 2 NAT-OA. Using first; ignoring others
Nov  4 08:15:03.487411: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: our client subnet returned doesn't match my proposal - us: 192.168.86.32/32 vs them: ###/32
Nov  4 08:15:03.487448: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: sending encrypted notification INVALID_ID_INFORMATION to ###:4500
Nov  4 08:15:03.487491: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: deleting state (STATE_QUICK_I1) aged 0.011796s and NOT sending notification
Nov  4 08:15:03.487534: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #2: ERROR: netlink response for Del SA esp.837e1dad@### included errno 3: No such process
Nov  4 08:15:17.684171: "4d6ecea7-7a76-4142-9aff-f53acf51405a": terminating SAs using this connection
Nov  4 08:15:17.684212: "4d6ecea7-7a76-4142-9aff-f53acf51405a" #1: deleting state (STATE_MAIN_I4) aged 14.27135s and sending notification
Nov  4 08:17:05.651286: shutting down

Comment 6 Douglas Kosovic 2020-11-23 02:16:30 UTC
Regarding the "our client subnet returned doesn't match my proposal - us: 192.168.86.32/32 vs them: 80.123.45.67/32" error, I believe it is related to the following libreswan commit which removed -DALLOW_MICROSOFT_BAD_PROPOSAL with libreswan >= 4.0 :

https://github.com/libreswan/libreswan/commit/134f76cd68b7f3d442e95ca65f67cad0e500c0ba#diff-6301a2703b709daa4d84ead1c30bf67cdaf088abed68753a8f9c740f1e58b54a

Comment 7 Fedora Update System 2020-11-23 17:11:22 UTC
FEDORA-2020-86d9477d65 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 8 Paul Wouters 2020-11-23 17:14:39 UTC
*** Bug 1897440 has been marked as a duplicate of this bug. ***

Comment 9 Fedora Update System 2020-11-23 17:20:26 UTC
FEDORA-2020-ea46d55ecf has been pushed to the Fedora ELN stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2020-11-23 17:21:55 UTC
FEDORA-2020-60d3e6450d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-60d3e6450d

Comment 11 Fedora Update System 2020-11-23 17:22:10 UTC
FEDORA-2020-19d974f925 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-19d974f925

Comment 12 Fedora Update System 2020-11-24 01:26:28 UTC
FEDORA-2020-60d3e6450d has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-60d3e6450d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-60d3e6450d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2020-11-24 02:20:44 UTC
FEDORA-2020-19d974f925 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-19d974f925`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-19d974f925

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Ivo Sarak 2020-11-24 07:38:56 UTC
Tried that errata on Fedora 33:

[ivo@l2ppar ~]$ sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-60d3e6450d
Fedora 33 - x86_64 - Test Updates                16 kB/s |  15 kB     00:00    
Fedora 33 - x86_64 - Test Updates                                                                                                        1.1 MB/s | 3.9 MB     00:03    
skype (unstable)                                                                                                                          14 kB/s | 2.9 kB     00:00    
No security updates needed, but 106 updates available
Dependencies resolved.
Nothing to do.
Complete!
[ivo@l2ppar ~]$ 

What?

Comment 15 Douglas Kosovic 2020-11-24 11:09:45 UTC
The dnf upgrade won't work if libreswan isn't already installed, if it isn't installed, issue the following to install the libreswan package from updates-testing :

sudo dnf install --enablerepo=updates-testing libreswan

Comment 16 Ivo Sarak 2020-11-24 12:15:11 UTC
[root@l2ppar ~]# rpm -q libreswan
libreswan-4.1-2.fc33.x86_64
[root@l2ppar ~]# dnf install --enablerepo=updates-testing libreswan
Last metadata expiration check: 2:23:02 ago on T 24 nov   2020 11:50:18.
Package libreswan-4.1-2.fc33.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[root@l2ppar ~]# dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-60d3e6450d
Last metadata expiration check: 2:23:46 ago on T 24 nov   2020 11:50:18.
No security updates needed, but 107 updates available
Dependencies resolved.
Nothing to do.
Complete!
[root@l2ppar ~]# 

Obviously that update is broken...

Comment 17 Ivo Sarak 2020-11-24 17:41:36 UTC
Now I do get it:

[root@l2ppar ivo]# dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-60d3e6450d
Fedora 33 - x86_64 - Test Updates               8.7 kB/s |  12 kB     00:01    
Fedora 33 - x86_64 - Test Updates               580 kB/s | 2.3 MB     00:04    
Last metadata expiration check: 0:00:05 ago on T 24 nov   2020 19:39:49.
Dependencies resolved.
================================================================================
 Package          Architecture  Version            Repository              Size
================================================================================
Upgrading:
 libreswan        x86_64        4.1-3.fc33         updates-testing        1.1 M

Transaction Summary
================================================================================
Upgrade  1 Package

Total download size: 1.1 M
Is this ok [y/N]: y
Downloading Packages:
libreswan-4.1-3.fc33.x86_64.rpm                                                 1.4 MB/s | 1.1 MB     00:00    
----------------------------------------------------------------------------------------------------------------
Total                                                                           623 kB/s | 1.1 MB     00:01     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                        1/1 
  Running scriptlet: libreswan-4.1-3.fc33.x86_64                                                            1/1 
  Upgrading        : libreswan-4.1-3.fc33.x86_64                                                            1/2 
  Running scriptlet: libreswan-4.1-3.fc33.x86_64                                                            1/2 
  Running scriptlet: libreswan-4.1-2.fc33.x86_64                                                            2/2 
  Cleanup          : libreswan-4.1-2.fc33.x86_64                                                            2/2 
  Running scriptlet: libreswan-4.1-2.fc33.x86_64                                                            2/2 
Warning: The unit file, source configuration file or drop-ins of ipsec.service changed on disk. Run 'systemctl daemon-reload' to reload units.

/usr/lib/tmpfiles.d/kdm.conf:1: Line references path below legacy directory /var/run/, updating /var/run/kdm/ → /run/kdm/; please update the tmpfiles.d/ drop-in file accordingly.
/usr/lib/tmpfiles.d/kdm.conf:2: Line references path below legacy directory /var/run/, updating /var/run/xdmctl → /run/xdmctl; please update the tmpfiles.d/ drop-in file accordingly.
/usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updating /var/run/net-snmp → /run/net-snmp; please update the tmpfiles.d/ drop-in file accordingly.

  Verifying        : libreswan-4.1-3.fc33.x86_64                                                            1/2 
  Verifying        : libreswan-4.1-2.fc33.x86_64                                                            2/2 

Upgraded:
  libreswan-4.1-3.fc33.x86_64                                                                                   

Complete!
[root@l2ppar ivo]#

Comment 18 Fedora Update System 2020-12-02 01:38:05 UTC
FEDORA-2020-60d3e6450d has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 19 Fedora Update System 2020-12-02 01:48:43 UTC
FEDORA-2020-19d974f925 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.