search

nm-l2tp / NetworkManager-l2tp

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

Unable to connect to L2TP over IPSec network #47

Closed shyamsathyanathan closed 7 years ago

shyamsathyanathan commented 7 years ago

Whenever I try to connect to an L2TP over IPSec network, I get the following error:

(nm-l2tp-service:3272): GLib-GIO-CRITICAL **: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed

Is there something wrong with my dbus?

I am running Ubuntu 16.04 GNOME

dkosovic commented 7 years ago

You don't have a D-Bus issue, it is just a side-effect of something else failing. Other NetworkManager VPN clients have the same g_dbus_method_invocation_take_error and I'm not sure exactly where it happens as the g_dbus_method_invocation_take_error()function is no longer used directly in this VPN plugin's code.

I assume you are using network-manager-l2tp and network-manager-l2tp-gnome version 1.2.6 packages from the PPA. The most common issue is that the VPN server is using a legacy cipher that newer strongSwan versions consider broken and you need to override in the IPsec dialog box advanced settings, see first issue on following page:

You might also try:

sudo systemctl restart NetworkManager
sudo systemctl stop xl2tpd

then try reconnecting the VPN connection.

dkosovic commented 7 years ago

if you provide some of the output of journalctl -b I could take a look at where it fails.

shyamsathyanathan commented 7 years ago

I tried restarting NetworkManager and stopping xl2tpd like you said, but that does not seem to do anything.

Here is a portion of the output of journalctl -b

May 31 15:02:17 shyam-ThinkPad-P50 charon: 12[IKE] sending retransmit 1 of request message ID 0, seq 1                                                                   
May 31 15:02:17 shyam-ThinkPad-P50 charon: 12[NET] sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)                                               
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: nm-l2tp[3231] <warn>  Timeout trying to establish IPsec connection                                               
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: nm-l2tp[3231] <info>  Terminating ipsec script with PID 3329.                                                    
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: nm-l2tp[3231] <warn>  Could not establish IPsec tunnel.                                                          
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: (nm-l2tp-service:3231): GLib-GIO-CRITICAL **: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: <info>  [1496223143.4511] vpn-connection[0x1789210,abcd-efgh-ijkl-mnop-qrstuvwxyz,"XYZ",0]: VPN plugin: state changed: stopped (6) 
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: <info>  [1496223143.4545] vpn-connection[0x1789210,abcd-efgh-ijkl-mnop-qrstuvwxyz,"XYZ",0]: VPN plugin: state change reason: unknown (0)
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: <info>  [1496223143.4569] vpn-connection[0x1789210,abcd-efgh-ijkl-mnop-qrstuvwxyz,"XYZ",0]: VPN service disappeared
May 31 15:02:23 shyam-ThinkPad-P50 NetworkManager[974]: <warn>  [1496223143.4604] vpn-connection[0x1789210,abcd-efgh-ijkl-mnop-qrstuvwxyz,"XYZ",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying'  
May 31 15:02:24 shyam-ThinkPad-P50 charon: 13[IKE] sending retransmit 2 of request message ID 0, seq 1                                                                   
May 31 15:02:24 shyam-ThinkPad-P50 charon: 13[NET] sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)                                               
May 31 15:02:37 shyam-ThinkPad-P50 charon: 14[IKE] sending retransmit 3 of request message ID 0, seq 1                                                                   
May 31 15:02:37 shyam-ThinkPad-P50 charon: 14[NET] sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)                                               
May 31 15:03:00 shyam-ThinkPad-P50 charon: 15[IKE] sending retransmit 4 of request message ID 0, seq 1                                                                   
May 31 15:03:00 shyam-ThinkPad-P50 charon: 15[NET] sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)
shyamsathyanathan commented 7 years ago

I would like to add that I had issues connecting to L2TP over IPSec previously and someone recommended updating xl2tpd to latest version. So I am running xl2tpd version 1.3.9 right now. This actually fixed the initial issue I had. But now, I think this is a whole new issue. I don't know if these are related in any way, putting this in here just in case if this has something to do with this.

shyamsathyanathan commented 7 years ago

My strongswan version is 5.3.5-1ubuntu3.3

dkosovic commented 7 years ago

It first does an IPsec connection then L2TP, so the xl2tpd version wouldn't have an impact until after the IPsec connection is established. In your case, the IPsec tunnel isn't getting established.

The newer xl2tpd fixed an issue with orphaned pppd processes as mentioned in the following known issues topic, and the xl2tpd bug fix has been back ported to Ubuntu 16.04 (which was only pushed out in the last week or so) :

Stopping the system xl2tpd service before running NetworkManager-l2tp was recommended for earlier versions of this plug-in, but still may be the case with some VPN servers.

Anyway with the log output you posted just shows NetworkManager-l2tp sending a kill signal to PID 32040 after a 10 second timeout trying to establish the IPsec connection. The IPsec issue is before that.

dkosovic commented 7 years ago

I wouldn't worry about obfuscating the UUID to abcd-efgh-ijkl-mnop-qrstuvwxyz as you can confirm by running /usr/bin/uuidgen a few times, the UUID is totally random each time you run it. If you delete and add a new VPN connection, NetworkManager creates a completly new UUID.

dkosovic commented 7 years ago

Forgot to mention, to just check the IPsec connection, you could do the following on the command-line:

sudo ipsec restart --conf /var/run/nm-l2tp-ipsec-abcd-efgh-ijkl-mnop-qrstuvwxyz.conf --debug
sudo ipsec up abcd-efgh-ijkl-mnop-qrstuvwxyz

and then double check the IPsec connection is up by issuing sudo ipsec status

shyamsathyanathan commented 7 years ago

When I run ipsec up it gives up after trying for 5 times. I get the following message:

giving up after 5 retransmits
peer not responding, trying again (2/0)
dkosovic commented 7 years ago

Without seeing the rest of the output, it's hard to say what is going on. I assume there are some responses from the VPN server before it gets to that point. If it isn't responding at all, then the VPN server is most likely down.

Could you install ike-scan and run the following script :

does the VPN server respond with anything for the above script? You may need to add the ciphers that the script returns.

shyamsathyanathan commented 7 years ago

There is definitely nothing wrong with the server itself because people are able to connect to it from Windows and Mac. Here is the full output:

initiating Main Mode IKE_SA c936ca4e-d5b8-42dc-bf99-654c1343a601[1] to x.x.x.x
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)
sending retransmit 1 of request message ID 0, seq 1
sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)
sending retransmit 2 of request message ID 0, seq 1
sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)
sending retransmit 3 of request message ID 0, seq 1
sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)
sending retransmit 4 of request message ID 0, seq 1
sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)
sending retransmit 5 of request message ID 0, seq 1
sending packet: from 192.168.1.13[500] to x.x.x.x[500] (248 bytes)
giving up after 5 retransmits
peer not responding, trying again (2/0)

I'll try ike-scan and update. But I used to connect to the server with the same setup a few weeks ago.

shyamsathyanathan commented 7 years ago

Output of 

sudo ./ike-scan.sh x.x.x.x | grep SA

gives

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

You have just confirmed your VPN server only uses 3DES which strongSwan considers insecure and broken. As mentioned in my first comment, you need to go to the IPsec dialog box advanced options, and in your case set:

shyamsathyanathan commented 7 years ago

Ah.. Thank you. This seems to have fixed it after the NetworkManager restart. I wasn't able to figure out this was in fact listed in the "known bugs"! Sorry for bothering you :)

shyamsathyanathan commented 7 years ago

Hey, sorry to bother you again, but this stopped working again today. I have the Phase1 and Phase2 algorithms set as it was yesterday, but all I did was restart the computer. Here is the output of sudo ipsec up c936ca4e-d5b8-42dc-bf99-654c1343a601

initiating Main Mode IKE_SA c936ca4e-d5b8-42dc-bf99-654c1343a601[1] to x.x.x.x
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from 192.168.100.21[500] to x.x.x.x[500] (212 bytes)
received packet: from x.x.x.x[500] to 192.168.100.21[500] (132 bytes)
parsed ID_PROT response 0 [ SA V V V ]
received XAuth vendor ID
received NAT-T (RFC 3947) vendor ID
received DPD vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.100.21[500] to x.x.x.x[500] (244 bytes)
received packet: from x.x.x.x[500] to 192.168.100.21[500] (228 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
sending retransmit 1 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
sending retransmit 2 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
sending retransmit 3 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
sending keep alive to x.x.x.x[4500]
sending retransmit 4 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
sending keep alive to x.x.x.x[4500]
sending keep alive to x.x.x.x[4500]
sending retransmit 5 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
sending keep alive to x.x.x.x[4500]

The output of journalctl -b

Jun 01 15:58:54 shyam-ThinkPad-P50 charon[7705]: 15[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
Jun 01 15:58:54 shyam-ThinkPad-P50 charon[7705]: 15[IKE] local host is behind NAT, sending keep alives
Jun 01 15:58:54 shyam-ThinkPad-P50 charon[7705]: 15[ENC] generating ID_PROT request 0 [ ID HASH ]
Jun 01 15:58:54 shyam-ThinkPad-P50 charon[7705]: 15[NET] sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
Jun 01 15:58:58 shyam-ThinkPad-P50 charon[7705]: 04[IKE] sending retransmit 1 of request message ID 0, seq 3
Jun 01 15:58:58 shyam-ThinkPad-P50 charon[7705]: 04[NET] sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: nm-l2tp[7662] <warn>  Timeout trying to establish IPsec connection
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: nm-l2tp[7662] <info>  Terminating ipsec script with PID 7731.
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: nm-l2tp[7662] <warn>  Could not establish IPsec tunnel.
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: (nm-l2tp-service:7662): GLib-GIO-CRITICAL **: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: <info>  [1496312943.5375] vpn-connection[0x1034590,c936ca4e-d5b8-42dc-bf99-654c1343a601,"XYZ",0]: VPN plugin: state changed: stopped (6)
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: <info>  [1496312943.5406] vpn-connection[0x1034590,c936ca4e-d5b8-42dc-bf99-654c1343a601,"XYZ",0]: VPN plugin: state change reason: unknown (0)
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: <info>  [1496312943.5424] vpn-connection[0x1034590,c936ca4e-d5b8-42dc-bf99-654c1343a601,"XYZ",0]: VPN service disappeared
Jun 01 15:59:03 shyam-ThinkPad-P50 NetworkManager[6287]: <warn>  [1496312943.5431] vpn-connection[0x1034590,c936ca4e-d5b8-42dc-bf99-654c1343a601,"XYZ",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying'
Jun 01 15:59:04 shyam-ThinkPad-P50 charon[7705]: 07[NET] received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
Jun 01 15:59:04 shyam-ThinkPad-P50 charon[7705]: 07[IKE] received retransmit of response with ID 0, but next request already sent
Jun 01 15:59:05 shyam-ThinkPad-P50 charon[7705]: 05[IKE] sending retransmit 2 of request message ID 0, seq 3
Jun 01 15:59:05 shyam-ThinkPad-P50 charon[7705]: 05[NET] sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
Jun 01 15:59:14 shyam-ThinkPad-P50 charon[7705]: 08[NET] received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
Jun 01 15:59:14 shyam-ThinkPad-P50 charon[7705]: 08[IKE] received retransmit of response with ID 0, but next request already sent
Jun 01 15:59:18 shyam-ThinkPad-P50 charon[7705]: 10[IKE] sending retransmit 3 of request message ID 0, seq 3
Jun 01 15:59:18 shyam-ThinkPad-P50 charon[7705]: 10[NET] sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
dkosovic commented 7 years ago

sudo systemctl stop xl2tpd isn't permanent, have you issued sudo systemctl disable xl2tpd to prevent the xl2tpd service from starting at boot time?

But having said that, I can't see anything obviously wrong with your log output.

shyamsathyanathan commented 7 years ago

Yes, I did run sudo systemctl stop xl2tpd before trying to connect to the VPN

dkosovic commented 7 years ago

Could you try running the following, and I expect it should fail :

sudo ipsec restart --conf /var/run/nm-l2tp-ipsec-c936ca4e-d5b8-42dc-bf99-654c1343a601.conf --debug
sleep 3
sudo ipsec up c936ca4e-d5b8-42dc-bf99-654c1343a601

then edit /var/run/nm-l2tp-ipsec-c936ca4e-d5b8-42dc-bf99-654c1343a601.conf and remove the keyingtries=0 line and then try the above again and see if it fails?

shyamsathyanathan commented 7 years ago

It fails in both cases.

The output of sudo ipsec up c936ca4e-d5b8-42dc-bf99-654c1343a601 after removing keyingtries=0:

initiating Main Mode IKE_SA c936ca4e-d5b8-42dc-bf99-654c1343a601[1] to x.x.x.x
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from 192.168.100.21[500] to x.x.x.x[500] (212 bytes)
received packet: from x.x.x.x[500] to 192.168.100.21[500] (132 bytes)
parsed ID_PROT response 0 [ SA V V V ]
received XAuth vendor ID
received NAT-T (RFC 3947) vendor ID
received DPD vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.100.21[500] to x.x.x.x[500] (244 bytes)
received packet: from x.x.x.x[500] to 192.168.100.21[500] (228 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
sending retransmit 1 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
sending retransmit 2 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
sending retransmit 3 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
received packet: from x.x.x.x[4500] to 192.168.100.21[4500] (228 bytes)
received retransmit of response with ID 0, but next request already sent
sending keep alive to x.x.x.x[4500]
sending retransmit 4 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
sending keep alive to x.x.x.x[4500]
sending keep alive to x.x.x.x[4500]
sending retransmit 5 of request message ID 0, seq 3
sending packet: from 192.168.100.21[4500] to x.x.x.x[4500] (68 bytes)
sending keep alive to x.x.x.x[4500]
sending keep alive to x.x.x.x[4500]
sending keep alive to x.x.x.x[4500]
giving up after 5 retransmits
peer not responding, trying again (2/3)
dkosovic commented 7 years ago

I did a Google search for "retransmit 1 of request message ID 0" strongswan and that's where I found a page suggesting to remove keyingtries=0.

I would just be doing Google searches to see if I can find anything else.

dkosovic commented 7 years ago

The following thread has a very similar issue to yours:

After lots of tcpdump analysis, they eventually solved the issue by restarting the VPN server

shyamsathyanathan commented 7 years ago

Hmm.. If that is the case shouldn't this affect everyone on the network?

Making Google searches are hard when you aren't sure what is the expected output and what is not. :D I ended up reading lots of dbus related issues after spending two days of searching for the initial error I got.

dkosovic commented 7 years ago

Instead of using --debug with sudo ipsec restart command-line, you could try --debug-more or --debug-all to see if there is anything useful with more debugging output.

If it is an issue with the VPN server, I would imagine it wouldn't affect existing network connections, just people trying to make new connections. I guess the one way to rule it out is to try connecting from the same network with something else, e.g Windows, Mac, etc.

shyamsathyanathan commented 7 years ago

--debug --debug-more and --debug-all all gives the same output.

Anyway, I have tried accessing it from a Windows 10 VM. It says:

The connection was terminated by the remote computer before it could be completed.
shyamsathyanathan commented 7 years ago

So now I'm not sure if it's a server issue either :/

dkosovic commented 7 years ago

A mis-behaving firewall is also a common culprit, but I guess there could also be other issues. I wish you luck in sorting it out.

shyamsathyanathan commented 7 years ago

I tried it out from another physical Windows installation, and it seems to connect just fine. It's definitely not the server.

mjbradford89 commented 7 years ago

I am also having the same issue on Ubuntu 16.04 GNOME. Though there is no output from the ike-scan.sh script for me.

dkosovic commented 7 years ago

@mjbradford89 I'm pretty sure it is a different issue.

What is the output of runningike-scan by itself? e.g. something like:

sudo ipsec stop
sudo ike-scan -M 123.54.67.9

It might be an IPSec IKEv2 VPN server, try:

sudo ike-scan --ikev2 123.54.67.9

the ike-scan.sh script will also accept the --ikev2 argument, e.g :

sudo ./ike-scan.sh --ikev2 123.54.67.9

If it is IKEv2, you are using the wrong VPN plugin, you'll need to use NetworkManager-strongswan instead.

dkosovic commented 7 years ago

@shyamsathyanathan if you have access to the VPN server, perhaps the logs there might give a hint.

In both the Win10 and Linux cases where it isn't working, it seems like the VPN server stops accepting packets which is why I mentioned a misbehaving firewall is a likely cause.

mjbradford89 commented 7 years ago

@dkosovic Thank you for your reply.

Unfortunately I am certain it is l2tp over IPsec. I'm not sure what changed, but now I am getting an output from sudo ike-scan -M *.*.*.*:

SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

I may be reading it wrong but it seemed to be the same as @shyamsathyanathan, but setting

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

in the advanced IPsec options didn't seem to work for me.

dkosovic commented 7 years ago

@mjbradford89 now that you are getting output from ike-scan it could be a similar issue, but hard to say. I would really need to see the log output to make more of a judgement as to what is going wrong.

You could try an exclamation mark at the end of phase 1 to override the default ciphers and only offer that one, e.g.:

As there are some Cisco Unity VPNs that are pedantic if they receive more ciphers for the proposals.

Also try stoping the xl2tpd service as this VPN plugin starts its own instance of xl2tpd and there could be issues with the initial proposal if UDP port 1701 isn't free due to an exisiting xl2tpd service running.

dkosovic commented 7 years ago

I've reproduced the issue on an Ubuntu VM with ufw (i.e. Uncomplicated Firewall) frontend:

sudo ufw enable
sudo ufw disable
sudo reboot

neither disabling ufw, nor rebooting after disabling ufw fixes the issue, but was working fine before issuing sudo ufw enable, which seems to mimic the symptoms @shyamsathyanathan has. But if ufw isn't involved, I'm still pretty sure it is a firewall of some description causing the issue.

shyamsathyanathan commented 7 years ago

Hey sorry to keep you waiting. I am waiting for the person who is responsible for the VPN to either restart it or send me some logs from there because I don't have access to it. That said, I suspect this is an issue with the server itself, like @dkosovic mentioned previously, as I was able to connect to another VPN with L2TP over IPSec with identical configuration.

dkosovic commented 7 years ago

I'll close this issue to prevent more people posting to it, but will reopen if I get any replies or maybe open up a new issue and maybe refer to this one.

Wish you luck in solving it.

shyamsathyanathan commented 7 years ago

Hey I was able to fix this problem on Windows 10 after setting "Data encryption" to require encryption (disconnect if server declines) in Network Connections -> My connection -> Right Click -> Properties -> Security. Do we have a similar flag on this library?

dkosovic commented 7 years ago

I think it is Use Point-to-Point encryption (MPPE) in PPP options, see:

and also briefly mentioned in:

shyamsathyanathan commented 7 years ago

But when I enable MPPE, the PAP option in the authentication methods list gets unchecked automatically, which is what we use as far as I know. But I tried it anyways and it did not seem to do anything. I seem to get the same error in journalctl -b as before.

dkosovic commented 7 years ago

I may have mislead you about MPPE being the same option as Win10.

According to the following page :

If encryption is required for an L2TP connection, then it is encrypted using IPsec. But you have already enabled IPsec, so not sure what the issue could be.

I think someone added the MPPE option to this VPN plug-in that wanted to use encrypted L2TP connections without IPsec.

dkosovic commented 7 years ago

I've released network-manager-l2tp-1.2.8 PPA package for Ubuntu 16.04, one significant thing I changed was the package dependency from strongswan to strongswan | libreswan (i.e. strongswan or libreswan). I backported the libreswan package from Ubuntu 17.04 (zesty) and made it available in the same PPA:

Could you try updating network-manager-l2tp and network-manager-l2tp-gnome to version 1.2.8, then install libreswan with the following (which will also uninstall strongswan) :

sudo apt install libreswan

Then try the VPN connection again. You can also remove the entries in Phase1 and Phase2 Algorithms text boxes as libreswan hasn't removed the cipher you are using from its defaults.

if you still have issues, try the following to verify your system for possible libreswan IPsec connection issues:

sudo ipsec restart
sudo ipsec verify
shyamsathyanathan commented 7 years ago

Hey! Thank you very much for porting this to libreswan! This seems to be working now.