Does openconnect work for you?
If so you can use this to connect automatically:
sudo openconnect SERVER --no-cert-check -u USERNAME --passwd-on-stdin <PASS_FILE
or
echo PASS | sudo openconnect SERVER --no-cert-check -u USERNAME --passwd-on-stdin
Not sure if people are still interested 6 months after this question was asked, but I think I have a solution. This worked for me on Kubuntu 16.10.
Compiling
As user563731 mentioned, the network-manager-l2tp plugin is not available in the Ubuntu or Debian repositories, and must be compiled from source.
Install the required packages to compile:
sudo apt install git intltool libtool network-manager-dev libnm-util-dev libnm-glib-dev libnm-glib-vpn-dev libnm-gtk-dev libnm-dev libnma-dev ppp-dev libdbus-glib-1-dev libsecret-1-dev libgtk-3-dev libglib2.0-dev xl2tpd strongswan
Download the source code from the network-manager-l2tp GitHub repository and change into the newly created directory:
git clone https://github.com/nm-l2tp/network-manager-l2tp.git
cd network-manager-l2tp
Run the autogen.sh script downloaded from the repository:
./autogen.sh
Configure the compile options as specified for Debian/Ubuntu in the README file:
./configure \
--disable-static --prefix=/usr \
--sysconfdir=/etc --libdir=/usr/lib/x86_64-linux-gnu \
--libexecdir=/usr/lib/NetworkManager \
--localstatedir=/var \
--with-pppd-plugin-dir=/usr/lib/pppd/2.4.7
Compile with make. This may take some time:
make
Copy the produced files to the proper locations. As far as I can tell, only 4 files need to be copied, despite the massive amount the make process created:
cp nm-l2tp-service.name /usr/lib/NetworkManager/VPN/
cp nm-l2tp-service.conf /etc/dbus-1/system.d/
cp src/nm-l2tp-service /usr/lib/NetworkManager/
cp src/.libs/nm-l2tp-pppd-plugin.so /usr/lib/pppd/2.4.7/
Additional workarounds & troubleshooting
I'm only listing the problems I experienced. For additional troubleshooting, make sure to review the links in the "Sources" section below.
AppArmor denies access to charon or stroke
When you connect, you may see errors in /var/log/syslog along the lines of "apparmor DENIED /usr/lib/ipsec/charon" or "reading from socket failed: Permission denied". The workaround for this is to disable AppArmor profiles for charon and stroke:
sudo ln -s /etc/apparmor.d/usr.lib.ipsec.charon /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.lib.ipsec.charon
sudo ln -s /etc/apparmor.d/usr.lib.ipsec.stroke /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.lib.ipsec.stroke
Port 1701 is busy, use ephemeral
This error appearing in /var/log/syslog is indicative of xl2tpd already running. Make sure the daemon isn't running:
systemctl stop xl2tpd
Then disable it to make sure it doesn't start again on the next reboot:
systemctl disable xl2tpd
The network-manager-l2tp plugin likes to start and stop this daemon on demand, so it's best to leave it disabled.
Minor problems that I encountered that I don't have solutions for, but aren't too horrible to live with
- For the duration of the time the VPN is connected, /var/log/syslog is flooded with "xl2tpd: network_thread: unable to find call or tunnel to handle packet." I don't know what this means or how to fix it.
- When the VPN is disconnected, it leaves behind a "ppp0" network interface. When re-connected, it creates a new "ppp1" network interface. It seems to do this indefinitely and does not remove any of them until you reboot.
- Remote DNS servers on the other side of the VPN tunnel are not automatically assigned. I have to manually add my DNS settings to the "IPv4" tab in the connection settings.
Sources
Best Answer
It is a bug of gnome's network manager. It has been reported here and here, so the only solution is to wait until a fix is available or to contribute to fix the bug.