Bug 1894381
Summary: | Libreswan 4.1-2 breaks l2tp connection to Windows VPN server | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mikkel Lauritsen <renard> |
Component: | libreswan | Assignee: | Paul Wouters <pwouters> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 33 | CC: | 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
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. |