nm-l2tp / NetworkManager-l2tp

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

L2TP/IPsec failed connection "no shared key found for" #86

Closed hojendiz closed 3 years ago

hojendiz commented 6 years ago

Trying to connect to a VPN L2TP/IPsec and Pre-Shared Key using NetworkManager-l2tp with strongSwan logs the following error

...
no shared key found for X.X.X.X - Y.Y.Y.Y
generating INFORMATIONAL_V1 request 1586625757 [ N(INVAL_KE) ]
sending packet: from X.X.X.X[500] to Y.Y.Y.Y[500] (56 bytes)
establishing connection '8f9e1789-30e3-4fca-9530-0e7ef31dba67' failed
Stopping strongSwan IPsec...
nm-l2tp[14510] <warn>  Could not establish IPsec tunnel.
...

The system information

openSUSE Leap 15.0

Information for package NetworkManager-l2tp:
--------------------------------------------
Repository     : Main Repository (OSS)                             
Name           : NetworkManager-l2tp                               
Version        : 1.2.8-lp150.2.20                                  
Arch           : x86_64                                            
Vendor         : openSUSE      

Information for package strongswan-ipsec:
-----------------------------------------
Repository     : Main Repository (OSS)              
Name           : strongswan-ipsec                   
Version        : 5.6.0-lp150.2.19                   
Arch           : x86_64                             
Vendor         : openSUSE  

checking the /etc/ipsec.secrets file

# Following line was added by NetworkManager-l2tp
include /etc/ipsec.d/*.secrets

For some reason that line doesn't load the secrets, so I added the following line to the file /etc/strongswan.d/charon/stroke.conf secrets_file = /etc/ipsec.d/nm-l2tp-ipsec-8f9e1789-30e3-4fca-9530-0e7ef31dba67.secrets

Then I could connect without problems

dkosovic commented 6 years ago

I've setup a VM with openSUSE Leap 15.0 and did a zypper update, followed by zypper install NetworkManager-l2tp-gnome and not much more. I appear to be using the same version of strongSwan as you, but it is successfully loading the PSK.

With no Gateway ID set in the IPsec Options dialog box I see the following in the output :

Jul 23 08:25:50 linux-qoto charon[1826]: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jul 23 08:25:50 linux-qoto charon[1826]: 00[CFG] loading secrets from '/etc/ipsec.d/nm-l2tp-ipsec-f5757a64-347b-4baa-b0f6-ca51fd54d9d1.secrets.
Jul 23 08:25:50 linux-qoto charon[1826]: 00[CFG]   loaded IKE secret for %any

If I set the Gateway ID to for example 123.54.76.8, I see:

Jul 23 08:30:00 linux-qoto charon[1826]: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jul 23 08:30:00 linux-qoto charon[1826]: 00[CFG] loading secrets from '/etc/ipsec.d/nm-l2tp-ipsec-f5757a64-347b-4baa-b0f6-ca51fd54d9d1.secrets.
Jul 23 08:30:00 linux-qoto charon[1826]: 00[CFG]   loaded IKE secret for 123.54.76.8

In your case, I don't know why it can't find a shared key for X.X.X.X - Y.Y.Y.Y and that include /etc/ipsec.d/*.secrets line is being ignored for some reason.

dkosovic commented 6 years ago

Anyway I'm still looking into the issue, but at a loss for the moment on how to reproduce.

Just for completeness, the only additional things other than configuring the VPN connection I did were:

sudo systemctl stop wicked
sudo systemctl disable wicked
sudo systemctl enable NetworkManager
sudo systemctl start NetworkManager

sudo reboot

But having said that, my strongSwan connection fails to connect with little info on why.

dkosovic commented 6 years ago

Got past my strongSwan issue, for some reason I have to enter phase 1 and phase 2 algorithms with an exclamation mark (!) at the end, even though my VPN server is proposing algorithms that aren't weak.

Looks like Leap 15.0 backported something from kernel 4.15 or later as I now see the following xl2tpd error :

udp_xmit failed ... with err=-1:No such device

that error is typically associated with kernel 4.15 and later, see:

As a workaround, you can build xl2tpd from source code and overwrite the broken system xl2tpd :

sudo zypper install libpcap-devel git gcc
sudo systemctl stop xl2tpd
git clone https://github.com/xelerance/xl2tpd.git
cd xl2tpd
make
sudo cp xl2tpd /usr/sbin/xl2tpd

I've previously reported the xl2tpd bug for Tumbleweed and now added a comment that it also affects Leap 15.0 :

dkosovic commented 5 years ago

With commit 70c5f72, /etc/ipsec.d/ipsec.nm-l2tp.secrets is now used instead of /etc/ipsec.d/nm-l2tp-ipsec-UUID.secrets. I've given up on the idea of running multiple instances of NetworkManager-l2tp, consequently only one instance of IPsec secrets file is required.

The following line is now appended to the /etc/ipsec.secrets file at runtime (it explicitly loads the file with a relative path and doesn't use a wildcard like previously) :

include ipsec.d/ipsec.nm-l2tp.secrets

previously it would append the following line :

include /etc/ipsec.d/*.secrets

Although I wasn't able to reproduce your issue, hopefully it fixes it. I'm guessing the wildcard was the issue.

I had to do this change for another issue.

R4md4c commented 4 years ago

I'm sorry to comment on an issue that might be too old, but it just popped out while searching for a solution for my problem.

I faced the same problem as well, and it got solved when I added secrets_file = /etc/ipsec.d/ipsec.nm-l2tp.secrets in /etc/strongswan.d/charon/stroke.conf. So apparently that commit didn't fix it.

dkosovic commented 4 years ago

@R4md4c which Linux distribution and version of strongSwan are you using? I'll like to reproduce the issue.

By default with strongSwan, secrets_file is set to ${sysconfdir}/ipsec.secrets which on most Linux distros would be /etc/ipsec.secrets and that is where the include ipsec.d/ipsec.nm-l2tp.secrets line now gets added.

It seems like a strongSwan bug.

R4md4c commented 4 years ago

I'm using Arch Linux with latest packages, and with strongSwan version 5.8.2. also the stroke.conf file was empty so it must have been using the default from /etc/ipsec.secrets however for some reason it failed to read it.

dkosovic commented 4 years ago

I wasn't able to reproduce this issue on Arch Linux with latest packages, but somehow managed to achieve it without trying on a different linux distro and resetting the security context of /etc/ipsec.secrets helped :

sudo restorecon /etc/ipsec.secrets