Can you tell me a bit more? Did you upgrade the server side or the client side or both?

Most likely, algorithms are being used on one side that have been removed from the default set of allowed algorithms. So the server side might need a more modern configuration. This could be that the client was using modp1024 which is no longer in the default set for being to weak, or md5.

What are your ike/esp lines on the server? Or if the server is not libreswan, I guess we maybe need to fixup NetworkManager-l2tp to use modp1536 instead of modp1024 ?

From the README.md of the package:

Legacy ciphers that are considered broken are regularly removed from the
default ciphers for strongSwan and Libreswan. This means VPN servers that are
using only legacy ciphers that strongSwan or Libreswan now consider broken will
result in a failed connection, unless user specified ciphers to supplement or
override the default ciphers are used.

User specified phase 1 (ike) and phase 2 (esp) cipher suites can be specified
in the IPsec configuration dialog box under Advanced options.

For example if you are using strongSwan with this VPN plugin and you need to
use the same ciphers that older versions of strongSwan and this VPN plugin
used, enter the following in the corresponding IPsec configuration dialog text
boxes:

* Phase1 Algorithms : aes128-sha1-modp2048,3des-sha1-modp1536,3des-sha1-modp1024
* Phase2 Algorithms : aes128-sha1,3des-sha1

Please see the IPsec IKEv1 ciphers section in the Wiki for more details
including how to query the VPN server for the ciphers it supports :
* https://github.com/nm-l2tp/network-manager-l2tp/wiki/Known-Issues

Only the client side was upgraded. I'm not aware of what the server is running. The use of legacy ciphers on the server side could be the issue here. I will check if this is the case.

This bug got me also. 

The server I connect to is Windows based (believe its 2012 R2); which wasn't changed: 


I running Fedora 26 Workstation, 4.12.13-300.fc26.x86_64 on a laptop and a clone desktop. After I ungraded to libreswan-3.21-1.fc26.x86_64 my VPN stopped working. After troubleshooting; I found that after downgrading to libreswan-3.18-1.fc26.x86_64 it works again. The log messages on my system were the same as reported by Alvin.

Re-assigning to NetworkManager-l2tp. Their ipsec configuration should be changed to use a more secure modp group (eg modp2048 or modp1536) and avoid using md5 (sha1 or sha2 is fine)

Could you run the script in the "Querying VPN server for supported IPsec IKEv1 ciphers" section located on the following page ?

https://github.com/nm-l2tp/network-manager-l2tp/wiki/Known-Issues#querying-vpn-server-for-supported-ipsec-ikev1-ciphers

and as mentioned on that page, grep for SA to reduce the output produced by that script, e.g. :

sudo ipsec stop
chmod a+rx ./ike-scan.sh
sudo ./ike-scan.sh 123.54.76.9 | grep SA


I would like to see the output to know what ciphers the VPN server supports.


The phase 1 algorithm syntax is a bit different between strongswan and libreswan. I need to fix up the NetworkManager-l2tp Wiki documentation for libreswan.

I ran that script and the line you're looking for is:

SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration(4)=0x00007080)

using 3des-sha1;modp1024 is too old and weak and legacy.

it should use at minimum:

ike=aes-sha2;modp2048
esp=aes_gcm-null

I've updated the NetworkManager-l2tp README.md file :
  https://github.com/nm-l2tp/network-manager-l2tp/blob/master/README.md

Extract :

## VPN servers using IPsec IKEv1 broken algorithms

There is a general consensus that the following algorithms are now considered broken in regards to security and should no longer be used.

Encryption Algorithms :
* 3DES
* Blowfish

Integrity Algorithms :
* MD5
* SHA1

Diffie Hellman Groups :
* MODP768
* MODP1024

Legacy algorithms that are considered broken are regularly removed from the default set of allowed algorithms with newer releases of strongSwan and Libreswan. As of Libreswan 3.2.20 and strongSwan 5.4.0, the above algorithms have been or in some cases already been dropped from the default set of allowed algorithms.

Please see the IPsec IKEv1 algorithms section in the Wiki for more details including how to query the VPN server for the algorithms it supports :
* https://github.com/nm-l2tp/network-manager-l2tp/wiki/Known-Issues

If the VPN server is using broken algorithms, it is recommended that it be reconfigured to use stronger algorithms. If for some reason the VPN server cannot be reconfigured and you are not too concerned about security, user specified phase 1 (ike) and phase 2 (esp) algorithms can be specified in the IPsec configuration dialog box under the `Advanced` options for a workaround.

### Example workaround for 3DES, SHA1 and MODP1024 broken algorithms

Unfortunately there are many L2TP/IPsec VPN servers still offering only 3DES, SHA1 and MODP1024. One of the main reasons possibly for this is because it is the default Microsoft has offered with their L2TP/IPsec VPN servers since the days Windows XP was the main client.

If you are using strongSwan for IPsec client support, enter the following in the corresponding IPsec configuration dialog text boxes:

* Phase1 Algorithms : 3des-sha1-modp1024
* Phase2 Algorithms : 3des-sha1

If you are using Libreswan >= 3.2.20 for IPsec client support, enter the following in the corresponding IPsec configuration dialog text boxes:

* Phase1 Algorithms : 3des-sha1;modp1024
* Phase2 Algorithms : 3des-sha1

The 'Phase1 Algorithms' and 'Phase2 Algorithms' text boxes in the IPsec Options dialog box were first introduced with NetworkManager-l2tp version 1.2.6 and were copied from NetworkManager-libreswan.

NetworkManager-l2tp screenshots including the IPsec Options dialog box can be seen here:
   https://github.com/nm-l2tp/network-manager-l2tp/wiki/Screenshots

If the 'Phase1 Algorithms' and 'Phase2 Algorithms' text boxes are not filled in, then no corresponding ike and esp lines are generated in the temporary  ipsec config file that gets used.

KDE doesn't use the NetworkManager-l2tp GUI (i.e. the NetworkManager-l2tp-gnome package), but provide their own front end, on Fedora the specific KDE package is called plasma-nm-l2tp. 

The 'Phase1 Algorithms' and 'Phase2 Algorithms' text boxes were first provided with KDE's Plasma 5.11, unfortunately Fedora 25 and 26 only offer plasma-nm-l2tp 5.10 at the moment.

If you are using KDE with Plasma 5.10 and aren't able to reconfigure the VPN server to use algorithms that aren't broken, so really need to fill in the 'Phase1 Algorithms' and 'Phase2 Algorithms' text boxes, you could install the GNOME based connection editor, e.g. :

    sudo dnf install nm-connection-editor NetworkManager-l2tp-gnome

then use /usr/bin/nm-connection-editor to edit or create L2TP/IPsec connections.

KDE bug# 380859 has the patch for phase 1 and 2 algorithms support if you want to backport to Plasma 5.10 :
  https://bugs.kde.org/show_bug.cgi?id=380859

Anyway, I don't think there is any bug with the NetworkManager-l2tp-1.2.8 and NetworkManager-l2tp-gnome-1.2.8 packages as they provide a workaround for dealing with VPN servers that are only proposing broken algorithms.

KDE users might want to lodge a separate bug request to have KDE Plasma upgraded to version 5.11.

Happy to accept any suggestions or fixes for what I wrote in the NetworkManager-l2tp README.md file or any other suggestions.

Also sorry for not responding sooner.

updating the README.md is a very poor solution to this problem.

The proper solution is to upgrade the phase1/phase2 algorithms to more modern versions, or to not specify them and rely on the defaults of libreswan.

If users don't fill out the optionally specified phase1/phase2 algorithms in the advanced section of NetworkManager-l2tp's IPsec Optionals dialog box, then the libreswan defaults are used as no ike= and esp= lines are generated. By default, the phase1/phase2 algorithms text boxes are hidden in a GTK Expander in order to discourage users from filling them in with values.

Although I said I copied the phase1/phase2 algorithms text boxes from NetworkManager-libreswan, unlike that VPN client, I don't override the libreswan defaults when users don't fill in the phase1/phase2 algorithms text boxes. 

As the current upstream maintainer of NetworkManager-l2tp, I'm not sure what else I can do. I have never overridden the libreswan ike and esp defaults defaults since I updated NetworkManager-l2tp to work with libreswan. But I am guilty for a brief period of supplementing the strongswan defaults with 3des-sha1-modp1024.

As far as I can see, the proper solution is to upgrade the phase1/phase2 algorithms on the VPN server side with modern ones.

In regards to this default proposals issue between libreswan-3.21 and RRAS 
 on Windows Server 2012 R2, the aforementioned updated NetworkManager-l2tp README.md file :
- lists what broken algorithms shouldn't be used for security reasons.
- indicates which libreswan versions are affected.
- provides link for method to query VPN server for algorithms it proposes.
- provides example workaround when users aren't able to upgrade the IPsec IKEv1 algorithms on the server side and aren't too concerned about security.

Details on how to configure Microsoft RRAS on Windows Server to use stronger IPsec IKEv1 algorithms are out of the scope of this bug report, I also don't know how.

I still need to update the NetworkManager-l2tp Wiki a bit, but think the README.md file covers the issue here and is what the users see when they land on the NetworkManager-l2tp github homepage.

Libreswan ipsec.conf man page should probably be updated, it doesn't mention modp2048 and seems to imply modp1024 and 3des are still used in the default set.

upstream man page:

For IKEv1, 3DES, SHA1 and MODP1536 are still allowed per default for backwards compatibility. IKEv2's minimum is AES, MODP2048 and SHA2. The default key size is
256 bits. The default AES_GCM ICV is 16 bytes.


I've just removed "3DES" from that list.

If you don't specify ike/esp lines, then I agree the remote VPN server needs an update to its configuration and that's not a bug in this package

Thanks, I'll point the NetworkManager-l2tp Wiki and/or the README.md file to the upstream man page. I still need to fix the grammar in the README.md file and want to redo parts of the Wiki.

It was in comment 7, where it was determined the VPN server was only offering the broken "ike=3des-sha1;modp1024" proposal for phase 1. I wrote that simple script to make it easier to debug issues like this as I was getting lots of strongswan NetworkManager-l2tp users complaining they couldn't connect anymore after I removed hardcoded ike/esp lines and switched to the strongswan defaults.