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)
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.
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
We also followed up downstream USG: https://community.ui.com/questions/Cant-L2TP-VPN-from-USG-Pro4-from-Fedora-33-libreswan-4-1/ad9657d6-6c4a-499f-b8d1-32f7afa8a8b4
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
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
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.
*** Bug 1897440 has been marked as a duplicate of this bug. ***
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.
FEDORA-2020-60d3e6450d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-60d3e6450d
FEDORA-2020-19d974f925 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-19d974f925
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.
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.
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?
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
[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...
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]#
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.
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.