diff options
author | Thomas Haller <thaller@redhat.com> | 2020-04-22 10:46:17 +0200 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2020-04-22 15:05:39 +0200 |
commit | 112e8aff5ba61116585b5577124d3776aa9ff568 (patch) | |
tree | b9f43599d6037c480e2a4e19e3b9e358cb1de248 /src/nm-ip6-config.c | |
parent | 0cb5343ce281ad6e91a75d3f244e57fa0791ac56 (diff) | |
download | NetworkManager-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.c | 3 |
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; |