Skip to content

Known Issues

Jump to bottom
Douglas Kosovic edited this page Apr 28, 2021 · 96 revisions

IPsec IKEv1 Algorithms

Compatibility with VPN servers using weak legacy IPsec IKEv1 algorithms

NetworkManager-l2tp versions 1.2.6 to 1.2.14 use the Libreswan or strongSwan default set of allowed algorithms for phase 1 (Main Mode) and phase 2 (Quick Mode) proposal negotiations. This means VPN servers that are using only legacy ciphers that strongSwan or Libreswan now consider broken will result in a failed connection, unless user specified algorithms to supplement or override the default set of algorithms are used for phase 1 and 2 in the IPsec config dialog box.

For backwards compatibility with most L2TP/IPsec VPN servers out there, NetworkManager-l2tp 1.2.16 and later no longer use the strongSwan and libreswan default set of allowed algorithms, instead algorithms that are a merge of Windows 10 and macOS/iOS/iPadOS L2TP/IPsec clients' IKEv1 proposals are used instead for the default. The weakest proposals that were not common to both Win10 and iOS were dropped, but all of the strongest ones were kept. So it should no longer be necessary to fill in the phase 1 and 2 algorithms in the IPsec Options dialog box.

See IPsec IKEv1 weak legacy algorithms and backwards compatibility in NetworkManager-l2tp's README.md file for more details.

Querying VPN server for its IKEv1 algorithm proposals

Install the ike-scan package which most Linux distributions provide and then run the following script (with further details on how below the script) :

#!/bin/sh

# Encryption algorithms: 3des=5, aes128=7/128, aes192=7/192, aes256=7/256
ENCLIST="5 7/128 7/192 7/256"
# Hash algorithms: md5=1, sha1=2, sha256=5, sha384=6, sha512=7
HASHLIST="1 2 5 6 7"
# Diffie-Hellman groups: 1, 2, 5, 14, 15, 19, 20, 21
GROUPLIST="1 2 5 14 15 19 20 21"
# Authentication method: Preshared Key=1, RSA signatures=3
AUTHLIST="1 3"

for ENC in $ENCLIST; do
   for HASH in $HASHLIST; do
       for GROUP in $GROUPLIST; do
          for AUTH in $AUTHLIST; do
             echo ike-scan --trans=$ENC,$HASH,$AUTH,$GROUP -M "$@"
             ike-scan --trans=$ENC,$HASH,$AUTH,$GROUP -M "$@"
          done
      done
   done
done

Let's assume the above script has been copied and pasted to a file called ike-scan.sh. To run the script, issue something like the following on the command-line. Note: ike-scan needs UDP port 500 to be free, this can be achieved by stopping any running IPsec service (e.g. sudo ipsec stop). Replace 123.54.76.9 in the below with your VPN server and we'll grep for SA (i.e. IPSec Security Association) which is the main thing we are interested in.

sudo ipsec stop
chmod a+rx ./ike-scan.sh
sudo ./ike-scan.sh 123.54.76.9 | grep SA=

It may take a few minutes for the script to run to completion and the output shall look something like:

  SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
  SA=(Enc=AES Hash=SHA1 Auth=PSK Group=14:modp2048 KeyLength=128 LifeType=Seconds LifeDuration(4)=0x00007080

From the above example script output, it would mean the following phase 1 algorithms options could be set in the IPsec dialog box advanced options:

  • Phase1 Algorithms: aes128-sha1-modp2048,3des-sha1-modp1024

For phase 2 algorithms, it is recommended to use the following which are what Windows 10 and iOS use for phase 2:

  • Phase2 Algorithms: aes256-sha1,aes128-sha1,3des-sha1

Overriding and not just supplementing the default cipher

For strongSwan, but not Libreswan, in some cases you may need to put an exclamation mark (!) at the end of the phase 1 or 2 settings to override and not just supplement the default ciphers. For example, some Cisco Unity VPN servers may require:

  • Phase1 Algorithms: aes128-sha1-modp1024,3des-sha1-modp1024!
  • Phase2 Algorithms: aes128-sha1,3des-md5!

"Layer 2 Tunneling Protocol (L2TP)" not showing up

After installing NetworkManager-l2tp from either the source code or a prebuilt binary package, if "Layer 2 Tunnelling Protocol (L2TP)" does not show up when trying to add a VPN connection, try one of the following:

  • sudo systemctl restart NetworkManager
  • sudo service network-manager restart
  • logout/#
  • reboot

Unable to save password

Logout/# or reboot if the saved password isn't being remembered and you are seeing something like the following in the journalctl output, :

gnome-shell[2143]: JS LOG: Invalid VPN service type (cannot find authentication binary)
...  NetworkManager[1234]: <error> ... vpn-connection...: Failed to request VPN secrets #3: No agents were available for this request.

This bug has been fixed with newer gnome-shell versions see GNOME bug# 773893 and Fedora gnome-shell bug# 1389107

Unable to create or edit a L2TP VPN connection

Unless you are using KDE (Plasma-nm) or the command-line (/usr/bin/nmcli), you will be using a GNOME based NetworkManager connection editor to create or edit VPN connections.

If you are using pre-build binary packages, please ensure you have installed the NetworkManager-l2tp-gnome or network-manager-l2tp-gnome package which provides the necessary files for use with a GNOME based NetworkManager connection editor, otherwise you may see a variation of the following error :

Could not load editor VPN plugin for 'org.freedesktop.NetworkManager.l2tp'
(missing plugin file "/usr/lib64/NetworkManager/libnm-vpn-plugin-l2tp-editor.so").

strongSwan no acceptable traffic selectors found

If you are using strongSwan and see no acceptable traffic selectors found error in the journalctl output (or elsewhere), then you are having IKEv1 Cisco Unity Extension issues caused by the strongSwan unity plugin.

Chromebooks use strongSwan for L2TP/IPsec, extract from chromium bug# 707139 which is also applicable to most Linux distributions :

Disable USE flag for strongSwan unity plugin

During the strongSwan 5.5.0 upgrade, the unity plugin got enabled because it is on by default in new strongSwan builds. But this plugin has a known issue that breaks transport mode, resulting in a regression when interoperating with certain VPN gateways. Disable the unity plugin until this is fixed. We never need Split-Include for transport mode anyway, and we do not currently support tunnel mode.

Rather than rebuilding strongSwan without the unity plugin, a workaround to disable the unity plugin is to edit the /etc/strongswan.d/charon.conf file to uncomment the # cisco_unity = no line like so:

# Send Cisco Unity vendor ID payload (IKEv1 only).
cisco_unity = no

and create or modify /etc/strongswan.d/charon/unity.conf so that it contains:

unity {

    # Whether to load the plugin. Can also be an integer to increase the
    # priority of this plugin.
    load = no

}

Libreswan algorithm 'modp1024' is not supported error

Extract from libreseswan-3.30 changes:

  • pluto: Disable support for DH2/modp1024 at compile time [Paul]

Extract from libreswan mailing list regarding DH2/modp1024 :

If you really want you can enable it at compile time with USE_DH2=true

But everything that supports DH2 also supports DH5. We are pretty sure nationstates can successfully attack DH2. You really cannot expect to use crypto parameters that were already not the most secure TWENTY years ago to still keep working unmodified.

With NetworkManager-l2tp 1.2.18 and >= 1.8.2, modp1024 was removed from the default phase 1 algorithms when Libreswan is detected. With these versions of the NetworkManager-l2tp source code, the --enable-libreswan-dh2 configure switch can be used for older versions of Libreswan or versions of Libreswan built with USE_DH2=true.

Issue with blacklisting of L2TP kernel modules

For compatibility with Microsoft L2TP servers (and with later kernel updates, other L2TP servers), L2TP kernel modules are required.

If you see the following error message, then chances are that the l2tp_ppp and l2tp_netlink kernel modules are blacklisted :

xl2tpd[1234]: L2TP kernel support not detected (try modprobing l2tp_ppp and pppol2tp)

modprobe l2tp_ppp (or modprobe pppol2tp for older kernels) can be used as a temporary workaround instead of removing the blacklistings as described below.

The following is an extract from "Enhanced security of auto-loading kernel modules in RHEL 8 " page :

To enhance Red Hat Enterprise Linux against possible future security vulnerabilities in lesser-known components which system administrators typically do not protect against, a set of kernel modules have been moved to the kernel-modules-extra package so they are not installed by default, and blacklisted by default so those components cannot be loaded by non-root users.

When a system requires use of one of these kernel modules, the system administrator must install the kernel-modules-extra package and explicitly remove the module blacklist.

Although the above was for RHEL8, it is also applicable to Fedora >= 31, CentOS 8 and other derivatives.

Note that on Fedora, RHEL and other derivatives, the kernel-modules-extra package shouldn't need to be explicitly installed as the xl2tpd package has a package dependency on it.

The /etc/modprobe.d/l2tp_netlink-blacklist.conf file contains:

# Remove the blacklist by adding a comment # at the start of the line.
blacklist l2tp_netlink

The /etc/modprobe.d/l2tp_ppp-blacklist.conf file contains :

# Remove the blacklist by adding a comment # at the start of the line.
blacklist l2tp_ppp

To remove the blacklist of the L2TP modules by adding a # comment to the blacklist lines can be achieved with:

sudo sed -e '/blacklist l2tp_netlink/s/^b/#b/g' -i /etc/modprobe.d/l2tp_netlink-blacklist.conf
sudo sed -e '/blacklist l2tp_ppp/s/^b/#b/g' -i /etc/modprobe.d/l2tp_ppp-blacklist.conf

Issue with not stopping system xl2tpd service

NetworkManager-l2tp starts its own instance of an xl2tpd process and if the system xl2tpd service is running, its own xl2tpd instance won't be able to use UDP port 1701, so will use an ephemeral port (i.e. random high port).

Although the use of an ephemeral port is described in "Securing L2TP using IPsec" RFC3193 written by Microsoft and Cisco, there are some L2TP/IPsec servers and/or firewalls that will have issues with the use of an ephemeral port.

Stopping the system xl2tpd service should free UDP port 1701 and on systemd based Linux distributions, the xl2tpd service can be stopped with the following:

sudo systemctl stop xl2tpd

If stopping the xl2tpd service fixes your VPN connection issue, you can disable the xl2tpd service from starting at boot time with :

sudo systemctl disable xl2tpd

Orphaned pppd process

With xl2tpd ≤ 1.3.6 (and in particular Linux distributions' xl2tpd packages that don't have xl2tpd commit# a193e02 backported which fixes a NULL-pointer deference bug), a pppd process will be left behind when tearing down a VPN connection because the parent xl2tpd process crashes before it has a chance at reaping the child pppd process.

Ubuntu 16.04 and 16.10 have updated xl2tpd 1.3.6 packages that contains the fix (Ubuntu bug# 1677990).

EAP: peer reports authentication failure

If you see EAP: peer reports authentication failure in the journalctl output (or elsewhere), then in the VPN connection's PPP Settings dialog box, untick EAP in the authentication methods list. In some situations, the Use Point-to-Point encryption (MPPE) checkbox may also need to be ticked.

DNS resolution issues

DNS not working after disconnecting

On Ubuntu 18.04 (and derivatives), if after the VPN connection is disconnected DNS stops resolving (due to /run/systemd/resolve/stub-resolv.conf becoming readable only by root), install the resolvconf package :

sudo apt install resolvconf

See Ubuntu bug LP#1778946.

.local hostname resolution

There are unfortunately many Microsoft Windows networks that still use .local for internal hostnames that are resolved using unicast DNS even though Microsoft no longer recommends using .local. The use of unicast DNS for resolving .local has fallen into disfavor as mobile devices, printers and other devices supporting Zeroconf (aka Bonjour) have become increasingly common and they use multicast DNS (mDNS) for resolving hostnames ending in .local.

In /etc/nsswitch.conf most Linux distributions put mdns4_minimal ahead of dns in the hosts: line which often looks something like:

hosts:    files mdns4_minimal [NOTFOUND=return] dns

With the above nsswitch.conf hosts configuration, .local hostname resolution will return NOTFOUND if the hostname can not be found in mDNS.

If you must VPN to a network using .local with unicast DNS and not too concerned about potential Zeroconf performance issues, one workaround is to move dns before mdns4_minimal in the hosts: line.

NetworkManager ≤ 1.6.2 and Systemd-resolved ignoring VPN server's DNS

NetworkManager 1.6 introduced support for the systemd-resolved local DNS forwarder backend. Some Linux distributions have switched from DNSMasq to Systemd-resolved for DNS. Unfortunately with NetworkManager ≤ 1.6.2 because the ppp interfaces isn't "managed" by NetworkManager the VPN server's DNS configuration is being ignored as described in GNOME bug# 779087.

A workaround is to rollback to using DNSMasq:

  1. Edit /etc/NetworkManager/NetworkManager.conf and add the following line under the [main] section:
dns=dnsmasq
  1. Backup the Systemd resolv.conf file (NetworkManager should create a new one):
sudo mv /etc/resolv.conf /etc/resolv.conf.systemd
  1. Disable and stop the systemd-resolved service:
sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
  1. Restart network-manager
sudo systemctl restart NetworkManager

Ubuntu AppArmor issue with strongSwan

For Ubuntu versions < 16.04, strongSwan's charon and stroke daemons are prevented from performing correctly as child processes under NetworkManager-l2tp due to an AppArmor name space issue involving NetworkManager and the AppArmor profiles for charon and stroke. The simplest workaround is to disable the charon and stroke AppArmor profiles :

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

With Ubuntu 16.04 (Xenial Xerus), the issue is fixed by upgrading to strongswan 5.3.5-1ubuntu3.1 (or later).

With Ubuntu 16.10 (Yakkety Yak), the issue is fixed by upgrading to strongswan 5.3.5-1ubuntu4.1 (or later).

With Ubuntu 17.04 and later, there is no strongSwan AppArmor issue.

openSUSE and SUSE Linux Enterprise Server

For NetworkManager-l2tp to work, please ensure the Wicked service is disabled and NetworkManager service enable:

sudo systemctl stop wicked
sudo systemctl disable wicked
sudo systemctl enable NetworkManager
sudo systemctl start NetworkManager
Clone this wiki locally