summaryrefslogtreecommitdiff
path: root/src/nm-ip6-config.c
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2020-04-22 10:46:17 +0200
committerThomas Haller <thaller@redhat.com>2020-04-22 15:05:39 +0200
commit112e8aff5ba61116585b5577124d3776aa9ff568 (patch)
treeb9f43599d6037c480e2a4e19e3b9e358cb1de248 /src/nm-ip6-config.c
parent0cb5343ce281ad6e91a75d3f244e57fa0791ac56 (diff)
downloadNetworkManager-112e8aff5ba61116585b5577124d3776aa9ff568.tar.gz
wireguard: don't let explicit gateway override WireGuard's peer route
The profile's "ipv4.gateway" and "ipv6.gateway" has only one real purpose: to define the next hop of a static default route. Usually, when specifying a gateway in this way, the default route from other addressing methods (like DHCPv4 or IPv6 autoconf) gets ignored. If you have a WireGuard peer with "AllowedIPs=0.0.0.0/0" and "wireguard.peer-routes" enabled, NetworkManager would automatically add a route to the peer. Previously, if the user also set a gateway, that route was suppressed. That doesn't feel right. Note that configuring a gateway on a WireGuard profile is likely to be wrong to begin with. At least, unless you take otherwise care to avoid routing loops. If you take care, setting a gateway may work, but it would feel clearer to instead just add an explicit /0 manual route instead. Also, note that usually you don't need a gateway anyway. WireGuard is a Layer 3 (IP) tunnel, where the next hop is alway just the other side of the tunnel. The next hop has little effect on the routes that you configure on a WireGuard interface. What however matters is whether a default route is present or not. Also, an explicit gateway probably works badly with "ipv[46].ip4-auto-default-route", because in that case the automatism should add a /0 peer-route route in a separate routing table. The explicit gateway interferes with that too. Nonetheless, without this patch it's not obvious why the /0 peer route gets suppressed when a gateway is set. Don't allow for that, and always add the peer-route. Probably the profile's gateway setting is still wrong and causes the profile not to work. But at least, you see all routes configured, and it's clearer where the (wrong) default route to the gateway comes from. (cherry picked from commit 115291a46f52ee4adfe85264b9566d216bcb25e8)
Diffstat (limited to 'src/nm-ip6-config.c')
-rw-r--r--src/nm-ip6-config.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/src/nm-ip6-config.c b/src/nm-ip6-config.c
index 3f2c465bda..b60e8057cb 100644
--- a/src/nm-ip6-config.c
+++ b/src/nm-ip6-config.c
@@ -876,7 +876,8 @@ nm_ip6_config_merge (NMIP6Config *dst,
nm_ip_config_iter_ip6_route_for_each (&ipconf_iter, src, &r_src) {
if (NM_PLATFORM_IP_ROUTE_IS_DEFAULT (r_src)) {
- if (NM_FLAGS_HAS (merge_flags, NM_IP_CONFIG_MERGE_NO_DEFAULT_ROUTES))
+ if ( NM_FLAGS_HAS (merge_flags, NM_IP_CONFIG_MERGE_NO_DEFAULT_ROUTES)
+ && !NM_FLAGS_HAS (src_priv->config_flags, NM_IP_CONFIG_FLAGS_IGNORE_MERGE_NO_DEFAULT_ROUTES))
continue;
if (default_route_metric_penalty) {
NMPlatformIP6Route r = *r_src;