search

nm-l2tp / NetworkManager-l2tp

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

Adding 2nd L2TP VPN causes wrong PSK to be used #112

Closed Lonniebiz closed 4 years ago

Lonniebiz commented 4 years ago

In Ubuntu 19.10, upon adding a 2nd L2TP VPN connection, it not only doesn't work, but it also corrupts the first one I added that was working fine.

Details: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/746

dkosovic commented 4 years ago

Extract from the strongSwan FAQ in regards to the invalid HASH_V1 payload length, decryption failed? error:

Q: I'm getting the error message "invalid HASH_V1 payload length, decryption failed?" when using PSK authentication. What could be the reason?

A: This is most likely due to an incorrect PSK on one of the peers. Since the PSK is incorporated into the key material used so secure the IKEv1 packets they can't be decrypted properly if the PSKs don't match.

So the VPN connection is using the wrong PSK. I can't see which PSK file it is using as it would be shown in the logs before what you provided, but I'm pretty sure you have a stray PSK file that didn't get deleted and you most likely didn't qualify with a Gateway ID in the IPsec Options dialog box, so is using %any instead of the ID of the VPN server so the PSK would be used with any connection.

To delete the stray PSK files that didn't get deleted, issue:

sudo su -
rm -f /etc/ipsec.d/nm-l2tp-ipsec*.secrets

normally the /etc/ipsec.d/nm-l2tp-ipsec*.secrets PSK files get deleted when the VPN connection gracefully goes down, but if it is killed (e.g. computer shutting down), stray PSK files can remain. The reason the PSK files are kept during the lifetime of the connection, is because they are required for re-keying.

I didn't make Gateway ID mandatory in the IPsec Options dialog box as it can cause issues for certain scenarios. In newer versions of NetworkManager-l2tp, Gateway ID has been renamed to Remote ID to match other operating systems and NetworkManager-libreswan.

This has been fixed with NetworkManager-1.2.12 and later, which uses /etc/ipsec.d/ipsec.nm-l2tp.secrets for the PSK, so uses the same PSK filename for all connections. I gave up on the idea of allowing multiple L2TP/IP sec VPN connections at the same time, so got rid of the UUID in the PSK filename.

Ubuntu 20.04 will be using the newer version of network-manager-l2tp from Debian Sid:

I've never had luck submitting backported packages to Ubuntu Backports, which seems to be user voting based and could only get a handful of users to vote, so never made it on the radar of the Ubuntu Backporters team. I basically have no privileges for submitting packages to Ubuntu, I usually contact my Debian sponsor who submits new packages to Debian and the package finds its way automatically to the next version of Ubuntu.

Lonniebiz commented 4 years ago

@dkosovic You're correct that a Gateway ID is NOT something I provided in both of those L2TP VPN profiles. Both of the VPN servers are Meraki and their documentation says to leave that field blank.

Is this Gateway ID an arbitrary input; meaning can I put in what ever I like into that field? Is the purpose of that field to just indicate an arbitrary name client-side, so that Linux can distinguish between multiple L2TP VPN profiles?

If so, when that field is left blank by the user, why doesn't the GUI (or underlying modules) just generate a Gateway ID for that purpose? It seems to me that it could simply re-use the overall VPN Identity name as the Gateway ID as shown here: GatewayID

What are your thoughts? Since Meraki doesn't need a Gateway ID, but Linux does, why not auto-propagate it?

Update: After rereading your post, I see that you've already addressed much of what I'm asking.

Lonniebiz commented 4 years ago

I've tried to persuade Ubuntu to upgrade the software version here: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1849930/

(see comment 7)

dkosovic commented 4 years ago

Just general info on how the Gateway ID is used.

The Gateway ID (or Remote ID in newer versions) is used in two places, the first is for the generated IPsec config file where it is used for the rightid value and the second for qualifying the PSK in the IPsec secrets file. More details on the ID syntax on the following strongSwan page:

The Gateway ID is typically the IP address of the VPN server, but often it is a internal private IP address, not the public facing IP address used to connect to it, in many cases it isn't even a static IP address. If you fill in the Gateway ID with something arbitrary, you'll get an error message something along the lines of a a Peer ID mismatch and you'll be able to see what the VPN server is trying to use for the Gateway ID.

If the Gateway ID isn't supplied, it gets set it to %any , so will work with almost any connection, but there are some very rare cases where the VPN server insists on the Gateway ID being set.

NetworkMananger-l2tp can't tell strongSwan or libreswan which PSK file to use, so an included file from /etc/ipsec.secrets is used.

seb128 commented 4 years ago

Hey there, speaking as an Ubuntu maintainer, new version which are not bugfixes only one are not obvious candidate for a stable update (SRU), we prefer backporting specific commits/fixes in those case. Unsure the fix describe here is a category of 'bugfix commit that can be easily backported' though...

dkosovic commented 4 years ago

@Lonniebiz could you try the following Ubuntu 19.10 network-manager-l2tp 1.2.10-1ubuntu1 PPA package which I suspect could be used as a proposed package upgrade for a SRU :

For LP: 1849930 it contains a patch based on commit# https://github.com/nm-l2tp/NetworkManager-l2tp/commit/70c5f7257dfd3b27bbf29deec0037a07051aebda

For LP: 1778946 it contains a patch based on commit# https://github.com/nm-l2tp/NetworkManager-l2tp/commit/479cb0da09168bde03d7f97147fa14ff591388d2

It also contains debian/network-manager-l2tp.preinstand debian/network-manager-l2tp.postrm from the current release in Sid which delete any stray PSK files.

Lonniebiz commented 4 years ago

I confirm that the packages in the PPA above worked for me.

Here are the steps I took to test the PPA:

1) I installed Ubuntu 19.10 into a fresh virtualbox virtual machine.

2) I updated all packages: sudo apt update ; sudo apt upgrade

3) After rebooting, I install these package:

sudo apt install network-manager-l2tp network-manager-l2tp-gnome strongswan

4) I upgraded to the packages provided by Douglas Kosovic's PPA

sudo add-apt-repository ppa:dkosovic/sru-network-manager-l2tp
sudo apt-get update
sudo apt upgrade

5) After rebooting once more, I added two different L2TP VPNs via Gnome-Control-Center. Both succeeded, and thereafter I was able to toggle between the two without issue.

dkosovic commented 4 years ago

@Lonniebiz your call if you want to submit a new SRU bug report using the SRU bug template as described here:

I've uploaded a new network-manager-l2tp (1.2.10-1ubuntu1) package which has changes based on the comments in your original Ubuntu bug report, LP: 1849930 :

It doesn't worry me if a SRU isn't submitted.

I have built new network-manager-l2tp 1.2.16 packages backported from Debian sid in this PPA repository :

I would recommend using network-manager-l2tp 1.2.16 instead of the older 1.2.10 as it has many bug fixes and enhancements.

Lonniebiz commented 4 years ago

@dkosovic Thanks for your help.