L2TP / IPSec failing to connect (Kubuntu 17.10)

Solution 1:

After spending a few hours digging around, I found out what the problem is, and the solution.

The problem:

1. Linux no longer supports the 3DES cipher, but many appliances still use it.
2. Kubuntu 17.10 is missing phase1 and phase2 algorithm entry fields under IPSec Settings (this is a known bug), which are needed to setup an L2TP/IPSec connection to use 3DES.

The solution:

1. Install the latest version of KDE Plasma from the "backports" PPA.
2. Reboot, then create a new L2TP/IPSec VPN connection - phase1 and phase2 algorithm entry fields should now be present.
3. For the Phase1 Algorithm, enter: 3des-sha1-modp1024!
4. For the Phase2 Algorithm, enter: 3des-sha1!

From memory, I did the following:

sudo add-apt-repository ppa:kubuntu-ppa/backports
sudo apt update && sudo apt upgrade
sudo reboot
sudo apt install network-manager-l2tp-gnome
sudo apt install strongswan
sudo apt install libstrongswan-extra-plugins
sudo apt install libcharon-extra-plugins

Reboot, then add L2TP/IPSec as normal. You should now see the Phase1 and Phase2 algorithm textboxes as show in the attached image.

It's important to note that the above steps will not work if you have installed the latest Linux kernel (4.14 or higher, I believe), so it is highly likely that this workaround to get L2TP/IPSec working with the 3DES cipher will not work when the up and coming *Ubuntu 18.04 LTS is released.

Solution 2:

I know that this question was in regards to getting L2TP/IPSec working on Kubuntu 17.10. However, 18.04 is out now, and here's how I get L2TP/IPSec working on Kubuntu 18.04:

1. $ sudo apt install network-manager-l2tp
2. $ sudo systemctl stop xl2tpd.service
3. $ sudo systemctl disable xl2tpd.service

Messing around with backports is not longer required as the Phase1 algorithms and Phase2 algorithms text-inputs are now included in the default Network Manager.

Solution 3:

You can use ike-scan (option --nat-t for NAT traversal) to ask the VPN server if you need those options:

sudo ike-scan vpn.myserver.org
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
52.x.x.x    Main Mode Handshake returned HDR=(CKY-R=aa91011bd9b543f7) SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)

Ending ike-scan 1.9: 1 hosts scanned in 0.064 seconds (15.54 hosts/sec).  1 returned handshake; 0 returned notify

The outputs Enc=3DES and Hash=SHA1 and Group=2:modp1024 gives you a hint if you need to adjust the phase algorithms. Note: My network-manager settings has a button which adds Legacy Proposals for both Phase1 and Phase2 Algorithms:

• Phase1 Algorithms: aes256-sha1-ecp384,aes128-sha1-ecp256,3des-sha1-modp1024!
• Phase2 Algorithms: aes256-sha1,aes128-sha1,3des-sha1!

Pick those values you find in the output of ike-scan.

Solution 4:

The kernel 4.14 bug is related to the following commit :

• https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/net/xfrm?h=v4.14.8&id=c9f3f813d462c72dbe412cee6a5cbacf13c4ad5e

That kernel 4.14 commit breaks IPsec transportation mode when a wildcard address is used on the client side as is the case with network-manager-l2tp. The commit was reverted in kernel-4.15-rc1 :

• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/xfrm?h=v4.15-rc1&id=94802151894d482e82c324edf2c658f8e6b96508

Unfortunately the reversion commit reintroduces a stack out-of-bounds bug. We might need to wait for the kernel 4.14 branch to get a fix after kernel 4.15 is released. More details in this netdev linux kernel mailing list thread :

• https://patchwork.ozlabs.org/patch/838470/