metrics on pushed routes not applied

Bug #1831483 reported by Paul Collins
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
NetworkManager-OpenVPN
Expired
Medium
network-manager-openvpn (Ubuntu)
Triaged
Low
Unassigned

Bug Description

We have a couple of VPN endpoints located in different places. These each provide access to a bunch of things located in both places. We decided that it would be a good idea to let people connect to both endpoints so that by adjusting the metrics on the pushed routes (we used 500 and 1000) our users would always use the shortest available path.

This works great with vanilla openvpn, but when using network-manager-openvpn, the metrics are lost and instead "50" is used, which means that only one gateway is used. Ideally network-manager-openvpn would use the supplied metrics so that traffic is routed as intended.

This seems to affect network-manager-openvpn in releases of Ubuntu up to 18.04 LTS, and possibly beyond.

Revision history for this message
In , Mihaly-orosz (mihaly-orosz) wrote :

Properly set openvpn client config works in NetworkManager-openvpn, but the static rutes that are pushed from the server are created with wrong metric (50 instead of 301)
Relevant config directives on server side:
push "route 192.168.100.0 255.255.255.0 vpn_gateway 301"

routing table on client after the connection has been set up:
192.168.100.0/24 via 192.168.17.222 dev tun0 proto static metric 50

Desired behaviour would be to set up the static route as follows:
192.168.100.0/24 via 192.168.17.222 dev tun0 proto static metric 301

Revision history for this message
In , Thomas Haller (thaller-1) wrote :

You can configure the metric of the routes via ipv4.route-metric property (where "-1" means default [1]).

The metrics specified by the server are ignored.

I'm not convinced that it is desirable to let the server determine the route metric for the client. But yes, maybe that would be a valuable feature...

[1] The default value depends on the device type (being 50 for VPN). You can also configure that default value in a global configuration file.

Revision history for this message
In , Mihaly-orosz (mihaly-orosz) wrote :

You are right, but default metric and route-metric can be set globally only, not for route by route. In my setup i have several static routes pushed by the server with different metrics. I am working in an environment where the offices uses their own subnet, and are interconnected via a corporate management VPN server. If you are in one of the offices you have a direct route to one of the subnets, but the others are reachable only through the management VPN server.

So most of the time one of the local subnets is overlapping with one of the static routes coming from the VPN server.

It would be nice if you would be able to instruct networkmanager to accept static route metrics from the server, like having a property called:
ipv4.route-metric-accept-remote
whrere 0 means ignore 1 means accept.

Revision history for this message
In , Thomas Haller (thaller-1) wrote :

The route-metric has a per-device-type-default [1] and this global default can be overwritten (globally) [2].\

But more importantly, you can configure the route-metric per-connection too. Ok, it's not as granular as "route by route", but it's also more then "can be set globally only"!

I suspect that is sufficient to model your use-case, or why not?
Say, you connect to your office sites via a ethernet connection. If you configure it to have route-metric 49, then you'll get:

 default via eth0 metric 49
 172.16.42.0/24 via eth0 metric 49
 172.16.0.0/16 via vpn metric 50

if you plugin your notebook in office-site #2 you'll get:

 default via eth0 metric 49
 172.16.23.0/24 via eth0 metric 49
 172.16.0.0/16 via vpn metric 50

[1] 50 for VPN, 100 for ethernet, 600 for Wi-Fi, etc.
[2] see CONNECTION SECTION in `man NetworkManager.conf`

Revision history for this message
In , Mihaly-orosz (mihaly-orosz) wrote :

You are right, we can manage it if we set up all of the client computers and change their ethernet metrics for the office connections. But it is just a workaround and causes extra administration work. Having a "full featured" openvpn implementation in networkmanager would be better.

Nevertheless this setup has been working for several years in native openvpn clients both on linux and on windows. We have problem only with linux distros started to use networkmanager.

To sum up; i would like to suggest to consider the implementation of the feature of accepting server pushed metrics for static routes in networkmanager. I hope it can be included into your development roadmap.

Thank you,
Mihaly

Revision history for this message
In , Thomas Haller (thaller-1) wrote :

I do agree that this can be a useful feature. I was trying to understand whether there is an alternative/workaround for your scenario.

Revision history for this message
In , Thomas Haller (thaller-1) wrote :

btw, instead of configuring your ethernet's route-metric to be 49, you can also configure you VPN's route-metric to be high enough (for example >= 101).

As you already have to deploy the VPN connection on all your client machines, this involves no additional configuration effort.

Revision history for this message
In , Mihaly-orosz (mihaly-orosz) wrote :

Thank you! I really appreciate your help.
I hope we can see the feature implemented soon! :)
Mihaly

Paul Collins (pjdc)
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, it looks like the issue was already discussed upstream on https://bugzilla.gnome.org/show_bug.cgi?id=760264

Changed in network-manager-openvpn (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in network-manager-openvpn:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Andre Klapper (a9016009) wrote :

bugzilla.gnome.org is being shut down in favor of a GitLab instance.
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).

Changed in network-manager-openvpn:
status: Confirmed → Expired
Revision history for this message
Haw Loeung (hloeung) wrote :

Any updates on this? We're still getting reports of issues from users where we have two VPN endpoints each pushing routes with different metrics for preferred routes / path.

We've had to work around this with smaller prefixes.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.