Ubuntu 17.10 connection failing

[0xtf]

Hi,

Following the comments on https://askubuntu.com/questions/977664/l2tp-ipsec-vpn-connection-on-ubuntu-17-10-connection-failed-activation-of-net I was wondering if the packages will né upgraded with the commit that prevents the connection from failing.

In my case, my PSK is >8 chars and I still can’t connect.

Thank you.

[dkosovic]

Are you using Libreswan and getting the "WARNING: using a weak secret (PSK)" warning message 10 times ? If you aren't, that commit won't help at all.

In the code, to check that Libreswan is indeed ready after it has been restarted, the ipsec auto --readycommand is call in a loop of max 10 attempts with a 1 second sleep between attempts. Once Libreswan becomes ready the code jumps out of the loop and continues. Unfortunatelly ipsec auto --ready returns failure when PSK < 8 chars regardless of if Libreswan is ready or not. The code before the commit assumed libreswan wasn't started and exits completely if the loop reached the max 10 attempts.

[dkosovic]

The two main reasons why Ubuntu 17.10 users are having issues not being able to connect to a VPN server with network-manager-l2tp are:

1. The VPN server or firewall might have an issue if the system xl2tpd service isn't stopped, see :

• https://github.com/nm-l2tp/network-manager-l2tp#issue-with-not-stopping-system-xl2tpd-service

2. The VPN server is only proposing weak and old algorithms that strongswan or libreswan now consider to be broken, see:

• https://github.com/nm-l2tp/network-manager-l2tp#vpn-servers-using-ipsec-ikev1-broken-algorithms

For the 2nd case, you probably have a received NO_PROPOSAL_CHOSEN error in the logs.

You can use the ike-scan.sh script on the following page to query the VPN server for the algorithms it is proposing :

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

You can see an example of a workaround for VPN servers using broken algorithms in the README.md file:

• https://github.com/nm-l2tp/network-manager-l2tp#example-workaround-for-3des-sha1-and-modp1024-broken-algorithms

[dkosovic]

I would need to see the journalctl --boot log output and/or the ike-scan.sh output to provide more advice.

[dkosovic]

Forgot to mention, of course if the VPN server is using weak and old algorithms that are now considered broken, it should be reconfigured to propose stronger algorithms.

But if you can't change what the VPN server is proposing, you'll have to use a workaround of setting the phase 1 and 2 algorithms in the IPsec Options dialog box like in the example workaround mentioned above.

[0xtf]

Hi @dkosovic,

I'm gonna go over everything you added and I'll get back to you! Thank you!

[0xtf]

So, do add a bit more to this:

I'm using strongSwan. After querying the server with the script and grepping for SA= I get the following:

SA=(Enc=AES KeyLength=128 Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)

SA=(Enc=AES KeyLength=256 Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)

SA=(Enc=AES KeyLength=256 Hash=SHA1 Group=14:modp2048 Auth=PSK LifeType=Seconds LifeDuration=28800)

I'm not sure on how the phase 1 and 2 entries are filled.

Phase 1: aes256-sha1-modp2048
and
phase 2: aes256-sha1-modp1024

Would you like me to provide additional information @dkosovic ?

Thank you!

[0xtf]

Just to add that, by using those configurations, I was able to connect.

[dkosovic]

Glad to hear you got the connection working.

I'm going to redo parts of the README.md file and known issues wiki to make it clearer as to what needs to be done in situations like this.