search

nm-l2tp / NetworkManager-l2tp

L2TP and L2TP/IPsec support for NetworkManager
GNU General Public License v2.0
486 stars 84 forks source link

VPN doesn't work with Kubuntu 20.04 #124

Closed mauro-miatello closed 4 years ago

mauro-miatello commented 4 years ago

I'm trying Kubuntu 20.04 and vpn doesn't work, same configuration in kde neon (ubuntu 18) works

in log I've "we require IKEv1 peer to have ID '185.x.y.z', but peer declares '192.168.10.26'" but in ipsec I've set right ip for id gateway

another issue is that it keeps going on to try to connect even if I don't click on vpnm connection in network manager

EDIT: I solved installing strongswan, but in Ubuntu 18 it works only with libreswan. is it right?

dkosovic commented 4 years ago

Sounds like you are having an issue with phase 1 (main mode) or phase 2 (quick mode) algorithms, but hard to say for certain without looking at the logs.

Ubuntu 18.04 shipped with a pretty old network-manager-l2tp 1.2.8 which uses the default proposals of libreswan and strongswan. The default strongswan proposals were pretty strong, probably too strong for most VPN servers, while libreswan still offered proposals with the Win2000 L2tp client era modp1024. Things changed with network-manager-l2tp version 1.2.16 as mentioned in the README.md file:

As of NetworkManager-l2tp version 1.2.16, it was decided to compromise for backwards compatibility by not using the strongSwan and libreswan default set of allowed algorithms, instead algorithms that are a merge of Windows 10 and macOS/iOS/iPadOS L2TP/IPsec clients' IKEv1 proposals are used instead. The weakest proposals that were not common to both Win10 and iOS were dropped, but all of the strongest ones were kept

I provide PPAs for older version of Ubuntu to use the newer network-manager-l2tp packages :

As of libreswan 3.30, libreswan is no longer built with modp1024 (aka DH2) support, so I'm about to do a maintenance release of network-manager-l2tp 1.2.16 which includes a patch to drop modp1024 from the network-manager-l2tp default proposals when libreswan is used. Without the patch, you would get a ike string error: IKE DH algorithm 'modp1024' is not supported error.

So I'm guessing you are using modp1024.

Unfortunately Kubuntu 20.04 probably wont have the new plasma-nm l2tp UI, although the KDE Neon Ubuntu 20.04 probably will : L2TP main window L2TP IPsec settings dialog

dkosovic commented 4 years ago

Actually, it is most likely that your VPN server doesn't support PFS (perfect forward secrecy) as Ubuntu 20.04 doesn't have libreswan 3.30 yet, which is enabled by default since network-manager-l2tp 1.2.12 (enabling PFS by default is actually libreswan's default behaviour). in the newer plasma-nm IPsec settings dialog, you'll notice a "Disable PFS" checkbox, unfortunately that checkbox is missing in the older plasma-nm UI. Note: the "Disable PFS" checkbox is grayed out if strongswan is detected instead of libreswan.

dkosovic commented 4 years ago

Actually regarding the Gateway ID (or Remote ID in newer networkmanager-l2tp versions), the corresponding code hasn't changed since the version of network-manager-l2tp in Ubuntu 18.04 (apart from Gateway ID being relabelled Remote ID in the GNOME UI and newer KDE plasma-nm UI).

Sorry if that is the only error you are seeing, I'm not sure why there would be differences between Ubuntu 18.04 and 20.04. I was rattling off other issues other users were experiencing or ones I know about with the latest versions of the packages, but seems like you aren't encountering those.

dkosovic commented 4 years ago

Thanks for the bug report, commit https://github.com/nm-l2tp/NetworkManager-l2tp/commit/1c6fafd53ffc9186cb21dd033d8f462c2196f60a should fix the issue.

It was an issue with the backwards compatibility of the Gateway ID.

Apart from the backwards Gateway ID handling code, the generated ipsec config options haven't changed between Gateway ID and Remote ID when compared to earlier versions of network-manager-l2tp.

You would have been using %any for the rightid ipsec config option with Ubuntu 20.04 regardless of what was specified in the Gateway ID field before this commit. With 18.04 you can achieve the same effect by not specifying anything in the Gateway ID. Not sure why libreswan needs an IP address in your case and why it didn't like %any, but strongswan was happy with %any.