WireGuard in NetworkManager

WireGuard in NetworkManager

NetworkManager 1.16 got native support for WireGuard VPN tunnels (NEWS). WireGuard is a novel VPN tunnel protocol and implementation that spawned a lot of interest. Here I will not explain how WireGuard itself works. You can find very good documentation and introduction at wireguard.com.

Having support in NetworkManager is great for two main reasons:

  • NetworkManager provides a de facto standard API for configuring networking on the host. This allows different tools to integrate and interoperate — from cli, tui, GUI, to cockpit. All these different components may now make use of the API also for configuring WireGuard. One advantage for the end user is that a GUI for WireGuard is now within reach.
  • By configuring WireGuard with NetworkManager you get other features beyond the plain WireGuard tunnel setup. Most notably you get DNS and firewalld setup in a consistent manner.
For Alice it is now easy to configure WireGuard with NetworkManager.

NetworkManager’s support for WireGuard requires the kernel module for Linux. As of March 2019, it is not yet upstream in mainline kernel but easy to install on most distributions.

Import an existing WireGuard profile

The WireGuard project provides a wg-quick tool to setup WireGuard tunnels. If you are using WireGuard already, chances are that you use this tool. In that case you would have a configuration file and issue wg-quick up. Here is the example configuration file from wg-quick’s manual page:

Address =
Address =
SaveConfig = true
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs =,

PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
AllowedIPs =,

PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs =

Let’s import this into NetworkManager:

$ CONF_FILE="wg0.conf"
$ nmcli connection import type wireguard file "$CONF_FILE"
Connection 'wg0' (125d4b76-d230-47b0-9c31-bb7b9ebca861) successfully added.

Note that the PreUp, PostUp, PreDown, and PostDown keys are ignored during import.

You may delete the profile again with

$ nmcli connection delete wg0
Connection 'wg0' (125d4b76-d230-47b0-9c31-bb7b9ebca861) successfully deleted.

About Connection Profiles

Note that wg-quick up wg0.conf does something fundamentally different from what nmcli connection import does. When you run wg-quick up, it reads the file, configures the WireGuard tunnel, sets up addresses and routes, and exits.

This is not what “connection import” does. NetworkManager is profile based. That means you create profiles instead of issuing ad-hoc commands that configure ephemeral settings (like ip address add, wg set, or wg-quick up). NetworkManager calls these profiles “connections”. Configuring something in NetworkManager usually boils down to create a suitable profile and “activate” it for the settings to take effect.

nmcli connection import is just one way to create a profile. Note that the imported profile is configured to autoconnect, so quite possibly the profile gets activated right away. But regardless of that, think of “import” creating just a profile. You would only do this step once, but afterwards activate the profile many times.

There is no difference to NetworkManager how the profile was created. You could also create a WireGuard profile from scratch.

$ nmcli connection add type wireguard ifname wg0 con-name my-wg0
Connection 'my-wg0' (0d2aed05-2c7f-40ec-81ad-b1b4edd898fc) successfully added.

And let’s look at the profile:

$ nmcli --show-secrets connection show my-wg0
connection.id:                       my-wg0
connection.uuid:                     0d2aed05-2c7f-40ec-81ad-b1b4edd898fc
connection.stable-id:                --
connection.type:                     wireguard
connection.interface-name:           wg0
connection.autoconnect:              yes
ipv4.method:                         disabled
ipv6.method:                         ignore
wireguard.private-key:               --
wireguard.private-key-flags:         0 (none)
wireguard.listen-port:               0
wireguard.fwmark:                    0x0
wireguard.peer-routes:               yes
wireguard.mtu:                       0

and finally let’s activate it. Note you will be asked to enter the private key that you may generate with wg genkey:

$ nmcli --show-secrets --ask connection up my-wg0
Secrets are required to connect WireGuard VPN 'my-wg0'
WireGuard private-key (wireguard.private-key): eD8wqjLABmg6ClC+6egB/dnMLbbUYSMMrDsrHUwmQlI=
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/30)

Confirm that the VPN tunnel is now up:

$ nmcli
wg0: connected to my-wg0
        wireguard, sw, mtu 1420
        inet6 fe80::720b:6576:1650:d26/64
        route6 ff00::/8
        route6 fe80::/64
$ ip link show wg0
34: wg0:  mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
$ sudo WG_HIDE_KEYS=never wg
interface: wg0
  public key: SymChsQwTX5yZrtwtsWpYfHLMgnJpOJ25YOfs7/ImT0=
  private key: eD8wqjLABmg6ClC+6egB/dnMLbbUYSMMrDsrHUwmQlI=
  listening port: 56389

Note that above wireguard.private-key-flags are set to 0. The secret flags determine whether the secret is not-required, to be stored to disk or a keyring, or always asked. In this case, the private key got stored to disk in /etc/NetworkManager/system-connections/.

This connection isn’t right yet. Let’s adjust it:

$ nmcli connection modify my-wg0 \
    autoconnect yes \
    ipv4.method manual \
    ipv4.addresses \
    wireguard.listen-port 50000 \

Check the manual for available NetworkManager settings in the profile. Compare what you configured until the profile is to your liking:

$ nmcli --overview connection show my-wg0
connection.id:                          my-wg0
connection.uuid:                        0d2aed05-2c7f-40ec-81ad-b1b4edd898fc
connection.type:                        wireguard
connection.interface-name:              wg0
connection.timestamp:                   1551171032
ipv4.method:                            manual
ipv6.method:                            ignore
wireguard.private-key-flags:            0 (none)
wireguard.listen-port:                  50000
GENERAL.NAME:                           my-wg0
GENERAL.UUID:                           0d2aed05-2c7f-40ec-81ad-b1b4edd898fc
GENERAL.DEVICES:                        wg0
GENERAL.STATE:                          activated
GENERAL.DEFAULT:                        no
GENERAL.DEFAULT6:                       no
GENERAL.SPEC-OBJECT:                    --
GENERAL.VPN:                            no
GENERAL.DBUS-PATH:                      /org/freedesktop/NetworkManager/ActiveConnection/30
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/Settings/60
GENERAL.ZONE:                           --
GENERAL.MASTER-PATH:                    --
IP6.ADDRESS[1]:                         fe80::720b:6576:1650:d26/64
IP6.ROUTE[1]:                           dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE[2]:                           dst = fe80::/64, nh = ::, mt = 256

Note that above output also shows the current device information with upper-cased properties. This is because the profile is currently activated. As you modify the profile, you’ll note that the changes don’t take effect immediately. For that you have to (re-) activate the profile with

$ nmcli connection up my-wg0

Note that this time we don’t need to provide the private key. The key was stored to disk according to the secret flags. This will allow the profile to automatically connect in the future upon boot.

Configuring Peers

As of now, nmcli does not yet support configuring peers. This is a missing feature. Until this is implemented you have the following possibilities, which are all a bit inconvenient.

1.) Import Peers from a wg-quick configuration file

See above. This does not allow you to modify an existing profile, as nmcli connection import always creates a new profile.

2.) Use the Python Example Script nm-wg-set

There is a python example script. It uses pygobject with libnm and accepts similar parameters as wg set. I mention this example script to give you an idea how you could use NetworkManager from python (in this case based on libnm and pygobject).

$ python nm-wg-set my-wg0 \
    fwmark 0x500 \
    peer llG3xkDWcEP4KODf45zjntuvUX0oXieRyxXdl5POYX4= \
    endpoint my-wg.example.com:4001 \
    allowed-ips \
    persistent-keepalive 120 \
    peer 2Gl0SATbfrrzxfrSkhNoRR9Jg56y533y07KtIVngAk0= \
    preshared-key \
      <(echo qoNbN/6ABe4wWyz4jh+uwX7vqRpNeGEtgAnUbwNjEug=) \
    preshared-key-flags 0 \
$ WG_HIDE_KEYS=never python nm-wg-set my-wg0 
interface:                    wg0
uuid:                         0d2aed05-2c7f-40ec-81ad-b1b4edd898fc
id:                           my-wg0
private-key:                  eD8wqjLABmg6ClC+6egB/dnMLbbUYSMMrDsrHUwmQlI=
private-key-flags:            0 (none)
listen-port:                  50000
fwmark:                       0x500
peer[0].public-key:           llG3xkDWcEP4KODf45zjntuvUX0oXieRyxXdl5POYX4=
peer[0].preshared-key-flags:  4 (not-required)
peer[0].endpoint:             my-wg.example.com:4001
peer[0].persistent-keepalive: 120
peer[1].public-key:           2Gl0SATbfrrzxfrSkhNoRR9Jg56y533y07KtIVngAk0=
peer[1].preshared-key:        qoNbN/6ABe4wWyz4jh+uwX7vqRpNeGEtgAnUbwNjEug=
peer[1].preshared-key-flags:  0 (none)
peer[1].persistent-keepalive: 0

3.) Use libnm directly

libnm is the client library for NetworkManager. It gained API for fully configuring WireGuard profiles. This is what the nm-wg-set example script above uses.

4.) Use D-Bus directly

NetworkManager’s D-Bus API is what all clients use — from libnm, nmcli to GUIs. NetworkManager is really all about the (D-Bus) API that it provides. Everything that a tool does with NetworkManager will always be possible by using D-Bus directly. When NetworkManager 1.16 introduces WireGuard support, then the tools are still lacking, but the API is ready for implementing them.

5.) Edit the Profile on Disk

NetworkManager persists WireGuard profiles in the keyfile format. These are files under /etc/NetworkManager/system-connections and it is always fully supported that you just edit these files by hand. This is the other, file-base API of NetworkManager beside D-Bus. This leaves you with the problem to know what to edit there exactly. Let’s look at what we got so far:

$ sudo cat \






The WireGuard peer settings should be pretty straight forward. See also NetworkManager’s keyfile documentation. Edit the file and issue sudo nmcli connection reload or sudo nmcli connection load /etc/NetworkManager/system-connection/my-wg0.nmconnection. This causes NetworkManager to update the profile with the changes from disk.

Finally, reactivate the profile and check the result:

$ nmcli connection up my-wg0 
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/31)
$ sudo WG_HIDE_KEYS=never wg
interface: wg0
  public key: SymChsQwTX5yZrtwtsWpYfHLMgnJpOJ25YOfs7/ImT0=
  private key: eD8wqjLABmg6ClC+6egB/dnMLbbUYSMMrDsrHUwmQlI=
  listening port: 50000
  fwmark: 0x500

peer: llG3xkDWcEP4KODf45zjntuvUX0oXieRyxXdl5POYX4=
  allowed ips:
  persistent keepalive: every 2 minutes

peer: 2Gl0SATbfrrzxfrSkhNoRR9Jg56y533y07KtIVngAk0=
  preshared key: qoNbN/6ABe4wWyz4jh+uwX7vqRpNeGEtgAnUbwNjEug=
  allowed ips: (none)

Reapply and Runtime Configuration

We said that after modifying a profile we have to fully reactivate the profile for the changes to take effect. That’s not the only way. NetworkManager supports nmcli device reapply wg0 which makes changes to the profile effective without doing a full re-activation cycle. That is less disruptive as the interface does not go down. Likewise, nmcli device modify wg0 allows you to change only the runtime configuration, without modifying the profile. It is fully supported to modify WireGuard settings of an active tunnel via reapply.

Dynamically Resolving Endpoints

In WireGuard, peers may have an endpoint configured but also roaming is built-in. NetworkManager supports peer endpoints specified as DNS names: it will resolve the names before configuring the IP address in kernel. NetworkManager resolves endpoint names every 30 minutes or whenever the DNS configuration of the host changes, in order to pick up changes to the endpoint’s IP address.


In the NetworkManager profile you can configure wireguard.mtu for the MTU. In absence of an explicit configuration, the default is used. That is different from wg-quick up, which tries to autodetect the MTU by looking at how to reach all peers. NetworkManager does not do such automatism.

Peer Routes, AllowedIPs and Cryptokey Routing

In WireGuard you need to configure the “AllowedIPs” ranges for the peers. This is what WireGuard calls Cryptokey Routing. It also implies, that you usually configure direct routes for these “AllowedIPs” ranges via the WireGuard tunnel. NetworkManager will add those routes automatically if wireguard.peer-routes option of the profile is enabled (which it is by default).

Routing All Your Traffic

When routing all traffic via the WireGuard tunnel, then peer endpoints must be still reached outside the tunnel.

For other VPN plugins NetworkManager adds a direct route to the external VPN gateway on the device that has the default route. That works well in most cases, but is an ugly hack because NetworkManager doesn’t reliably know the correct direct route in unusual scenarios.

NetworkManager currently does not provide any additional automatism to help you with that. As workaround you could manually add an explicit route to the profile of the device via which the endpoint is reachable:

$ nmcli connection modify eth0 \
    +ipv4.routes "$WG_ENDPOINT_ADDR/32"

An alternative solution is to configure policy routing. The wg-quick tool does this with the Table=auto setting (which is the default).

NetworkManager supports configuring routes in other routing tables than the “main” table. Hence, using policy-routing works in parts by configuring "ipv4.route-table" and "ipv6.route-table". The problem is that currently NetworkManager does not support configuring the routing policy rules themselves. For now, the rules must be configured outside of NetworkManager. You could do so via a dispatcher script in /etc/NetworkManager/dispatcher.d, but yes, this is lacking. See the NetworkManager manual about dispatcher scripts.

update 2019/08/02 NetworkManager supports since 1.18.0 configuring policy routing rules in the profile. However, there are still two caveats to manually configure what wg-quick does with TABLE=auto (and what WireGuard calls “Improved Rule-based Routing“). First, it requires the suppress_prefixlength rule attribute. That attribute is only supported since NetworkManager 1.20.0. The second problem is that it requires to put the default-route in a dedicated table. While you can configure the routing table for manual routes in NetworkManager, you currently cannot configure a default route (with prefix lenth 0) like a manual route. That needs fixing. On the upside, 1.20.0 brings also new options wireguard.ip4-auto-default-route and wireguard.ip6-auto-default-route. These options are enabled by default and NetworkManager will now automatically configure policy routing like wg-quick with TABLE=auto. This automatism offers a nice solution for the problem.

Key, Peer, and IP Address Management

The beauty of WireGuard is its simplicity. But it also leaves all questions about key distribution, peer management and IP address assignment to the upper layers. For the moment NetworkManager does not provide additional logic on top of WireGuard and exposes just the plain settings. This leaves the user (or external tools) to manually distribute private keys and configure peers, IP addresses and routing. I expect that as WireGuard matures there will be schemes for simplifying this and NetworkManager may implement such protocols or functionality. But NetworkManager won’t come up with a homegrown, non-standard way of doing this.

WireGuard is Layer3 only. That means you cannot run DHCP on a WireGuard link and ipv4.method=auto is not a valid configuration. Instead, you have to configure static addresses or IPv6 link local addresses.


WireGuard, like most tunnel based solutions, have neat applications regarding networking namespaces. This is not implemented in NetworkManager yet, but we would be interested to do so. Note that this isn’t specific to WireGuard tunnels and namespace isolation would be a useful feature in general.

What’s next?

  • Add support for policy-routing rules (rhbz#1652653).
  • Automatically help avoiding routing loops when routing all traffic.
  • Add nmcli support for configuring WireGuard peers.
  • Add WireGuard support to other NetworkManager clients, like nm-connection-editor.
  • See where management tools for WireGuard go and what NetworkManager can do to simplify management of keys, peers and addressing.
  • Provide an API in NetworkManager to isolate networks via networking namespaces. This is not specific to WireGuard but will be useful in that context.

MAC Address Spoofing in NetworkManager 1.4.0

The new NetworkManager release 1.4.0 adds new features to change the current MAC address of your Ethernet or Wi-Fi card. This is also called MAC address “spoofing” or “cloning”.

His name is Václav
Václav sleeps better with NetworkManager’s MAC address randomization

Previously NetworkManager 1.2.0 added MAC address randomization for Wi-Fi, as Lubomir explains in his blog post. He also explains why you may want to do that in the first place, so I skip the introduction. Suffice to say, some consider randomizing the MAC address an important feature to protect their privacy. Only be aware that for real™ privacy, more considerations come into play. The Tails distribution and Wikipedia have good reads on the subject.

1.2.0 relies on support from wpa_supplicant to configure a random MAC address. The problem is that it requires API which will only be part of the next major release 2.6 of the supplicant. Such a release does not yet exist to this date and thus virtually nobody is using this feature.

With NetworkManager 1.4.0, changing of the MAC address is done by NetworkManager itself, requiring no support from the supplicant. This allows also for more flexibility to generate “stable” addresses and the “generate-mac-address-mask”. Also, the same options are now available not only for Wi-Fi, but also Ethernet devices.

Tools like macchanger and macchiato are commonly used to change the MAC address of a device. They support flexible mechanisms to generate a random address, most of these options are now also supported by NetworkManager.

Randomization during Wi-Fi scanning

During Wi-Fi scanning, NetworkManager resets the MAC address frequently to a randomly generated address. This was already enabled by default in 1.2.0, but as said, users likely didn’t have the required support from wpa_supplicant.

This default behavior can be disabled with a global configuration option in NetworkManager.conf:


Note that this is a per-device configuration value, because at the time of Wi-Fi scanning, no connection is yet activated. A “connection” in NetworkManager-speak is a profile, a bunch of settings.

Supported Modes

Since long, NetworkManager supports two connection properties “ethernet.cloned-mac-address” and “wifi.cloned-mac-address”. These settings take effect when activating the connection. They got extended in 1.4.0 and support the following values:

  • An explict MAC address: this was already supported before 1.4.0 and allows to spoof a specific MAC address.
  • “permanent”: use the permanent MAC address of the device. Before 1.4.0, the permanent MAC address was used if the “cloned-mac-address” property was left empty, thus it was the default.
  • “preserve”: don’t change the MAC address of the device upon activation.
  • “random”: generate a randomized value upon each connect.
  • “stable”: generate a stable, hashed MAC address.
  • NULL/unset: this is the default value which allows fallback to a globally configured default, see below. In case no global override exists, NetworkManager falls back to “permanent”, like it did before.

Update-2017-01-25: with 1.6 release and newer, the default value changed from “permanent” to “preserve” [commit],[bug].

Note that in the D-Bus API, the “cloned-mac-address” field is not a string and thus could not be extended in a backward compatible way. That is why on D-Bus there are new fields “ethernet.assigned-mac-address” and “wifi.assigned-mac-address” instead. On the other hand, in nmcli, libnm.so, and keyfile-format the properties are indeed called “cloned-mac-address”.

How to configure it?

It is likely that your favorite NetworkManager client does not expose these options in the UI. In that case, I would suggest to use nmcli to configure the per-connection settings:

$ nmcli connection show
NAME               UUID               TYPE            DEVICE
My Wi-Fi           fca8fc45-c47...    802-11-wireless --

$ nmcli connection show "My Wi-Fi"

$ nmcli connection modify "My Wi-Fi" \
        wifi.cloned-mac-address stable

$ nmcli connection up "My Wi-Fi"

$ ip link show

Stable MAC Address Generation

The “stable” method warrants more explanation. In a way it is similar to “random”, but instead it generates a stable, hashed value. This way every time the connection activates, the same address is generated. However, each connection generates a different address.

This is for example useful so that you get the same IP address from DHCP, which might not be the case with “random”. Or a captive-portal might remember your login-status based on the MAC address. With “random” you may be required to re-authenticate on every connect.

The “stable” mode still makes you easily recognizable when you re-connect to a previous network, but your hardware MAC address is hidden and tracking you across different networks may be harder (YMMV).

The stable address is generated by hashing a private key from /var/lib/NetworkManager/secret_key, the ifname of the device, and a stable-id. The stable-id by default is the UUID of the connection (“connection.uuid”), unless you configure the new property “connection.stable-id“. The latter allows you to have multiple connections that generate the same MAC address. Note that “connection.stable-id” property is also used when generating stable-privacy IPv6 addresses (“ipv6.addr-gen-mode”, RFC 7217).

Format of the MAC Address

The “random” and “stable” modes both generate a MAC address. By default, all 48 bits of the MAC address are scrambled except the following two bits. For one, the LSB of the first octet which must always be cleared to indicate a unicast MAC address. And then, the 2nd-LSB of the first octet is set to indicate a locally administered address — contrary to a burned-in address. This has the same effect as calling macchanger --random with respect to which bits are scrambled.

Which bits are scrambled is configurable by the per-connection properties “ethernet.generate-mac-address-mask” and “wifi.generate-mac-address-mask” [man]. During Wi-Fi scanning, the per-device property “wifi.scan-generate-mac-address-mask” is used instead [man].

The property works as follows. If the mask-setting contains one MAC address, that address is used as a mask. For example “FF:FF:FF:00:00:00” results in randomizing the lower 3 octets and use the vendor OUI of the device’s permanent MAC address. This is similar to macchanger --ending, except that NetworkManager uses the permanent MAC address of the device while macchanger preserves the OUI of the current address.

Update-2016-11-04: it doesn’t use the permanent MAC address, instead the “initial” MAC address, that is the current MAC address that was configured on the device outside of NetworkManager.

If after the initial mask a second MAC address follows, that address is used instead of the device’s permanent address. For example “FF:FF:FF:00:00:00 00:50:E4:00:00:00” sets the OUI to “00:50:E4” but randomizes the last 3 octets. Likewise, “02:00:00:00:00:00 00:00:00:00:00:00” scrambles all bits but clears the second LSB of the first octet, thus creating a burned-in address like macchanger --random --bia.

Actually, there can follow arbitrary many MAC addresses after the mask, in which case one will be chosen randomly. “02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00” will scramble all 47 bits — except the unicast bit which must be always cleared. This allows you to specify a list of OUIs.

Global Default Configuration

NetworkManager supports certain per-connection properties to fallback to a globally configured default value. By having “cloned-mac-address” or “generate-mac-address-mask” unset, it allows fallback to a value configured in NetworkManager.conf.

For example, I have a file /etc/NetworkManager/conf.d/30-mac-randomization.conf like:

# "yes" is already the default for scanning


which sets the default fallback to random. Only for a few selected connection profiles I explicitly switch the per-connection setting to “stable”.

Note: distributions and packages are advised to install configuration snippets to /usr/lib/NetworkManager/conf.d directory instead of /etc.

What’s missing?

What feature do you miss?

One idea would be to support some special “connection.stable-id”. This would allow to implement a “change daily” feature like Windows 10 has. Allowing for a stable-id “time: <date> <time> <period>” could have the effect to start at <date>-<time> and generate a new ID each <period> time. Say, “time: 2016-08-22 6:00:00 7d” could mean to generate a new ID every Monday at 6:00 a.m. Of course, the ID only gets re-generated upon activation of a connection.

Update-2017-01-25: since 1.6, NetworkManager supports dynamic stable-ids like "${BOOT}", "${CONNECTION}", "${RANDOM}" or any combination of these. This also affects RFC7217 stable privacy IPv4 addresses [commit], [example].

Another idea would be to allow a special keyword “preserve” in “generate-mac-address-mask”. It could be used to set a value like “FF:FF:FF:00:00:00 preserve” which should have the same effect as macchanger --ending and use the current MAC address instead of the permanent one.

If you have problems, questions or suggestions, meet us on mailing list, IRC (#nm on freenode) or check our documentation and our bugtracker.

Towards NetworkManager 1.2

Since beginning of this year (2016), two beta releases for the upcoming NetworkManager version 1.2 were released [beta1] [beta2] [git-beta1] [git-beta2].

These lead us towards the next stable version which will bring many new features and improvements. Without going into detail, the improvements and fixes are vast [NEWS].

  • A lot of code was refactored and cleaned up. For example the platform code was for large parts rewritten and now implements netlink-route parsing without relying on libnl3-route library. I think it is fair to say, that the code keeps improving.
  •  We also significantly improved our testing. With the help from Red Hat’s QA team we have an extensive suite of integration tests that help us immensely to be confident about the stability of the code. Currently those tests require internal infrastructure and are thus not yet upstream. But that is on our todo list. Also Coverity and valgrind help us to discover bugs.
  • The previous version 1.0 already introduced the new libnm library to replace the legacy libnm-util/libnm-glib pair. The main reason was to move away from the long deprecated dbus-glib library which NetworkManager was using since the early days. This was not really fixable without introducing a new library. Note that the legacy libraries are still there and continue to be available as long as there are users.
    Now with 1.2, we also ported most VPN plugins and nm-applet to the new library. The VPN plugins contain a shared library which can be loaded by clients to import/export VPN configurations. Those VPN libraries are now available in two flavors, for users of libnm and libnm-glib.

Backward compatibility is of the highest priority for us. Optimally, you can update from an older version without running into any regressions. If you happen to encounter a problem it is likely an issue we want to hear about and fix it.

What about 1.0?

The first release of the current stable branch 1.0 happened more than a year ago. Indeed, NetworkManager’s upstream project makes new major releases very infrequently and the project might not look very active. Well, that is not the case.

NetworkManager’s stable branch 1.0 continues to be heavily maintained in parallel. The last minor release 1.0.10 was cut end of December 2015 [1.0.10] [git-1.0.10].

These stable releases contain much more than mere bug fixes for the 1.0 branch. During the past year more than 1400 commits were backported from the development branch, including new features and major refactorings. This was done to let users and downstream benefit from the work on master and to provide important improvements while waiting for version 1.2.

In fact, some of the new features for 1.2 already found their way back to the stable branch and if you are using a recent distribution like Fedora 23, you already have a small taste of what’s coming.

Where and How?

There are still a few things that need to be fixed. Then the first release candidate 1.2-rc1 will happen and the final 1.2.0 release should happen soon after. I think by mid April 2016 NetworkManager 1.2.0 will be out.

If you want to give it a try, you can build it from source [master] [beta2]. Our master branch is in a good shape and close to the final state. Alternatively, a beta is also packaged in Debian testing/unstable and Fedora 24/rawhide.

We love to hear feedback on networkmanager-list@gnome.org or #nm on IRC/freenode.