Bug 1894381 - Libreswan 4.1-2 breaks l2tp connection to Windows VPN server
Summary: Libreswan 4.1-2 breaks l2tp connection to Windows VPN server
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libreswan
Version: 33
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1897440 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-04 07:43 UTC by Mikkel Lauritsen
Modified: 2020-12-03 09:13 UTC (History)
8 users (show)

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:
Clone Of:
Environment:
Last Closed: 2020-11-23 17:11:22 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.