NetworkManager » History » Version 44
NetworkManager allows configuration and control of VPN daemons through a plugin interface. We provide such a plugin for NetworkManager to configure road warrior clients for the most common setups. The plugin currently supports connections using the IKEv2 protocol only.
NetworkManager uses DBUS to communicate with a special build of the charon IKE daemon (charon-nm). Before 5.0.0 NetworkManager communicated with a plugin in regular charon, which was prone to conflicts.
The plugin uses a certificate for gateway authentication and supports EAP and RSA authentication for client authentication. PSK is supported starting with NetworkManager-strongswan-1.3.1, but strong secrets are enforced.
You can use any password based EAP method supported by strongSwan (MD5/GTC/MSCHAPv2) or private key authentication. Private keys are either stored in a file or accessed through your ready-to-use ssh-agent. You'll need a certificate matching that key. Starting with strongSwan 4.5.0 / NetworkManager-strongswan 1.2.0, private keys and certificates on a smartcard can be used.
If you configure the gateway certificate directly on the clients, there are no requirements to the certificate. If you deploy CA certificates (supported since 4.3.1), the gateway certificate will need a subjectAltName including the host name of the gateway (the same you enter in the clients configuration). Starting with version 4.3.5, you can also use preinstalled root CA certificates of your distribution, using the
--with-nm-ca-dir configure option. Since 5.5.1 this can also be modified with the charon-nm.ca_dir setting. Just don't specify any gateway/CA certificate to use preinstalled root certificates. CA certificates on a smartcard are automatically used.
- Versions before 5.0.3 don't work well together with some versions of NetworkManager (see #294). Please check the IP addresses of the loopback interface when encountering network problems after/during the connection. To restore:
ip addr flush dev lo
ip addr add 127.0.0.1/8 dev lo
- restore your default gateway
- Versions before NetworkManager-strongswan 1.4.0 / strongSwan 5.5.1 don't work with NetworkManager 1.2 and newer (some patches may be applied to older strongSwan releases to use the updated NM plugin, refer to our Download page for details).
The original strongSwan NM plugin and the NetworkManager VPN module were based on the NetworkManager 0.9 interface. Version 1.4.0 of the plugin updated parts of it to the NetworkManager 1.2 interface (mostly related to the GUI, the plugin in charon-nm is largely unchanged). It should work out-of-the-box with the latest packages of your favorite Linux distribution.
Your distribution may provide a package (e.g. network-manager-strongswan on Debian/Ubuntu).
Otherwise, you have to build strongSwan from source.
Building from source¶
To build from source you additionally need the NetworkManager headers for the strongSwan NM backend:
apt-get install libssl-dev network-manager-dev libnm-glib-vpn-dev libnm-gtk-dev libnma-dev libgtk-3-dev libsecret-1-dev gnome-common
NM integration works only for IKEv2. Since on a desktop we have OpenSSL installed anyway, we are going to use libcrypto for all cryptographic operations.
--enable-agent builds the ssh-agent private key plugin, EAP plugins are enabled using
--enable-eap-gtc --enable-eap-md5 --enable-eap-mschapv2. For Smartcard support,
--enable-pkcs11. You may omit options you don't need.
# get the strongSwan tarball wget http://download.strongswan.org/strongswan-5.x.x.tar.bz2 tar xjf strongswan-5.x.x.tar.bz2 cd strongswan-5.x.x # build charon with OpenSSL/NM Plugin ./configure --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib \ --disable-aes --disable-des --disable-md5 --disable-sha1 --disable-sha2 \ --disable-fips-prf --disable-gmp --enable-openssl --enable-nm --enable-agent \ --enable-eap-gtc --enable-eap-md5 --enable-eap-mschapv2 --enable-eap-identity make make install # get the NetworkManager strongsSwan plugin as a tarball wget http://download.strongswan.org/NetworkManager/NetworkManager-strongswan-1.x.x.tar.bz2 tar xjf NetworkManager-strongswan-1.x.x.tar.bz2 cd NetworkManager-strongswan-1.x.x # build the NetworkManager strongsSwan plugin (if you changed prefix/libexecdir above, set --with-charon=/path/to/charon-nm) ./configure --sysconfdir=/etc --prefix=/usr make make install
- Click on nm-applet -> VPN Connections -> Configure VPN...
- Add -> Ipsec/IKEv2 (strongswan) -> Create ...
- Configure your client
- Click on nm-applet -> VPN Connections -> Your Connection
- Enter password
As you can see, there is no subnet configuration for the tunnel. We let the gateway administration choose the subnet; the client always proposes 0.0.0.0/0 for the remote network and the gateway narrows that down to the configured subnet.
If you use Certificate/private_key authentication, please store your certificate and private key in separate files.
Smart card requirements¶
The use of smart cards should be as simple as possible to the end user, which brings some restrictions. For instance, the daemon automatically selects the first certificate with a private key on any token in any slot.
First, you'll need to specify the PKCS#11 module in strongswan.conf. Please refer to the general description of smart card support with IKEv2 for details on how to do so.
You may define multiple modules, the daemon looks for the first certificate/private key in the specified module order.The daemon uses the following mechanism to find a private key:
- enumerate all certificates which have the TLS Client Auth Extended Key usage, but no CA constraint
- for each certificate:
- extract the subjectKeyIdentifier
- enumerate all modules with all tokens
- for each token:
- look for a public key having the certificates subjectKeyIdentifier as ID
- if not found, enumerate all public keys and look for a certificate with a matching subjectKeyIdentifier and use its ID
- if found, log in to the smartcard using the supplied PIN
- if logged in, load the associated private key
In short, the private key on the token must have a public key readable without login, and both objects must have a matching ID. Before 5.5.1 both objects had to have an ID matching the certificates subjectKeyIdentifier (or the hash of the subjectPublicKey field of the public key).
The certificate needs the TLS CLient Auth Extended Key usage flag.
The daemon uses the first subjectAltName of the selected certificate as IKEv2 identity, or uses the full DN if none found.
Depending on the used authentication methods, you can use gateway configurations very similar to Windows 7 (Certificate/MSCHAPv2), or use EAP-GTC and the PAM XAuth backend to authenticate against PAM.