Closed carlespla closed 4 years ago
same on fedora 31 after maybe after libreswan update. temporary workaround: edit connection -Identity-> IPSEC settings->advanced->in Phase1 Algorithm put this line ( just removed *modp1024 from defaults):
aes256-sha2_256-modp2048,aes256-sha2_256-modp1536,aes256-sha1-modp2048,aes256-sha1-modp1536,aes256-sha1-ecp_384,aes128-sha1-ecp_256,3des-sha1-modp2048
Yeah, I can confirm it is after the libreseswan-3.30 update.
Extract from libreseswan-3.30 changes:
- pluto: Disable support for DH2/modp1024 at compile time [Paul]
Also extract from libreswan mailing list regarding DH2/modp1024 :
If you really want you can enable it at compile time with USE_DH2=true
But everything that supports DH2 also supports DH5. We are pretty sure nationstates can successfully attack DH2. You really cannot expect to use crypto parameters that were already not the most secure TWENTY years ago to still keep working unmodified.
That's unfortunate, I know of legacy VPN servers that only support DH2.
I'll update the Fedora NetworkManager-l2tp RPMs with a patch to remove modp1024.
I did some testing with libreseswan-3.30 to find out what its default proposals are. Below are its proposals in the order they are advertised :
Phase 1 - main mode (IKE) proposals:
AES_CBC_256/HMAC_SHA2_256_128/MODP_2048
AES_CBC_128/HMAC_SHA2_256_128/MODP_2048
AES_CBC_256/HMAC_SHA2_512_256/MODP_2048
AES_CBC_128/HMAC_SHA2_512_256/MODP_2048
AES_CBC_256/HMAC_SHA1_96/MODP_2048
AES_CBC_128/HMAC_SHA1_96/MODP_2048
AES_CBC_256/HMAC_SHA2_256_128/MODP_1536
AES_CBC_128/HMAC_SHA2_256_128/MODP_1536
AES_CBC_256/HMAC_SHA2_512_256/MODP_1536
AES_CBC_128/HMAC_SHA2_512_256/MODP_1536
AES_CBC_256/HMAC_SHA1_96/MODP_1536
AES_CBC_128/HMAC_SHA1_96/MODP_1536
3DES_CBC/HMAC_SHA2_256_128/MODP_2048
3DES_CBC/HMAC_SHA2_512_256/MODP_2048
3DES_CBC/HMAC_SHA1_96/MODP_2048
3DES_CBC/HMAC_SHA2_256_128/MODP_1536
3DES_CBC/HMAC_SHA2_512_256/MODP_1536
3DES_CBC/HMAC_SHA1_96/MODP_1536
Phase 2 - quick mode (ESP) proposals:
AES_CBC_128/HMAC_SHA1_96
3DES_CBC/HMAC_SHA1_96
The NetworkManager-l2tp README.md file lists the phase 1 and 2 algorithms NetworkManager-l2tp >= 1.2.16 uses for its default proposals (as the default libreswan or strongswan proposals aren't used). They are a merge of Win10 and iOS proposals, with the very weak proposals removed.
I'm pretty sure I will patch the NetworkManager-l2tp RPMs with a patch to remove modp1024 proposals from the existing NetworkManager-l2tp proposals, instead of using the default libreswan proposals as they don't include the ECP proposals Win10 clients use.
If anybody wants to use modp1024 on Fedora >= 30, they can switch from libreswan to strongswan with the following:
sudo rpm -e libreswan
sudo dnf install strongswan
The following are Fedora NetworkManager-l2tp 1.8.0-5 package update statuses, the new packages include a patch to support libreswan 3.30 which is no longer built with modp1024 support (https://src.fedoraproject.org/rpms/NetworkManager-l2tp/commits) :
Fedora 30 :
Fedora 31 :
Fedora 32 :
Fedora 33 / Rawhide :
Edit: the packages are no longer in testing and have been pushed to updates.
Just passing along some feedback I provided to the Fedora NetworkManager-l2tp RPMs that were in testing and have since been pushed to updates.
If you are no longer able to connect after a kernel update, then the issue is most likely with xl2tpd, not the libreswan 3.30 update.
Fedora >= 31 have blacklisted the L2TP kernel modules. Unblacklisting the L2TP kernel modules should fix the xl2tpd issue (and not to mention, make the connection faster), see the following for details:
Note: The patch in the packages pushed to Fedora testing (and the suggested Phase 1 Algorithms workaround for older versions of this package) is just to avoid the following config file syntax error with libreswan-3.30 :
ike string error: IKE DH algorithm 'modp1024' is not supported
I upgraded to F32 to see if the problem would be resolved, as apparently this was the case for coworkers who upgraded to the newest Ubuntu.
$ rpm -q NetworkManager-l2tp
NetworkManager-l2tp-1.8.0-5.fc32.x86_64
but unfortunately I still get:
pluto[43039]: Failed to add connection "776c7dfb-a022-4203-b140-5edd4e86b5c6": ike string error: IKE DH algorithm 'modp1024' is not supported
nm-l2tp-service[42738]: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
NetworkManager[1028]: <info> [1585094510.8221] vpn-connection[0x564e245a22e0,776c7dfb-a022-4203-b140-5edd4e86b5c6,"EditShare US | Boston",0]: VPN plugin: state changed: stopped (6)
NetworkManager[1028]: <info> [1585094510.8263] vpn-connection[0x564e245a22e0,776c7dfb-a022-4203-b140-5edd4e86b5c6,"EditShare US | Boston",0]: VPN service disappeared
NetworkManager[1028]: <warn> [1585094510.8281] vpn-connection[0x564e245a22e0,776c7dfb-a022-4203-b140-5edd4e86b5c6,"EditShare US | Boston",0]: VPN connection: failed to connect: 'Remote peer disconnected'
I don't get any errors suggesting blacklisted kernel modules, and modprobe doesn't address the issue.
libreswan >= 3.30 is no longer built with DH2 (modp1024) support, so if you are using libreswan, you can no longer specify any proposal in the Phase 1 Algorithms that contain modp1024, otherwise libreswan will output the ike string error: IKE DH algorithm 'modp1024' is not supported
error.
The NetworkManager-l2tp-1.8.0-5 upgrade just removed the 'modp1024' proposals from NetworkManager-l2tp 1.8.0's default proposals when libreswan is used.
As mentioned in an above message, if you need to use modp1024
on Fedora,, you can switch from libreswan to strongswan with the following:
sudo rpm -e libreswan
sudo dnf install strongswan
Ubuntu 20.04 by default uses strongswan instead of libreswan and if libreswan is used, it is using the older version 3.29 which is still built with DH2 (modp1024) support :
If users are using Ubuntu < 20.04, I would recommend the newer network-manager-l2tp packages from the following PPA instead :
Thanks for the clarification. I misunderstood the explanation as if the NetworkManager-l2tp
fix re-added modp2014
rather than removed it.
It looks like that package recommends libreswan
, and since I'm using Fedora Silverblue the dnf
/rpm
commads won't work for me. How do you remove a recommended package in rpm-ostree
?
Sorry I'm not familiar with rpm-ostree
at all.
On most other linux distros, libreswan and strongswan can't be installed at the same time, but Fedora renamed /usr/sbin/ipsec
to /usr/sbin/strongswan
for the strongswan RPM package to avoid a clash with libreswan's /usr/sbin/ipsec
.
NetworkManager-l2tp basically does /usr/sbin/ipsec --version
to determine if strongswan or libreswan is being used, if that file doesn't exist, it tries /usr/sbin/strongswan
.
So the simplest workaround to get NetworkManager-l2tp to use strongswan (assuming it is installed), would be to rename libreswan's /usr/sbin/ipsec
, e.g. :
sudo mv /usr/sbin/ipsec /usr/sbin/ipsec.bak
That's helpful to know thanks, but unfortunately for this circumstance Fedora Silverblue doesn't allow modification to those directories, as they are immutable to ensure the ability to stage changes and roll them back. The above returns:
$ sudo mv /usr/sbin/ipsec /usr/sbin/ipsec.bak
[sudo] password for kyra:
mv: cannot move '/usr/sbin/ipsec' to '/usr/sbin/ipsec.bak': Read-only file system
I'll see about staging direct changes to the filesystem, which I believe is possible.
P.S. I've raised the question here: https://github.com/coreos/rpm-ostree/issues/718#issuecomment-603816983
Edit: This gets things working temporarily, but doesn't persist through reboots (a planned feature for rpm-ostree
)
$ sudo rpm-ostree usroverlay
[sudo] password for kyra:
Development mode enabled. A writable overlayfs is now mounted on /usr.
All changes there will be discarded on reboot.
From the other ticket:
if NetworkManager-l2tp did something more like
Recommends: libreswan or strongswan
then it'd work to dorpm-ostree install NetworkManager-l2tp strongswan
.
So it would be nice if there could be a simple patch for that
I'm working on a new NetworkManager-l2tp 1.8.2 package and the new RPM will have Recommends: (libreswan or strongswan)
.
I've submitted a build of NetworkManager-l2tp 1.8.2-1 for Fedora 32, unfortunately the i686, PPC64 and ARM AArch64 architectures currently don't build because the C compiler can't build an executable according to a configure script test. As a result, I can't submit the RPMs, but it will probably resolve itself once those architectures' repositories are sorted out.
Thank you! How can the repositories sort themselves out? A limitation of the C compiler sounds like a non-trivial issue. Do you expect it to be resolved in the short term?
The new Fedora NetworkManager-l2tp 1.8.2-1 packages have been built and the update statuses can be found on the following pages :
Fedora 30 :
Fedora 31 :
Fedora 32 :
Fedora 33 / Rawhide :
When the packages move from pending to testing (last time it took 3 days, but can vary), info on how to install from testing will be provided on the above pages. Once in testing, feel free to vote, it only takes 3 votes for a package to move to stable, otherwise it will take 7 days to automatically move to stable.
Closing issue as the wiki has a description of this Libreswan known issue:
I did some testing with libreseswan-3.30 to find out what its default proposals are. Below are its proposals in the order they are advertised :
Phase 1 - main mode (IKE) proposals:
AES_CBC_256/HMAC_SHA2_256_128/MODP_2048 AES_CBC_128/HMAC_SHA2_256_128/MODP_2048 AES_CBC_256/HMAC_SHA2_512_256/MODP_2048 AES_CBC_128/HMAC_SHA2_512_256/MODP_2048 AES_CBC_256/HMAC_SHA1_96/MODP_2048 AES_CBC_128/HMAC_SHA1_96/MODP_2048 AES_CBC_256/HMAC_SHA2_256_128/MODP_1536 AES_CBC_128/HMAC_SHA2_256_128/MODP_1536 AES_CBC_256/HMAC_SHA2_512_256/MODP_1536 AES_CBC_128/HMAC_SHA2_512_256/MODP_1536 AES_CBC_256/HMAC_SHA1_96/MODP_1536 AES_CBC_128/HMAC_SHA1_96/MODP_1536 3DES_CBC/HMAC_SHA2_256_128/MODP_2048 3DES_CBC/HMAC_SHA2_512_256/MODP_2048 3DES_CBC/HMAC_SHA1_96/MODP_2048 3DES_CBC/HMAC_SHA2_256_128/MODP_1536 3DES_CBC/HMAC_SHA2_512_256/MODP_1536 3DES_CBC/HMAC_SHA1_96/MODP_1536
Phase 2 - quick mode (ESP) proposals:
AES_CBC_128/HMAC_SHA1_96 3DES_CBC/HMAC_SHA1_96
The NetworkManager-l2tp README.md file lists the phase 1 and 2 algorithms NetworkManager-l2tp >= 1.2.16 uses for its default proposals (as the default libreswan or strongswan proposals aren't used). They are a merge of Win10 and iOS proposals, with the very weak proposals removed.
I'm pretty sure I will patch the NetworkManager-l2tp RPMs with a patch to remove modp1024 proposals from the existing NetworkManager-l2tp proposals, instead of using the default libreswan proposals as they don't include the ECP proposals Win10 clients use.
If anybody wants to use modp1024 on Fedora >= 30, they can switch from libreswan to strongswan with the following:
sudo rpm -e libreswan sudo dnf install strongswan
can i disable pfs in strongswan?
@rithgan , pfs is disabled by default with strongswan, extract from:
Perfect Forward Secrecy (PFS) The pfs option has been removed and the default for IKEv1 has been changed from enabled to disabled. To enable PFS both IKEv1 and IKEv2 now use the same syntax, namely listing a Diffie-Hellman group in the ESP proposal, esp=aes128-sha1-modp2048.
Note: ESP proposal is referred to as the Phase 2 proposal in the GUI.
SO: Fedora 30 conn: "6e651357-96c1-48fa-b48b-4609860741c9" accept-redirect-to=
conn: "6e651357-96c1-48fa-b48b-4609860741c9" esp=aes256-sha1,aes128-sha1,3des-sha1
conn: "6e651357-96c1-48fa-b48b-4609860741c9" ike=aes256-sha2_256-modp2048,aes256-sha2_256-modp1536,aes256-sha2_256-modp1024,aes256-sha1-modp2048,aes256-sha1-modp1536,aes256-sha1-modp1024,aes256-sha1-ecp_384,aes128-sha1-modp1024,aes128-sha1-ecp_256,3des-sha1-modp2048,3des-sha1-modp1024
036 Failed to add connection "6e651357-96c1-48fa-b48b-4609860741c9": ike string error: IKE DH algorithm 'modp1024' is not supported
nm-l2tp[1300] Could not establish IPsec tunnel.