fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-05-18 08:08:09 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/devices/nm-device-wireguard.c

2009 lines
68 KiB
C
Raw Normal View History

all: SPDX header conversion $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
2019-09-10 11:19:01 +02:00
// SPDX-License-Identifier: LGPL-2.1+
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2018 Javier Arteaga <jarteaga@jbeta.is>
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
*/
#include "nm-default.h"
#include "nm-device-wireguard.h"
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
#include <linux/rtnetlink.h>
#include <linux/fib_rules.h>
libnm,cli: add NMSettingWireGuard For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
2018-12-27 16:48:30 +01:00
#include "nm-setting-wireguard.h"
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
#include "nm-core-internal.h"
shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" From the files under "shared/nm-utils" we build an internal library that provides glib-based helper utilities. Move the files of that basic library to a new subdirectory "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la" to "libnm-glib-aux.la". Reasons: - the name "utils" is overused in our code-base. Everything's an "utils". Give this thing a more distinct name. - there were additional files under "shared/nm-utils", which are not part of this internal library "libnm-utils-base.la". All the files that are part of this library should be together in the same directory, but files that are not, should not be there. - the new name should better convey what this library is and what is isn't: it's a set of utilities and helper functions that extend glib with funcitonality that we commonly need. There are still some files left under "shared/nm-utils". They have less a unifying propose to be in their own directory, so I leave them there for now. But at least they are separate from "shared/nm-glib-aux", which has a very clear purpose. (cherry picked from commit 80db06f768e47541eae7d66ef48fbe47bf1a69ce)
2019-04-15 08:16:00 +02:00
#include "nm-glib-aux/nm-secret-utils.h"
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#include "nm-device-private.h"
#include "platform/nm-platform.h"
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
#include "platform/nmp-object.h"
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
#include "platform/nmp-rules-manager.h"
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#include "nm-device-factory.h"
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
#include "nm-active-connection.h"
#include "nm-act-request.h"
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
#include "dns/nm-dns-manager.h"
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#include "nm-device-logging.h"
_LOG_DECLARE_SELF(NMDeviceWireGuard);
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/* TODO: activate profile with peer preshared-key-flags=2. On first activation, the secret is
* requested (good). Enter it and connect. Reactivate the profile, now there is no password
* prompt, as the secret is cached (good??). */
/* TODO: unlike for other VPNs, we don't inject a direct route to the peers. That means,
* you might get a routing sceneraio where the peer (VPN server) is reachable via the VPN.
* How we handle adding routes to external gateway for other peers, has severe issues
wireguard: update TODO list for WireGuard devices (cherry picked from commit 3990c92fbf4789d8de2264b39f9d1b690f5dd4d5)
2019-03-01 09:02:20 +01:00
* as well. We may use policy-routing like wg-quick does. See also disussions at
* https://www.wireguard.com/netns/#improving-the-classic-solutions */
/* TODO: honor the TTL of DNS to determine when to retry resolving endpoints. */
/* TODO: when we get multiple IP addresses when resolving a peer endpoint. We currently
* just take the first from GAI. We should only accept AAAA/IPv6 if we also have a suitable
* IPv6 address. The problem is, that we have to recheck that when IP addressing on other
* interfaces changes. This makes it almost too cumbersome to implement. */
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/*****************************************************************************/
libnm,cli: add NMSettingWireGuard For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
2018-12-27 16:48:30 +01:00
G_STATIC_ASSERT (NM_WIREGUARD_PUBLIC_KEY_LEN == NMP_WIREGUARD_PUBLIC_KEY_LEN);
G_STATIC_ASSERT (NM_WIREGUARD_SYMMETRIC_KEY_LEN == NMP_WIREGUARD_SYMMETRIC_KEY_LEN);
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
#define LINK_CONFIG_RATE_LIMIT_NSEC (50 * NM_UTILS_NS_PER_MSEC)
/* a special @next_try_at_nsec timestamp indicating that we should try again as soon as possible. */
#define NEXT_TRY_AT_NSEC_ASAP ((gint64) G_MAXINT64)
/* a special @next_try_at_nsec timestamp that is
* - positive (indicating resolve-checks are enabled)
* - already in the past (we use the absolute timestamp of 1nsec for that). */
#define NEXT_TRY_AT_NSEC_PAST ((gint64) 1)
/* like %NEXT_TRY_AT_NSEC_ASAP, but used for indicating to retry ASAP for a @retry_in_msec value.
* That is a relative time duraction, contrary to @next_try_at_nsec which is an absolute
* timestamp. */
#define RETRY_IN_MSEC_ASAP ((gint64) G_MAXINT64)
#define RETRY_IN_MSEC_MAX ((gint64) (30 * 60 * 1000))
typedef enum {
LINK_CONFIG_MODE_FULL,
LINK_CONFIG_MODE_REAPPLY,
LINK_CONFIG_MODE_ASSUME,
LINK_CONFIG_MODE_ENDPOINTS,
} LinkConfigMode;
typedef struct {
GCancellable *cancellable;
NMSockAddrUnion sockaddr;
/* the timestamp (in nm_utils_get_monotonic_timestamp_ns() scale) when we want
* to retry resolving the endpoint (again).
*
* It may be set to %NEXT_TRY_AT_NSEC_ASAP to indicate to re-resolve as soon as possible.
*
* A @sockaddr is either fixed or it has
* - @cancellable set to indicate an ongoing request
* - @next_try_at_nsec set to a positive value, indicating when
* we ought to retry. */
gint64 next_try_at_nsec;
guint resolv_fail_count;
} PeerEndpointResolveData;
typedef struct {
NMWireGuardPeer *peer;
NMDeviceWireGuard *self;
CList lst_peers;
PeerEndpointResolveData ep_resolv;
/* dirty flag used during _peers_update_all(). */
bool dirty_update_all:1;
} PeerData;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
NM_GOBJECT_PROPERTIES_DEFINE (NMDeviceWireGuard,
PROP_PUBLIC_KEY,
PROP_LISTEN_PORT,
PROP_FWMARK,
);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
typedef struct {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMDnsManager *dns_manager;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMPlatformLnkWireGuard lnk_curr;
NMActRequestGetSecretsCallId *secrets_call_id;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
CList lst_peers_head;
GHashTable *peers;
gint64 resolve_next_try_at;
gint64 link_config_last_at;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint resolve_next_try_id;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
guint link_config_delayed_id;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint32 auto_default_route_fwmark;
guint32 auto_default_route_priority;
bool auto_default_route_enabled_4:1;
bool auto_default_route_enabled_6:1;
bool auto_default_route_initialized:1;
bool auto_default_route_refresh:1;
bool auto_default_route_priority_initialized:1;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
} NMDeviceWireGuardPrivate;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
struct _NMDeviceWireGuard {
NMDevice parent;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceWireGuardPrivate _priv;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
};
struct _NMDeviceWireGuardClass {
NMDeviceClass parent;
};
G_DEFINE_TYPE (NMDeviceWireGuard, nm_device_wireguard, NM_TYPE_DEVICE)
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
#define NM_DEVICE_WIREGUARD_GET_PRIVATE(self) _NM_GET_PRIVATE (self, NMDeviceWireGuard, NM_IS_DEVICE_WIREGUARD, NMDevice)
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static void _peers_resolve_start (NMDeviceWireGuard *self,
PeerData *peer_data);
static void _peers_resolve_retry_reschedule (NMDeviceWireGuard *self,
gint64 new_next_try_at_nsec);
static gboolean link_config_delayed_resolver_cb (gpointer user_data);
static gboolean link_config_delayed_ratelimit_cb (gpointer user_data);
/*****************************************************************************/
NM_UTILS_LOOKUP_STR_DEFINE_STATIC (_link_config_mode_to_string, LinkConfigMode,
NM_UTILS_LOOKUP_DEFAULT_NM_ASSERT (NULL),
NM_UTILS_LOOKUP_ITEM (LINK_CONFIG_MODE_FULL, "full"),
NM_UTILS_LOOKUP_ITEM (LINK_CONFIG_MODE_REAPPLY, "reapply"),
NM_UTILS_LOOKUP_ITEM (LINK_CONFIG_MODE_ASSUME, "assume"),
NM_UTILS_LOOKUP_ITEM (LINK_CONFIG_MODE_ENDPOINTS, "endpoints"),
);
/*****************************************************************************/
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
static void
_auto_default_route_get_enabled (NMSettingWireGuard *s_wg,
NMConnection *connection,
gboolean *out_enabled_v4,
gboolean *out_enabled_v6)
{
NMTernary enabled_v4;
NMTernary enabled_v6;
enabled_v4 = nm_setting_wireguard_get_ip4_auto_default_route (s_wg);
enabled_v6 = nm_setting_wireguard_get_ip6_auto_default_route (s_wg);
if (enabled_v4 == NM_TERNARY_DEFAULT) {
if (nm_setting_ip_config_get_never_default (nm_connection_get_setting_ip_config (connection, AF_INET)))
enabled_v4 = FALSE;
}
if (enabled_v6 == NM_TERNARY_DEFAULT) {
if (nm_setting_ip_config_get_never_default (nm_connection_get_setting_ip_config (connection, AF_INET6)))
enabled_v6 = FALSE;
}
if ( enabled_v4 == NM_TERNARY_DEFAULT
|| enabled_v6 == NM_TERNARY_DEFAULT) {
guint i, n_peers;
n_peers = nm_setting_wireguard_get_peers_len (s_wg);
for (i = 0; i < n_peers; i++) {
NMWireGuardPeer *peer = nm_setting_wireguard_get_peer (s_wg, i);
guint n_aips;
guint j;
n_aips = nm_wireguard_peer_get_allowed_ips_len (peer);
for (j = 0; j < n_aips; j++) {
const char *aip;
gboolean valid;
int prefix;
int addr_family;
aip = nm_wireguard_peer_get_allowed_ip (peer, j, &valid);
if (!valid)
continue;
if (!nm_utils_parse_inaddr_prefix_bin (AF_UNSPEC,
aip,
&addr_family,
NULL,
&prefix))
continue;
if (prefix != 0)
continue;
if (addr_family == AF_INET) {
if (enabled_v4 == NM_TERNARY_DEFAULT) {
enabled_v4 = TRUE;
if (enabled_v6 != NM_TERNARY_DEFAULT)
goto done;
}
} else {
if (enabled_v6 == NM_TERNARY_DEFAULT) {
enabled_v6 = TRUE;
if (enabled_v4 != NM_TERNARY_DEFAULT)
goto done;
}
}
}
}
done:
;
}
*out_enabled_v4 = (enabled_v4 == TRUE);
*out_enabled_v6 = (enabled_v6 == TRUE);
}
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
#define AUTO_RANDOM_RANGE 500u
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
static guint32
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
_auto_default_route_get_auto_fwmark (const char *uuid)
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
{
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
guint64 rnd_seed;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
/* we use the generated number as fwmark but also as routing table for
* the default-route.
*
* We pick a number
*
* - based on the connection's UUID (as stable seed).
* - larger than 51820u (arbitrarily)
* - one out of AUTO_RANDOM_RANGE
*/
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
rnd_seed = c_siphash_hash (NM_HASH_SEED_16 (0xb9, 0x39, 0x8e, 0xed, 0x15, 0xb3, 0xd1, 0xc4, 0x5f, 0x45, 0x00, 0x4f, 0xec, 0xc2, 0x2b, 0x7e),
(const guint8 *) uuid,
uuid ? strlen (uuid) + 1u : 0u);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
return 51820u + (rnd_seed % AUTO_RANDOM_RANGE);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
}
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
#define PRIO_WIDTH 2u
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
static guint32
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
_auto_default_route_get_auto_priority (const char *uuid)
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
{
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
const guint32 RANGE_TOP = 32766u - 1000u;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint64 rnd_seed;
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
/* we pick a priority for the routing rules as follows:
*
* - use the connection's UUID as stable seed for the "random" number.
* - have it smaller than RANGE_TOP (32766u - 1000u), where 32766u is the priority of the default
* rules
* - we add 2 rules (PRIO_WIDTH). Hence only pick even priorites.
* - pick one out of AUTO_RANDOM_RANGE. */
rnd_seed = c_siphash_hash (NM_HASH_SEED_16 (0x99, 0x22, 0x4d, 0x7c, 0x37, 0xda, 0x8e, 0x7b, 0x2f, 0x55, 0x16, 0x7b, 0x75, 0xda, 0x42, 0xdc),
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
(const guint8 *) uuid,
uuid ? strlen (uuid) + 1u : 0u);
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
return RANGE_TOP - (((rnd_seed % (PRIO_WIDTH * AUTO_RANDOM_RANGE)) / PRIO_WIDTH) * PRIO_WIDTH);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
}
static void
_auto_default_route_init (NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
NMConnection *connection;
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
gboolean enabled_v4 = FALSE;
gboolean enabled_v6 = FALSE;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
gboolean refreshing_only;
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
guint32 new_fwmark = 0;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint32 old_fwmark;
char sbuf1[100];
if (G_LIKELY ( priv->auto_default_route_initialized
&& !priv->auto_default_route_refresh))
return;
refreshing_only = priv->auto_default_route_initialized
&& priv->auto_default_route_refresh;
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
old_fwmark = priv->auto_default_route_fwmark;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
connection = nm_device_get_applied_connection (NM_DEVICE (self));
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
if (connection) {
NMSettingWireGuard *s_wg;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
s_wg = _nm_connection_get_setting (connection, NM_TYPE_SETTING_WIREGUARD);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
new_fwmark = nm_setting_wireguard_get_fwmark (s_wg);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
_auto_default_route_get_enabled (s_wg,
connection,
&enabled_v4,
&enabled_v6);
}
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
if ( ( enabled_v4
|| enabled_v6)
&& new_fwmark == 0u) {
if (refreshing_only)
new_fwmark = old_fwmark;
else
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
new_fwmark = _auto_default_route_get_auto_fwmark (nm_connection_get_uuid (connection));
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
}
priv->auto_default_route_refresh = FALSE;
priv->auto_default_route_fwmark = new_fwmark;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
priv->auto_default_route_enabled_4 = enabled_v4;
priv->auto_default_route_enabled_6 = enabled_v6;
priv->auto_default_route_initialized = TRUE;
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
if (connection) {
_LOGT (LOGD_DEVICE,
"auto-default-route is %s for IPv4 and %s for IPv6%s",
priv->auto_default_route_enabled_4 ? "enabled" : "disabled",
priv->auto_default_route_enabled_6 ? "enabled" : "disabled",
priv->auto_default_route_enabled_4 || priv->auto_default_route_enabled_6
? nm_sprintf_buf (sbuf1, " (fwmark 0x%x)", priv->auto_default_route_fwmark)
: "");
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
}
}
static GPtrArray *
get_extra_rules (NMDevice *device)
{
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD (device);
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
gs_unref_ptrarray GPtrArray *extra_rules = NULL;
guint32 priority = 0;
int is_ipv4;
NMConnection *connection;
_auto_default_route_init (self);
connection = nm_device_get_applied_connection (device);
if (!connection)
return NULL;
for (is_ipv4 = 0; is_ipv4 < 2; is_ipv4++) {
NMSettingIPConfig *s_ip;
int addr_family = is_ipv4 ? AF_INET : AF_INET6;
guint32 table_main;
guint32 fwmark;
if (is_ipv4) {
if (!priv->auto_default_route_enabled_4)
continue;
} else {
if (!priv->auto_default_route_enabled_6)
continue;
}
if (!extra_rules) {
if (priv->auto_default_route_priority_initialized)
priority = priv->auto_default_route_priority;
else {
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
priority = _auto_default_route_get_auto_priority (nm_connection_get_uuid (connection));
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
priv->auto_default_route_priority = priority;
priv->auto_default_route_priority_initialized = TRUE;
}
extra_rules = g_ptr_array_new_with_free_func ((GDestroyNotify) nmp_object_unref);
}
s_ip = nm_connection_get_setting_ip_config (connection, addr_family);
table_main = nm_setting_ip_config_get_route_table (s_ip);
if (table_main == 0)
table_main = RT_TABLE_MAIN;
fwmark = priv->auto_default_route_fwmark;
G_STATIC_ASSERT_EXPR (PRIO_WIDTH == 2);
g_ptr_array_add (extra_rules,
nmp_object_new (NMP_OBJECT_TYPE_ROUTING_RULE,
&((const NMPlatformRoutingRule) {
.priority = priority,
.addr_family = addr_family,
.action = FR_ACT_TO_TBL,
.table = table_main,
.suppress_prefixlen_inverse = ~((guint32) 0u),
})));
g_ptr_array_add (extra_rules,
nmp_object_new (NMP_OBJECT_TYPE_ROUTING_RULE,
&((const NMPlatformRoutingRule) {
.priority = priority + 1u,
.addr_family = addr_family,
.action = FR_ACT_TO_TBL,
.table = fwmark,
.flags = FIB_RULE_INVERT,
.fwmark = fwmark,
.fwmask = 0xFFFFFFFFu,
})));
}
return g_steal_pointer (&extra_rules);
}
static guint32
coerce_route_table (NMDevice *device,
int addr_family,
guint32 route_table,
gboolean is_user_config)
{
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD (device);
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
gboolean auto_default_route_enabled;
if (route_table != 0u)
return route_table;
_auto_default_route_init (self);
auto_default_route_enabled = (addr_family == AF_INET)
? priv->auto_default_route_enabled_4
: priv->auto_default_route_enabled_6;
if (auto_default_route_enabled) {
/* we need to enable full-sync mode of all routing tables. */
_LOGT (LOGD_DEVICE, "coerce ipv%c.route-table setting to \"main\" (table 254) as we enable auto-default-route handling",
nm_utils_addr_family_to_char (addr_family));
return RT_TABLE_MAIN;
}
return 0;
}
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static gboolean
_peer_data_equal (gconstpointer ptr_a, gconstpointer ptr_b)
{
const PeerData *peer_data_a = ptr_a;
const PeerData *peer_data_b = ptr_b;
return nm_streq (nm_wireguard_peer_get_public_key (peer_data_a->peer),
nm_wireguard_peer_get_public_key (peer_data_b->peer));
}
static guint
_peer_data_hash (gconstpointer ptr)
{
const PeerData *peer_data = ptr;
return nm_hash_str (nm_wireguard_peer_get_public_key (peer_data->peer));
}
static PeerData *
_peers_find (NMDeviceWireGuardPrivate *priv,
NMWireGuardPeer *peer)
{
nm_assert (peer);
G_STATIC_ASSERT_EXPR (G_STRUCT_OFFSET (PeerData, peer) == 0);
return g_hash_table_lookup (priv->peers, &peer);
}
static void
_peers_remove (NMDeviceWireGuardPrivate *priv,
PeerData *peer_data)
{
nm_assert (peer_data);
nm_assert (g_hash_table_lookup (priv->peers, peer_data) == peer_data);
if (!g_hash_table_remove (priv->peers, peer_data))
nm_assert_not_reached ();
c_list_unlink_stale (&peer_data->lst_peers);
nm_wireguard_peer_unref (peer_data->peer);
nm_clear_g_cancellable (&peer_data->ep_resolv.cancellable);
g_slice_free (PeerData, peer_data);
wireguard: fix use-after free in _peers_remove() (cherry picked from commit 85c26341a280b1234cf73c6537b0bae55fb3adbf)
2019-08-03 12:27:57 +02:00
if (c_list_is_empty (&priv->lst_peers_head)) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_clear_g_source (&priv->resolve_next_try_id);
nm_clear_g_source (&priv->link_config_delayed_id);
}
}
static PeerData *
_peers_add (NMDeviceWireGuard *self,
NMWireGuardPeer *peer)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
PeerData *peer_data;
nm_assert (peer);
nm_assert (nm_wireguard_peer_is_sealed (peer));
nm_assert (!_peers_find (priv, peer));
peer_data = g_slice_new (PeerData);
*peer_data = (PeerData) {
.self = self,
.peer = nm_wireguard_peer_ref (peer),
.ep_resolv = {
.sockaddr = NM_SOCK_ADDR_UNION_INIT_UNSPEC,
},
};
c_list_link_tail (&priv->lst_peers_head, &peer_data->lst_peers);
if (!nm_g_hash_table_add (priv->peers, peer_data))
nm_assert_not_reached ();
return peer_data;
}
static gboolean
_peers_resolve_retry_timeout (gpointer user_data)
{
NMDeviceWireGuard *self = user_data;
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
PeerData *peer_data;
gint64 now;
gint64 next;
priv->resolve_next_try_id = 0;
_LOGT (LOGD_DEVICE, "wireguard-peers: rechecking peer endpoints...");
now = nm_utils_get_monotonic_timestamp_ns ();
next = G_MAXINT64;
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers) {
if (peer_data->ep_resolv.next_try_at_nsec <= 0)
continue;
if (peer_data->ep_resolv.cancellable) {
/* we are currently resolving a name. We don't need the global
* watchdog to guard this peer. No need to adjust @next for
* this one, when the currently ongoing resolving completes, we
* may reschedule. Skip. */
continue;
}
if ( peer_data->ep_resolv.next_try_at_nsec == NEXT_TRY_AT_NSEC_ASAP
|| now >= peer_data->ep_resolv.next_try_at_nsec) {
_peers_resolve_start (self, peer_data);
/* same here. Now we are resolving. We don't need the global
* watchdog. Skip w.r.t. finding @next. */
continue;
}
if (next > peer_data->ep_resolv.next_try_at_nsec)
next = peer_data->ep_resolv.next_try_at_nsec;
}
if (next < G_MAXINT64)
_peers_resolve_retry_reschedule (self, next);
return G_SOURCE_REMOVE;
}
static void
_peers_resolve_retry_reschedule (NMDeviceWireGuard *self,
gint64 new_next_try_at_nsec)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
guint32 interval_ms;
gint64 now;
nm_assert (new_next_try_at_nsec > 0);
nm_assert (new_next_try_at_nsec != NEXT_TRY_AT_NSEC_ASAP);
if ( priv->resolve_next_try_id
&& priv->resolve_next_try_at <= new_next_try_at_nsec) {
/* we already have an earlier timeout scheduled (possibly for
* another peer that expires sooner). Don't reschedule now.
* Even if the scheduled timeout expires too early, we will
* compute the right next-timeout and reschedule then. */
return;
}
now = nm_utils_get_monotonic_timestamp_ns ();
/* schedule at most one day ahead. No problem if we expire earlier
* than expected. Also, rate-limit to 500 msec. */
interval_ms = NM_CLAMP ((new_next_try_at_nsec - now) / NM_UTILS_NS_PER_MSEC,
(gint64) 500,
(gint64) (24*60*60*1000));
_LOGT (LOGD_DEVICE, "wireguard-peers: schedule rechecking peer endpoints in %u msec",
interval_ms);
nm_clear_g_source (&priv->resolve_next_try_id);
priv->resolve_next_try_at = new_next_try_at_nsec;
priv->resolve_next_try_id = g_timeout_add (interval_ms,
_peers_resolve_retry_timeout,
self);
}
static void
_peers_resolve_retry_reschedule_for_peer (NMDeviceWireGuard *self,
PeerData *peer_data,
gint64 retry_in_msec)
{
nm_assert (retry_in_msec >= 0);
if (retry_in_msec == RETRY_IN_MSEC_ASAP) {
_peers_resolve_start (self, peer_data);
return;
}
peer_data->ep_resolv.next_try_at_nsec = nm_utils_get_monotonic_timestamp_ns ()
+ (retry_in_msec * NM_UTILS_NS_PER_MSEC);
_peers_resolve_retry_reschedule (self, peer_data->ep_resolv.next_try_at_nsec);
}
static gint64
_peers_retry_in_msec (PeerData *peer_data,
gboolean after_failure)
{
if (peer_data->ep_resolv.next_try_at_nsec == NEXT_TRY_AT_NSEC_ASAP) {
peer_data->ep_resolv.resolv_fail_count = 0;
return RETRY_IN_MSEC_ASAP;
}
if (after_failure) {
if (peer_data->ep_resolv.resolv_fail_count < G_MAXUINT)
peer_data->ep_resolv.resolv_fail_count++;
} else
peer_data->ep_resolv.resolv_fail_count = 0;
if (!after_failure)
return RETRY_IN_MSEC_MAX;
if (peer_data->ep_resolv.resolv_fail_count > 20)
return RETRY_IN_MSEC_MAX;
/* double the retry-time, starting with one second. */
return NM_MIN (RETRY_IN_MSEC_MAX,
(1u << peer_data->ep_resolv.resolv_fail_count) * 500);
}
static void
_peers_resolve_cb (GObject *source_object,
GAsyncResult *res,
gpointer user_data)
{
NMDeviceWireGuard *self;
PeerData *peer_data;
gs_free_error GError *resolv_error = NULL;
GList *list;
gboolean changed = FALSE;
NMSockAddrUnion sockaddr;
gint64 retry_in_msec;
char s_sockaddr[100];
char s_retry[100];
list = g_resolver_lookup_by_name_finish (G_RESOLVER (source_object), res, &resolv_error);
if (nm_utils_error_is_cancelled (resolv_error, FALSE))
return;
peer_data = user_data;
self = peer_data->self;
g_clear_object (&peer_data->ep_resolv.cancellable);
nm_assert ((!resolv_error) != (!list));
#define _retry_in_msec_to_string(retry_in_msec, s_retry) \
({ \
gint64 _retry_in_msec = (retry_in_msec); \
\
_retry_in_msec == RETRY_IN_MSEC_ASAP \
? "right away" \
: nm_sprintf_buf (s_retry, "in %"G_GINT64_FORMAT" msec", _retry_in_msec); \
})
if ( resolv_error
&& !g_error_matches (resolv_error, G_RESOLVER_ERROR, G_RESOLVER_ERROR_NOT_FOUND)) {
retry_in_msec = _peers_retry_in_msec (peer_data, TRUE);
_LOGT (LOGD_DEVICE, "wireguard-peer[%s]: failure to resolve endpoint \"%s\": %s (retry %s)",
nm_wireguard_peer_get_public_key (peer_data->peer),
nm_wireguard_peer_get_endpoint (peer_data->peer),
resolv_error->message,
_retry_in_msec_to_string (retry_in_msec, s_retry));
_peers_resolve_retry_reschedule_for_peer (self, peer_data, retry_in_msec);
return;
}
sockaddr = (NMSockAddrUnion) NM_SOCK_ADDR_UNION_INIT_UNSPEC;
if (!resolv_error) {
GList *iter;
for (iter = list; iter; iter = iter->next) {
GInetAddress *a = iter->data;
GSocketFamily f = g_inet_address_get_family (a);
if (f == G_SOCKET_FAMILY_IPV4) {
nm_assert (g_inet_address_get_native_size (a) == sizeof (struct in_addr));
sockaddr.in = (struct sockaddr_in) {
.sin_family = AF_INET,
.sin_port = htons (nm_sock_addr_endpoint_get_port (_nm_wireguard_peer_get_endpoint (peer_data->peer))),
};
memcpy (&sockaddr.in.sin_addr, g_inet_address_to_bytes (a), sizeof (struct in_addr));
break;
}
if (f == G_SOCKET_FAMILY_IPV6) {
nm_assert (g_inet_address_get_native_size (a) == sizeof (struct in6_addr));
sockaddr.in6 = (struct sockaddr_in6) {
.sin6_family = AF_INET6,
.sin6_port = htons (nm_sock_addr_endpoint_get_port (_nm_wireguard_peer_get_endpoint (peer_data->peer))),
.sin6_scope_id = 0,
.sin6_flowinfo = 0,
};
memcpy (&sockaddr.in6.sin6_addr, g_inet_address_to_bytes (a), sizeof (struct in6_addr));
break;
}
}
g_list_free_full (list, g_object_unref);
}
if (sockaddr.sa.sa_family == AF_UNSPEC) {
/* we failed to resolve the name. There is no need to reset the previous
* sockaddr. Either it was already AF_UNSPEC, or we had a good name
* from resolving before. In that case, we don't want to throw away
* a possibly good IP address, since WireGuard supports automatic roaming
* anyway. Either the IP address is still good (and we would wrongly
* reject it), or it isn't -- in which case it does not hurt much. */
} else {
if (nm_sock_addr_union_cmp (&peer_data->ep_resolv.sockaddr, &sockaddr) != 0)
changed = TRUE;
peer_data->ep_resolv.sockaddr = sockaddr;
}
if ( resolv_error
|| peer_data->ep_resolv.sockaddr.sa.sa_family == AF_UNSPEC) {
/* while it technically did not fail, something is probably odd. Retry frequently to
* resolve the name, like we would do for normal failures. */
retry_in_msec = _peers_retry_in_msec (peer_data, TRUE);
_LOGT (LOGD_DEVICE, "wireguard-peer[%s]: no %sresults for endpoint \"%s\" (retry %s)",
nm_wireguard_peer_get_public_key (peer_data->peer),
resolv_error ? "" : "suitable ",
nm_wireguard_peer_get_endpoint (peer_data->peer),
_retry_in_msec_to_string (retry_in_msec, s_retry));
} else {
retry_in_msec = _peers_retry_in_msec (peer_data, FALSE);
_LOGT (LOGD_DEVICE, "wireguard-peer[%s]: endpoint \"%s\" resolved to %s (retry %s)",
nm_wireguard_peer_get_public_key (peer_data->peer),
nm_wireguard_peer_get_endpoint (peer_data->peer),
nm_sock_addr_union_to_string (&peer_data->ep_resolv.sockaddr, s_sockaddr, sizeof (s_sockaddr)),
_retry_in_msec_to_string (retry_in_msec, s_retry));
}
_peers_resolve_retry_reschedule_for_peer (self, peer_data, retry_in_msec);
if (changed) {
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
/* schedule the job in the background, to give multiple resolve events time
* to complete. */
nm_clear_g_source (&priv->link_config_delayed_id);
priv->link_config_delayed_id = g_idle_add_full (G_PRIORITY_DEFAULT_IDLE + 1,
link_config_delayed_resolver_cb,
self,
NULL);
}
}
static void
_peers_resolve_start (NMDeviceWireGuard *self,
PeerData *peer_data)
{
gs_unref_object GResolver *resolver = NULL;
const char *host;
resolver = g_resolver_get_default ();
nm_assert (!peer_data->ep_resolv.cancellable);
peer_data->ep_resolv.cancellable = g_cancellable_new ();
/* set a special next-try timestamp. It is positive, and indicates
* that we are in the process of trying.
* This timestamp however already lies in the past, but that is correct,
* because we are currently in the process of trying. We will determine
* a next-try timestamp once the try completes. */
peer_data->ep_resolv.next_try_at_nsec = NEXT_TRY_AT_NSEC_PAST;
host = nm_sock_addr_endpoint_get_host (_nm_wireguard_peer_get_endpoint (peer_data->peer));
g_resolver_lookup_by_name_async (resolver,
host,
peer_data->ep_resolv.cancellable,
_peers_resolve_cb,
peer_data);
_LOGT (LOGD_DEVICE, "wireguard-peer[%s]: resolving name \"%s\" for endpoint \"%s\"...",
nm_wireguard_peer_get_public_key (peer_data->peer),
host,
nm_wireguard_peer_get_endpoint (peer_data->peer));
}
static void
_peers_resolve_reresolve_all (NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
PeerData *peer_data;
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers) {
if (peer_data->ep_resolv.cancellable) {
/* remember to retry when the currently ongoing request completes. */
peer_data->ep_resolv.next_try_at_nsec = NEXT_TRY_AT_NSEC_ASAP;
} else if (peer_data->ep_resolv.next_try_at_nsec <= 0) {
/* this peer does not require resolving the name. Skip it. */
} else {
/* we have a next-try scheduled. Restart right away. */
peer_data->ep_resolv.resolv_fail_count = 0;
_peers_resolve_start (self, peer_data);
}
}
}
static gboolean
_peers_update (NMDeviceWireGuard *self,
PeerData *peer_data,
NMWireGuardPeer *peer,
gboolean force_update)
{
nm_auto_unref_wgpeer NMWireGuardPeer *old_peer = NULL;
NMSockAddrEndpoint *old_endpoint;
NMSockAddrEndpoint *endpoint;
gboolean endpoint_changed = FALSE;
gboolean changed;
NMSockAddrUnion sockaddr;
gboolean sockaddr_fixed;
char sockaddr_sbuf[100];
nm_assert (peer);
nm_assert (nm_wireguard_peer_is_sealed (peer));
if ( peer == peer_data->peer
&& !force_update)
return FALSE;
changed = (nm_wireguard_peer_cmp (peer,
peer_data->peer,
NM_SETTING_COMPARE_FLAG_EXACT) != 0);
old_peer = peer_data->peer;
peer_data->peer = nm_wireguard_peer_ref (peer);
old_endpoint = old_peer ? _nm_wireguard_peer_get_endpoint (old_peer) : NULL;
endpoint = peer ? _nm_wireguard_peer_get_endpoint (peer) : NULL;
endpoint_changed = ( endpoint != old_endpoint
&& ( !old_endpoint
|| !endpoint
|| !nm_streq (nm_sock_addr_endpoint_get_endpoint (old_endpoint),
nm_sock_addr_endpoint_get_endpoint (endpoint))));
if ( !force_update
&& !endpoint_changed) {
/* nothing to do. */
return changed;
}
sockaddr = (NMSockAddrUnion) NM_SOCK_ADDR_UNION_INIT_UNSPEC;
sockaddr_fixed = TRUE;
if ( endpoint
&& nm_sock_addr_endpoint_get_host (endpoint)) {
if (!nm_sock_addr_endpoint_get_fixed_sockaddr (endpoint, &sockaddr)) {
/* we have an endpoint, but it's not a static IP address. We need to resolve
* the names. */
sockaddr_fixed = FALSE;
}
}
if (nm_sock_addr_union_cmp (&peer_data->ep_resolv.sockaddr, &sockaddr) != 0)
changed = TRUE;
nm_clear_g_cancellable (&peer_data->ep_resolv.cancellable);
peer_data->ep_resolv = (PeerEndpointResolveData) {
.sockaddr = sockaddr,
.resolv_fail_count = 0,
.cancellable = NULL,
.next_try_at_nsec = 0,
};
if (!endpoint) {
_LOGT (LOGD_DEVICE, "wireguard-peer[%s]: no endpoint configured",
nm_wireguard_peer_get_public_key (peer_data->peer));
} else if (!nm_sock_addr_endpoint_get_host (endpoint)) {
_LOGT (LOGD_DEVICE, "wireguard-peer[%s]: invalid endpoint \"%s\"",
nm_wireguard_peer_get_public_key (peer_data->peer),
nm_sock_addr_endpoint_get_endpoint (endpoint));
} else if (sockaddr_fixed) {
_LOGT (LOGD_DEVICE, "wireguard-peer[%s]: fixed endpoint \"%s\" (%s)",
nm_wireguard_peer_get_public_key (peer_data->peer),
nm_sock_addr_endpoint_get_endpoint (endpoint),
nm_sock_addr_union_to_string (&peer_data->ep_resolv.sockaddr, sockaddr_sbuf, sizeof (sockaddr_sbuf)));
} else
_peers_resolve_start (self, peer_data);
return changed;
}
static void
_peers_remove_all (NMDeviceWireGuardPrivate *priv)
{
PeerData *peer_data;
while ((peer_data = c_list_first_entry (&priv->lst_peers_head, PeerData, lst_peers)))
_peers_remove (priv, peer_data);
}
static void
_peers_update_all (NMDeviceWireGuard *self,
NMSettingWireGuard *s_wg,
gboolean *out_peers_removed)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
PeerData *peer_data_safe;
PeerData *peer_data;
guint i, n;
gboolean peers_removed = FALSE;
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers)
peer_data->dirty_update_all = TRUE;
n = nm_setting_wireguard_get_peers_len (s_wg);
for (i = 0; i < n; i++) {
NMWireGuardPeer *peer = nm_setting_wireguard_get_peer (s_wg, i);
gboolean added = FALSE;
peer_data = _peers_find (priv, peer);
if (!peer_data) {
peer_data = _peers_add (self, peer);
added = TRUE;
}
_peers_update (self, peer_data, peer, added);
peer_data->dirty_update_all = FALSE;
}
c_list_for_each_entry_safe (peer_data, peer_data_safe, &priv->lst_peers_head, lst_peers) {
if (peer_data->dirty_update_all) {
_peers_remove (priv, peer_data);
peers_removed = TRUE;
}
}
NM_SET_OUT (out_peers_removed, peers_removed);
}
static void
_peers_get_platform_list (NMDeviceWireGuardPrivate *priv,
LinkConfigMode config_mode,
NMPWireGuardPeer **out_peers,
NMPlatformWireGuardChangePeerFlags **out_peer_flags,
guint *out_len,
GArray **out_allowed_ips_data)
{
gs_free NMPWireGuardPeer *plpeers = NULL;
gs_free NMPlatformWireGuardChangePeerFlags *plpeer_flags = NULL;
gs_unref_array GArray *allowed_ips = NULL;
PeerData *peer_data;
guint i_good;
guint n_aip;
guint i_aip;
guint len;
guint i;
nm_assert (out_peers && !*out_peers);
nm_assert (out_peer_flags && !*out_peer_flags);
nm_assert (out_len && *out_len == 0);
nm_assert (out_allowed_ips_data && !*out_allowed_ips_data);
len = g_hash_table_size (priv->peers);
nm_assert (len == c_list_length (&priv->lst_peers_head));
if (len == 0)
return;
plpeers = g_new0 (NMPWireGuardPeer, len);
plpeer_flags = g_new0 (NMPlatformWireGuardChangePeerFlags, len);
i_good = 0;
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers) {
NMPlatformWireGuardChangePeerFlags *plf = &plpeer_flags[i_good];
NMPWireGuardPeer *plp = &plpeers[i_good];
NMSettingSecretFlags psk_secret_flags;
libnm: rename and expose nm_utils_base64secret_decode() in libnm A NetworkManager client requires an API to validate and decode a base64 secret -- like it is used by WireGuard. If we don't have this as part of the API, it's inconvenient. Expose it. Rename it from _nm_utils_wireguard_decode_key(), to give it a more general name. Also, rename _nm_utils_wireguard_normalize_key() to nm_utils_base64secret_normalize(). But this one we keep as internal API. The user will care more about validating and decoding the base64 key. To convert the key back to base64, we don't need a public API in libnm. This is another ABI change since 1.16-rc1. (cherry picked from commit e46ba0186720bfe5e31dcad9a5001a415deb9ce6)
2019-03-02 17:10:25 +01:00
if (!nm_utils_base64secret_decode (nm_wireguard_peer_get_public_key (peer_data->peer),
sizeof (plp->public_key),
plp->public_key))
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
continue;
*plf = NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_NONE;
plp->persistent_keepalive_interval = nm_wireguard_peer_get_persistent_keepalive (peer_data->peer);
if (NM_IN_SET (config_mode, LINK_CONFIG_MODE_FULL,
LINK_CONFIG_MODE_REAPPLY))
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_KEEPALIVE_INTERVAL;
/* if the peer has an endpoint but it is not yet resolved (not ready),
* we still configure it and leave the endpoint unspecified. Later,
* when we can resolve the endpoint, we will update. */
plp->endpoint = peer_data->ep_resolv.sockaddr;
if (plp->endpoint.sa.sa_family == AF_UNSPEC) {
/* we don't actually ever clear endpoints, if we don't have better information. */
} else
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ENDPOINT;
if (NM_IN_SET (config_mode, LINK_CONFIG_MODE_FULL,
LINK_CONFIG_MODE_REAPPLY)) {
psk_secret_flags = nm_wireguard_peer_get_preshared_key_flags (peer_data->peer);
if (!NM_FLAGS_HAS (psk_secret_flags, NM_SETTING_SECRET_FLAG_NOT_REQUIRED)) {
libnm: rename and expose nm_utils_base64secret_decode() in libnm A NetworkManager client requires an API to validate and decode a base64 secret -- like it is used by WireGuard. If we don't have this as part of the API, it's inconvenient. Expose it. Rename it from _nm_utils_wireguard_decode_key(), to give it a more general name. Also, rename _nm_utils_wireguard_normalize_key() to nm_utils_base64secret_normalize(). But this one we keep as internal API. The user will care more about validating and decoding the base64 key. To convert the key back to base64, we don't need a public API in libnm. This is another ABI change since 1.16-rc1. (cherry picked from commit e46ba0186720bfe5e31dcad9a5001a415deb9ce6)
2019-03-02 17:10:25 +01:00
if ( !nm_utils_base64secret_decode (nm_wireguard_peer_get_preshared_key (peer_data->peer),
sizeof (plp->preshared_key),
plp->preshared_key)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
&& config_mode == LINK_CONFIG_MODE_FULL)
goto skip;
}
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_PRESHARED_KEY;
}
if ( NM_IN_SET (config_mode, LINK_CONFIG_MODE_FULL,
LINK_CONFIG_MODE_REAPPLY)
&& ((n_aip = nm_wireguard_peer_get_allowed_ips_len (peer_data->peer)) > 0)) {
if (!allowed_ips)
allowed_ips = g_array_new (FALSE, FALSE, sizeof (NMPWireGuardAllowedIP));
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ALLOWEDIPS
| NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_REPLACE_ALLOWEDIPS;
plp->_construct_idx_start = allowed_ips->len;
for (i_aip = 0; i_aip < n_aip; i_aip++) {
const char *aip;
NMIPAddr addrbin = { };
int addr_family;
gboolean valid;
int prefix;
aip = nm_wireguard_peer_get_allowed_ip (peer_data->peer, i_aip, &valid);
if ( !valid
|| !nm_utils_parse_inaddr_prefix_bin (AF_UNSPEC,
aip,
&addr_family,
&addrbin,
&prefix)) {
/* the address is really not expected to be invalid, because then
* the connection would not verify. Anyway, silently skip it. */
continue;
}
if (prefix == -1)
prefix = addr_family == AF_INET ? 32 : 128;
g_array_append_val (allowed_ips,
((NMPWireGuardAllowedIP) {
.family = addr_family,
.mask = prefix,
.addr = addrbin,
}));
}
plp->_construct_idx_end = allowed_ips->len;
}
i_good++;
continue;
skip:
memset (plp, 0, sizeof (*plp));
}
if (i_good == 0)
return;
for (i = 0; i < i_good; i++) {
NMPWireGuardPeer *plp = &plpeers[i];
guint l;
if (plp->_construct_idx_end == 0) {
nm_assert (plp->_construct_idx_start == 0);
plp->allowed_ips = NULL;
plp->allowed_ips_len = 0;
} else {
nm_assert (plp->_construct_idx_start < plp->_construct_idx_end);
l = plp->_construct_idx_end - plp->_construct_idx_start;
plp->allowed_ips = &g_array_index (allowed_ips, NMPWireGuardAllowedIP, plp->_construct_idx_start);
plp->allowed_ips_len = l;
}
}
*out_peers = g_steal_pointer (&plpeers);
*out_peer_flags = g_steal_pointer (&plpeer_flags);;
*out_len = i_good;
*out_allowed_ips_data = g_steal_pointer (&allowed_ips);
}
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static void
update_properties (NMDevice *device)
{
NMDeviceWireGuard *self;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceWireGuardPrivate *priv;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
const NMPlatformLink *plink;
const NMPlatformLnkWireGuard *props = NULL;
int ifindex;
g_return_if_fail (NM_IS_DEVICE_WIREGUARD (device));
self = NM_DEVICE_WIREGUARD (device);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
ifindex = nm_device_get_ifindex (device);
props = nm_platform_link_get_lnk_wireguard (nm_device_get_platform (device), ifindex, &plink);
if (!props) {
_LOGW (LOGD_PLATFORM, "could not get wireguard properties");
return;
}
g_object_freeze_notify (G_OBJECT (device));
#define CHECK_PROPERTY_CHANGED(field, prop) \
G_STMT_START { \
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (priv->lnk_curr.field != props->field) { \
priv->lnk_curr.field = props->field; \
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
_notify (self, prop); \
} \
} G_STMT_END
#define CHECK_PROPERTY_CHANGED_ARRAY(field, prop) \
G_STMT_START { \
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (memcmp (&priv->lnk_curr.field, &props->field, sizeof (priv->lnk_curr.field)) != 0) { \
memcpy (&priv->lnk_curr.field, &props->field, sizeof (priv->lnk_curr.field)); \
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
_notify (self, prop); \
} \
} G_STMT_END
CHECK_PROPERTY_CHANGED_ARRAY (public_key, PROP_PUBLIC_KEY);
CHECK_PROPERTY_CHANGED (listen_port, PROP_LISTEN_PORT);
CHECK_PROPERTY_CHANGED (fwmark, PROP_FWMARK);
g_object_thaw_notify (G_OBJECT (device));
}
static void
link_changed (NMDevice *device,
const NMPlatformLink *pllink)
{
NM_DEVICE_CLASS (nm_device_wireguard_parent_class)->link_changed (device, pllink);
update_properties (device);
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static NMDeviceCapabilities
get_generic_capabilities (NMDevice *dev)
{
return NM_DEVICE_CAP_IS_SOFTWARE;
}
/*****************************************************************************/
static gboolean
create_and_realize (NMDevice *device,
NMConnection *connection,
NMDevice *parent,
const NMPlatformLink **out_plink,
GError **error)
{
const char *iface = nm_device_get_iface (device);
int r;
g_return_val_if_fail (iface, FALSE);
r = nm_platform_link_wireguard_add (nm_device_get_platform (device), iface, out_plink);
if (r < 0) {
g_set_error (error, NM_DEVICE_ERROR, NM_DEVICE_ERROR_CREATION_FAILED,
"Failed to create WireGuard interface '%s' for '%s': %s",
iface,
nm_connection_get_id (connection),
nm_strerror (r));
return FALSE;
}
return TRUE;
}
/*****************************************************************************/
static void
_secrets_cancel (NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
if (priv->secrets_call_id)
nm_act_request_cancel_secrets (NULL, priv->secrets_call_id);
nm_assert (!priv->secrets_call_id);
}
static void
_secrets_cb (NMActRequest *req,
NMActRequestGetSecretsCallId *call_id,
NMSettingsConnection *connection,
GError *error,
gpointer user_data)
{
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD (user_data);
NMDevice *device = NM_DEVICE (self);
NMDeviceWireGuardPrivate *priv;
g_return_if_fail (NM_IS_DEVICE_WIREGUARD (self));
g_return_if_fail (NM_IS_ACT_REQUEST (req));
priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
g_return_if_fail (priv->secrets_call_id == call_id);
priv->secrets_call_id = NULL;
if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
return;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_return_if_fail (req == nm_device_get_act_request (device));
g_return_if_fail (nm_device_get_state (device) == NM_DEVICE_STATE_NEED_AUTH);
g_return_if_fail (nm_act_request_get_settings_connection (req) == connection);
if (error) {
_LOGW (LOGD_ETHER, "%s", error->message);
nm_device_state_changed (device,
NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_NO_SECRETS);
device: let devices call stage1 again after being ready to proceed I am about to change the when stage1 gets postponed, then the way to proceed it is to schedule stage1 again (instead of scheduling stage2). The reason is that stage1 handling should be reentrant and we should keep entering it until there is no more reason to postpone it. If a subclass postpones stage1 and then later progresses it by directly scheduling stage2, then only the subclass is in control over postponing stage 2. Instead, anybody should be able to delay stage2 independently. That can only work if everybody signals readyness to proceed by scheduling stage1 again.
2019-08-22 10:43:22 +02:00
return;
}
nm_device_activate_schedule_stage1_device_prepare (device);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
static void
_secrets_get_secrets (NMDeviceWireGuard *self,
const char *setting_name,
NMSecretAgentGetSecretsFlags flags,
const char *const*hints)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
NMActRequest *req;
_secrets_cancel (self);
req = nm_device_get_act_request (NM_DEVICE (self));
g_return_if_fail (NM_IS_ACT_REQUEST (req));
priv->secrets_call_id = nm_act_request_get_secrets (req,
TRUE,
setting_name,
flags,
hints,
_secrets_cb,
self);
g_return_if_fail (priv->secrets_call_id);
}
static NMActStageReturn
_secrets_handle_auth_or_fail (NMDeviceWireGuard *self,
NMActRequest *req,
gboolean new_secrets)
{
NMConnection *applied_connection;
const char *setting_name;
gs_unref_ptrarray GPtrArray *hints = NULL;
if (!nm_device_auth_retries_try_next (NM_DEVICE (self)))
return NM_ACT_STAGE_RETURN_FAILURE;
nm_device_state_changed (NM_DEVICE (self), NM_DEVICE_STATE_NEED_AUTH, NM_DEVICE_STATE_REASON_NONE);
nm_active_connection_clear_secrets (NM_ACTIVE_CONNECTION (req));
applied_connection = nm_act_request_get_applied_connection (req);
setting_name = nm_connection_need_secrets (applied_connection, &hints);
if (!setting_name) {
_LOGI (LOGD_DEVICE, "Cleared secrets, but setting didn't need any secrets.");
return NM_ACT_STAGE_RETURN_FAILURE;
}
if (hints)
g_ptr_array_add (hints, NULL);
_secrets_get_secrets (self,
setting_name,
NM_SECRET_AGENT_GET_SECRETS_FLAG_ALLOW_INTERACTION
| (new_secrets ? NM_SECRET_AGENT_GET_SECRETS_FLAG_REQUEST_NEW : 0),
( hints
? (const char *const*) hints->pdata
: NULL));
return NM_ACT_STAGE_RETURN_POSTPONE;
}
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static void
_dns_config_changed (NMDnsManager *dns_manager, NMDeviceWireGuard *self)
{
/* when the DNS configuration changes, we re-resolve the peer addresses.
*
* Possibly, we should also do that when the default-route changes, but it's
* hard to figure out when that happens. */
_peers_resolve_reresolve_all (self);
}
/*****************************************************************************/
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static NMActStageReturn
link_config (NMDeviceWireGuard *self,
const char *reason,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
LinkConfigMode config_mode,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceStateReason *out_failure_reason)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_auto_bzero_secret_ptr NMSecretPtr wg_lnk_clear_private_key = NM_SECRET_PTR_INIT ();
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMSettingWireGuard *s_wg;
NMConnection *connection;
NMActStageReturn ret;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gs_unref_array GArray *allowed_ips_data = NULL;
NMPlatformLnkWireGuard wg_lnk;
gs_free NMPWireGuardPeer *plpeers = NULL;
gs_free NMPlatformWireGuardChangePeerFlags *plpeer_flags = NULL;
guint plpeers_len = 0;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
const char *setting_name;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gboolean peers_removed;
NMPlatformWireGuardChangeFlags wg_change_flags;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
int ifindex;
int r;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_NONE);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
connection = nm_device_get_applied_connection (NM_DEVICE (self));
s_wg = NM_SETTING_WIREGUARD (nm_connection_get_setting (connection, NM_TYPE_SETTING_WIREGUARD));
g_return_val_if_fail (s_wg, NM_ACT_STAGE_RETURN_FAILURE);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
priv->link_config_last_at = nm_utils_get_monotonic_timestamp_ns ();
_LOGT (LOGD_DEVICE, "wireguard link config (%s, %s)...",
reason, _link_config_mode_to_string (config_mode));
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
_auto_default_route_init (self);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (!priv->dns_manager) {
priv->dns_manager = g_object_ref (nm_dns_manager_get ());
g_signal_connect (priv->dns_manager, NM_DNS_MANAGER_CONFIG_CHANGED, G_CALLBACK (_dns_config_changed), self);
}
if ( NM_IN_SET (config_mode, LINK_CONFIG_MODE_FULL)
&& (setting_name = nm_connection_need_secrets (connection, NULL))) {
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMActRequest *req = nm_device_get_act_request (NM_DEVICE (self));
_LOGD (LOGD_DEVICE,
"Activation: connection '%s' has security, but secrets are required.",
nm_connection_get_id (connection));
ret = _secrets_handle_auth_or_fail (self, req, FALSE);
if (ret != NM_ACT_STAGE_RETURN_SUCCESS) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (ret != NM_ACT_STAGE_RETURN_POSTPONE) {
nm_assert (ret == NM_ACT_STAGE_RETURN_FAILURE);
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_NO_SECRETS);
}
return ret;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
}
ifindex = nm_device_get_ip_ifindex (NM_DEVICE (self));
if (ifindex <= 0) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
return NM_ACT_STAGE_RETURN_FAILURE;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_peers_update_all (self, s_wg, &peers_removed);
wg_lnk = (NMPlatformLnkWireGuard) { };
wg_change_flags = NM_PLATFORM_WIREGUARD_CHANGE_FLAG_NONE;
if ( NM_IN_SET (config_mode, LINK_CONFIG_MODE_FULL)
|| ( NM_IN_SET (config_mode, LINK_CONFIG_MODE_REAPPLY)
&& peers_removed))
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_REPLACE_PEERS;
if (NM_IN_SET (config_mode, LINK_CONFIG_MODE_FULL,
LINK_CONFIG_MODE_REAPPLY)) {
device/wireguard: fix separating lines by semicolon in link_config()
2019-07-15 11:00:01 +02:00
wg_lnk.listen_port = nm_setting_wireguard_get_listen_port (s_wg);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_LISTEN_PORT;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wg_lnk.fwmark = priv->auto_default_route_fwmark;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_FWMARK;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
libnm: rename and expose nm_utils_base64secret_decode() in libnm A NetworkManager client requires an API to validate and decode a base64 secret -- like it is used by WireGuard. If we don't have this as part of the API, it's inconvenient. Expose it. Rename it from _nm_utils_wireguard_decode_key(), to give it a more general name. Also, rename _nm_utils_wireguard_normalize_key() to nm_utils_base64secret_normalize(). But this one we keep as internal API. The user will care more about validating and decoding the base64 key. To convert the key back to base64, we don't need a public API in libnm. This is another ABI change since 1.16-rc1. (cherry picked from commit e46ba0186720bfe5e31dcad9a5001a415deb9ce6)
2019-03-02 17:10:25 +01:00
if (nm_utils_base64secret_decode (nm_setting_wireguard_get_private_key (s_wg),
sizeof (wg_lnk.private_key),
wg_lnk.private_key)) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_lnk_clear_private_key = NM_SECRET_PTR_ARRAY (wg_lnk.private_key);
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_PRIVATE_KEY;
} else {
if (NM_IN_SET (config_mode, LINK_CONFIG_MODE_FULL)) {
_LOGD (LOGD_DEVICE, "the provided private-key is invalid");
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_NO_SECRETS);
return NM_ACT_STAGE_RETURN_FAILURE;
}
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_peers_get_platform_list (priv,
config_mode,
&plpeers,
&plpeer_flags,
&plpeers_len,
&allowed_ips_data);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
r = nm_platform_link_wireguard_change (nm_device_get_platform (NM_DEVICE (self)),
ifindex,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
&wg_lnk,
plpeers,
plpeer_flags,
plpeers_len,
wg_change_flags);
device/wireguard: fix explicit_bzero() call on peers buffer in link_config() Correctly warned by coverity. (cherry picked from commit 458a2edbb24061bfd9532594e447da2e23819092)
2019-08-02 09:16:34 +02:00
nm_explicit_bzero (plpeers, sizeof (plpeers[0]) * plpeers_len);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (r < 0) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
return NM_ACT_STAGE_RETURN_FAILURE;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
return NM_ACT_STAGE_RETURN_SUCCESS;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static void
link_config_delayed (NMDeviceWireGuard *self,
const char *reason)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
gint64 now;
priv->link_config_delayed_id = 0;
if (priv->link_config_last_at != 0) {
now = nm_utils_get_monotonic_timestamp_ns ();
if (now < priv->link_config_last_at + LINK_CONFIG_RATE_LIMIT_NSEC) {
all: codespell fixes Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2'). (cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
2019-03-11 12:00:32 +01:00
/* we ratelimit calls to link_config(), because we call this whenever a resolver
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
* completes. */
_LOGT (LOGD_DEVICE, "wireguard link config (%s) (postponed)", reason);
priv->link_config_delayed_id = g_timeout_add (NM_MAX ((priv->link_config_last_at + LINK_CONFIG_RATE_LIMIT_NSEC - now) / NM_UTILS_NS_PER_MSEC,
(gint64) 1),
link_config_delayed_ratelimit_cb,
self);
return;
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
link_config (self, reason, LINK_CONFIG_MODE_ENDPOINTS, NULL);
}
static gboolean
link_config_delayed_ratelimit_cb (gpointer user_data)
{
link_config_delayed (user_data, "after-ratelimiting");
return G_SOURCE_REMOVE;
}
static gboolean
link_config_delayed_resolver_cb (gpointer user_data)
{
link_config_delayed (user_data, "resolver-update");
return G_SOURCE_REMOVE;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
static NMActStageReturn
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
act_stage2_config (NMDevice *device,
NMDeviceStateReason *out_failure_reason)
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
{
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMDeviceSysIfaceState sys_iface_state;
NMDeviceStateReason failure_reason;
NMActStageReturn ret;
sys_iface_state = nm_device_sys_iface_state_get (device);
if (sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_EXTERNAL) {
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_NONE);
return NM_ACT_STAGE_RETURN_SUCCESS;
}
ret = link_config (NM_DEVICE_WIREGUARD (device),
"configure",
(sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_ASSUME)
? LINK_CONFIG_MODE_ASSUME
: LINK_CONFIG_MODE_FULL,
&failure_reason);
if (sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_ASSUME) {
/* this never fails. */
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_NONE);
return NM_ACT_STAGE_RETURN_SUCCESS;
}
if (ret != NM_ACT_STAGE_RETURN_FAILURE) {
NM_SET_OUT (out_failure_reason, NM_DEVICE_STATE_REASON_NONE);
return ret;
}
nm_device_state_changed (device,
NM_DEVICE_STATE_FAILED,
failure_reason);
NM_SET_OUT (out_failure_reason, failure_reason);
return NM_ACT_STAGE_RETURN_FAILURE;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
static NMIPConfig *
_get_dev2_ip_config (NMDeviceWireGuard *self,
int addr_family)
{
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
gs_unref_object NMIPConfig *ip_config = NULL;
NMConnection *connection;
NMSettingWireGuard *s_wg;
guint n_peers;
guint i;
int ip_ifindex;
guint32 route_metric;
guint32 route_table_coerced;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
gboolean auto_default_route_enabled;
_auto_default_route_init (self);
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
connection = nm_device_get_applied_connection (NM_DEVICE (self));
s_wg = NM_SETTING_WIREGUARD (nm_connection_get_setting (connection, NM_TYPE_SETTING_WIREGUARD));
/* Differences to `wg-quick`.
*
* `wg-quick` supports the "Table" setting with 3 modes:
*
* a1) "off": this is what we do with "peer-routes" disabled.
*
* a2) an explicit routing table. This is our behavior with "peer-routes" on. In this case
* we honor the "ipv4.route-table" and "ipv6.route-table" settings. One difference is that
* `wg-quick` would resolve table names from /etc/iproute2/rt_tables. Our connection profiles
all: codespell fixes Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2'). (cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
2019-03-11 12:00:32 +01:00
* only contain table numbers, so that conversion from name to table must have happened
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
* before already.
*
* a3) "auto" (the default). In this case, `wg-quick` would only add the route to the
* main table, if the AllowedIP range is not yet reachable on the link. With "peer-routes"
* enabled, we don't check for that and always add the routes to the main-table
* (with 'ipv4.route-table' and 'ipv6.route-table' set to zero or RT_TABLE_MAIN (254)).
*
* Also, in "auto" mode, `wg-quick` would add special handling for /0 routes and pick
* an empty table to configure policy routing to avoid routing loops. This handling
* of routing-loops via policy routing is not yet done, and requires a separate solution
* from constructing the peer-routes here.
*/
if (!nm_setting_wireguard_get_peer_routes (s_wg))
return NULL;
ip_ifindex = nm_device_get_ip_ifindex (NM_DEVICE (self));
if (ip_ifindex <= 0)
return NULL;
route_metric = nm_device_get_route_metric (NM_DEVICE (self), addr_family);
device: support reapplying route-table Changing "ipv4.route-table" and "ipv6.route-table" was not allowed during reapply. The main difficulty for supporting that is changing the sync-mode. With route-table 0, we don't sync all tables but only the main table. So, when reapply changes from full-sync to no-full-sync, it's slightly more complicated. But it's probably not too complicated either. The change from no-full-sync to full-sync is simple: we just start doing a full-sync. The reverse change is slightly more complicated, because we need to do one last full-sync, to get rid of routes that we configured on those other tables.
2019-04-30 14:01:10 +02:00
route_table_coerced = nm_platform_route_table_coerce (nm_device_get_route_table (NM_DEVICE (self), addr_family));
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
auto_default_route_enabled = (addr_family == AF_INET)
? priv->auto_default_route_enabled_4
: priv->auto_default_route_enabled_6;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
n_peers = nm_setting_wireguard_get_peers_len (s_wg);
for (i = 0; i < n_peers; i++) {
NMWireGuardPeer *peer = nm_setting_wireguard_get_peer (s_wg, i);
guint n_aips;
guint j;
n_aips = nm_wireguard_peer_get_allowed_ips_len (peer);
for (j = 0; j < n_aips; j++) {
NMPlatformIPXRoute rt;
NMIPAddr addrbin;
const char *aip;
gboolean valid;
int prefix;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint32 rtable_coerced;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
aip = nm_wireguard_peer_get_allowed_ip (peer, j, &valid);
if ( !valid
|| !nm_utils_parse_inaddr_prefix_bin (addr_family,
aip,
NULL,
&addrbin,
&prefix))
continue;
if (prefix < 0)
prefix = (addr_family == AF_INET) ? 32 : 128;
if (!ip_config)
ip_config = nm_device_ip_config_new (NM_DEVICE (self), addr_family);
nm_utils_ipx_address_clear_host_address (addr_family, &addrbin, NULL, prefix);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
rtable_coerced = route_table_coerced;
if ( prefix == 0
&& auto_default_route_enabled) {
/* In auto-default-route mode, we place the default route in a table that
* has the same number as the fwmark. wg-quick does that too. If you don't
* like that, configure the rules and the default-route explicitly in the
* connection profile. */
rtable_coerced = nm_platform_route_table_coerce (priv->auto_default_route_fwmark);
}
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
if (addr_family == AF_INET) {
rt.r4 = (NMPlatformIP4Route) {
.network = addrbin.addr4,
.plen = prefix,
.ifindex = ip_ifindex,
.rt_source = NM_IP_CONFIG_SOURCE_USER,
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
.table_coerced = rtable_coerced,
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
.metric = route_metric,
};
} else {
rt.r6 = (NMPlatformIP6Route) {
.network = addrbin.addr6,
.plen = prefix,
.ifindex = ip_ifindex,
.rt_source = NM_IP_CONFIG_SOURCE_USER,
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
.table_coerced = rtable_coerced,
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
.metric = route_metric,
};
}
nm_ip_config_add_route (ip_config, &rt.rx, NULL);
}
}
return g_steal_pointer (&ip_config);
}
static NMActStageReturn
act_stage3_ip_config_start (NMDevice *device,
int addr_family,
gpointer *out_config,
NMDeviceStateReason *out_failure_reason)
{
gs_unref_object NMIPConfig *ip_config = NULL;
ip_config = _get_dev2_ip_config (NM_DEVICE_WIREGUARD (device), addr_family);
nm_device_set_dev2_ip_config (device, addr_family, ip_config);
return NM_DEVICE_CLASS (nm_device_wireguard_parent_class)->act_stage3_ip_config_start (device, addr_family, out_config, out_failure_reason);
}
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
static guint32
get_configured_mtu (NMDevice *device, NMDeviceMtuSource *out_source)
{
/* When "MTU" for `wg-quick up` is unset, it calls `ip route get` for
* each configured endpoint, to determine the suitable MTU how to reach
* each endpoint.
* For `wg-quick` this works very well, because whenever the script runs it
* determines the best setting at that point in time. It's simply not concerned
* with what happens later (and it's not around anyway).
*
* NetworkManager sticks around, so the right MTU would need to be re-determined
* whenever anything relevant changes. Which basically means, to re-evaluate whenever
* something related to addresses or routing changes (which happens all the time).
*
* The correct MTU indeed depends on the MTU setting of other interfaces (or routes).
* But it's still odd, that activating/deactivating a seemingly unrelated interface
* would trigger an MTU change. It's odd to explain/document and odd to implemented
* -- despite this being the reality.
*
* For now, only support configuring an explicit MTU, or leave the setting untouched.
all: codespell fixes Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2'). (cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
2019-03-11 12:00:32 +01:00
* The same limitation also applies to other "ip-tunnel" types, where we could use
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
* similar smarts for autodetecting the MTU.
*/
return nm_device_get_configured_mtu_from_connection (device,
NM_TYPE_SETTING_WIREGUARD,
out_source);
}
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
static void
_device_cleanup (NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
_peers_remove_all (priv);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
_secrets_cancel (self);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
priv->auto_default_route_initialized = FALSE;
priv->auto_default_route_priority_initialized = FALSE;
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static void
device_state_changed (NMDevice *device,
NMDeviceState new_state,
NMDeviceState old_state,
NMDeviceStateReason reason)
{
if (new_state <= NM_DEVICE_STATE_ACTIVATED)
return;
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
_device_cleanup (NM_DEVICE_WIREGUARD (device));
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static gboolean
can_reapply_change (NMDevice *device,
const char *setting_name,
NMSetting *s_old,
NMSetting *s_new,
GHashTable *diffs,
GError **error)
{
if (nm_streq (setting_name, NM_SETTING_WIREGUARD_SETTING_NAME)) {
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
/* Most, but not all WireGuard settings can be reapplied. Whitelist.
*
* MTU cannot be reapplied. */
return nm_device_hash_check_invalid_keys (diffs,
NM_SETTING_WIREGUARD_SETTING_NAME,
error,
NM_SETTING_WIREGUARD_FWMARK,
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
NM_SETTING_WIREGUARD_IP4_AUTO_DEFAULT_ROUTE,
NM_SETTING_WIREGUARD_IP6_AUTO_DEFAULT_ROUTE,
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
NM_SETTING_WIREGUARD_LISTEN_PORT,
NM_SETTING_WIREGUARD_PEERS,
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
NM_SETTING_WIREGUARD_PEER_ROUTES,
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
NM_SETTING_WIREGUARD_PRIVATE_KEY,
NM_SETTING_WIREGUARD_PRIVATE_KEY_FLAGS);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
return NM_DEVICE_CLASS (nm_device_wireguard_parent_class)->can_reapply_change (device,
setting_name,
s_old,
s_new,
diffs,
error);
}
static void
reapply_connection (NMDevice *device,
NMConnection *con_old,
NMConnection *con_new)
{
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD (device);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
gs_unref_object NMIPConfig *ip4_config = NULL;
gs_unref_object NMIPConfig *ip6_config = NULL;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
priv->auto_default_route_refresh = TRUE;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
ip4_config = _get_dev2_ip_config (self, AF_INET);
ip6_config = _get_dev2_ip_config (self, AF_INET6);
nm_device_set_dev2_ip_config (device, AF_INET, ip4_config);
nm_device_set_dev2_ip_config (device, AF_INET6, ip6_config);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_DEVICE_CLASS (nm_device_wireguard_parent_class)->reapply_connection (device,
con_old,
con_new);
link_config (NM_DEVICE_WIREGUARD (device),
"reapply",
LINK_CONFIG_MODE_REAPPLY,
NULL);
}
/*****************************************************************************/
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static void
update_connection (NMDevice *device, NMConnection *connection)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (device);
NMSettingWireGuard *s_wg = NM_SETTING_WIREGUARD (nm_connection_get_setting (connection, NM_TYPE_SETTING_WIREGUARD));
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
const NMPObject *obj_wg;
const NMPObjectLnkWireGuard *olnk_wg;
guint i;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (!s_wg) {
s_wg = NM_SETTING_WIREGUARD (nm_setting_wireguard_new ());
nm_connection_add_setting (connection, NM_SETTING (s_wg));
}
g_object_set (s_wg,
NM_SETTING_WIREGUARD_FWMARK,
(guint) priv->lnk_curr.fwmark,
NM_SETTING_WIREGUARD_LISTEN_PORT,
(guint) priv->lnk_curr.listen_port,
NULL);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
obj_wg = NMP_OBJECT_UP_CAST (nm_platform_link_get_lnk_wireguard (nm_device_get_platform (device),
nm_device_get_ip_ifindex (device),
NULL));
if (!obj_wg)
return;
olnk_wg = &obj_wg->_lnk_wireguard;
for (i = 0; i < olnk_wg->peers_len; i++) {
nm_auto_unref_wgpeer NMWireGuardPeer *peer = NULL;
const NMPWireGuardPeer *ppeer = &olnk_wg->peers[i];
peer = nm_wireguard_peer_new ();
_nm_wireguard_peer_set_public_key_bin (peer, ppeer->public_key);
nm_setting_wireguard_append_peer (s_wg, peer);
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static void
get_property (GObject *object, guint prop_id,
GValue *value, GParamSpec *pspec)
{
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD (object);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
switch (prop_id) {
case PROP_PUBLIC_KEY:
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_value_take_variant (value,
g_variant_new_fixed_array (G_VARIANT_TYPE_BYTE,
priv->lnk_curr.public_key,
sizeof (priv->lnk_curr.public_key),
1));
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
break;
case PROP_LISTEN_PORT:
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_value_set_uint (value, priv->lnk_curr.listen_port);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
break;
case PROP_FWMARK:
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_value_set_uint (value, priv->lnk_curr.fwmark);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static void
nm_device_wireguard_init (NMDeviceWireGuard *self)
{
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
c_list_init (&priv->lst_peers_head);
priv->peers = g_hash_table_new (_peer_data_hash, _peer_data_equal);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static void
dispose (GObject *object)
{
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD (object);
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
_device_cleanup (self);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
G_OBJECT_CLASS (nm_device_wireguard_parent_class)->dispose (object);
}
static void
finalize (GObject *object)
{
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD (object);
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE (self);
nm_explicit_bzero (priv->lnk_curr.private_key, sizeof (priv->lnk_curr.private_key));
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (priv->dns_manager) {
g_signal_handlers_disconnect_by_func (priv->dns_manager, _dns_config_changed, self);
g_object_unref (priv->dns_manager);
}
device/wireguard: fix memleak for NMDeviceWireGuard Fixes: 2148d0948202 ('core/wireguard: add support for WireGuard peers')
2019-05-03 11:03:01 +02:00
g_hash_table_destroy (priv->peers);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
G_OBJECT_CLASS (nm_device_wireguard_parent_class)->finalize (object);
}
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static const NMDBusInterfaceInfoExtended interface_info_device_wireguard = {
.parent = NM_DEFINE_GDBUS_INTERFACE_INFO_INIT (
NM_DBUS_INTERFACE_DEVICE_WIREGUARD,
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS (
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE ("PublicKey", "ay", NM_DEVICE_WIREGUARD_PUBLIC_KEY),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE ("ListenPort", "q", NM_DEVICE_WIREGUARD_LISTEN_PORT),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE ("FwMark", "u", NM_DEVICE_WIREGUARD_FWMARK),
),
),
};
static void
nm_device_wireguard_class_init (NMDeviceWireGuardClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
NMDBusObjectClass *dbus_object_class = NM_DBUS_OBJECT_CLASS (klass);
NMDeviceClass *device_class = NM_DEVICE_CLASS (klass);
object_class->get_property = get_property;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
object_class->dispose = dispose;
object_class->finalize = finalize;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
dbus_object_class->interface_infos = NM_DBUS_INTERFACE_INFOS (&interface_info_device_wireguard);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->connection_type_supported = NM_SETTING_WIREGUARD_SETTING_NAME;
device_class->connection_type_check_compatible = NM_SETTING_WIREGUARD_SETTING_NAME;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES (NM_LINK_TYPE_WIREGUARD);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->state_changed = device_state_changed;
device_class->create_and_realize = create_and_realize;
device_class->act_stage2_config = act_stage2_config;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
device_class->act_stage2_config_also_for_external_or_assume = TRUE;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
device_class->act_stage3_ip_config_start = act_stage3_ip_config_start;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->get_generic_capabilities = get_generic_capabilities;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
device_class->link_changed = link_changed;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->update_connection = update_connection;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
device_class->can_reapply_change = can_reapply_change;
device_class->reapply_connection = reapply_connection;
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
device_class->get_configured_mtu = get_configured_mtu;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
device_class->get_extra_rules = get_extra_rules;
device_class->coerce_route_table = coerce_route_table;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
obj_properties[PROP_PUBLIC_KEY] =
g_param_spec_variant (NM_DEVICE_WIREGUARD_PUBLIC_KEY,
"", "",
G_VARIANT_TYPE ("ay"),
NULL,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
obj_properties[PROP_LISTEN_PORT] =
g_param_spec_uint (NM_DEVICE_WIREGUARD_LISTEN_PORT,
"", "",
0, G_MAXUINT16, 0,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
obj_properties[PROP_FWMARK] =
g_param_spec_uint (NM_DEVICE_WIREGUARD_FWMARK,
"", "",
0, G_MAXUINT32, 0,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
g_object_class_install_properties (object_class, _PROPERTY_ENUMS_LAST, obj_properties);
}
/*************************************************************/
#define NM_TYPE_WIREGUARD_DEVICE_FACTORY (nm_wireguard_device_factory_get_type ())
#define NM_WIREGUARD_DEVICE_FACTORY(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_WIREGUARD_DEVICE_FACTORY, NMWireGuardDeviceFactory))
static NMDevice *
create_device (NMDeviceFactory *factory,
const char *iface,
const NMPlatformLink *plink,
NMConnection *connection,
gboolean *out_ignore)
{
return (NMDevice *) g_object_new (NM_TYPE_DEVICE_WIREGUARD,
NM_DEVICE_IFACE, iface,
NM_DEVICE_TYPE_DESC, "WireGuard",
NM_DEVICE_DEVICE_TYPE, NM_DEVICE_TYPE_WIREGUARD,
NM_DEVICE_LINK_TYPE, NM_LINK_TYPE_WIREGUARD,
NULL);
}
NM_DEVICE_FACTORY_DEFINE_INTERNAL (WIREGUARD, WireGuard, wireguard,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NM_DEVICE_FACTORY_DECLARE_LINK_TYPES (NM_LINK_TYPE_WIREGUARD)
NM_DEVICE_FACTORY_DECLARE_SETTING_TYPES (NM_SETTING_WIREGUARD_SETTING_NAME),
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
factory_class->create_device = create_device;
)
Reference in a new issue Copy permalink