Unfortunately, that patch is just a partial workaround for a very limited use case. If the sysadmin ever tries to override more than a single IP through the route push mechanism of openvpn (i.e., something larger than a /32), this hack will stop to do what it did. Also, NetworkManager still sets a bogus route to your router through tun0, causing all kinds of hard to diagnose breakage.
The problem is that NetworkManager's OpenVPN handling tries to infer if it needs to set a host route to reach a remote gateway, rather than just using the explicit interface passed as part of OpenVPN's "route push".
For a proper fix, nm should pass the interface for each route all the way down to rtnl_route_add. That's a non trivial amount of work, which is probably why the effort stalled upstream.
Unfortunately, that patch is just a partial workaround for a very limited use case. If the sysadmin ever tries to override more than a single IP through the route push mechanism of openvpn (i.e., something larger than a /32), this hack will stop to do what it did. Also, NetworkManager still sets a bogus route to your router through tun0, causing all kinds of hard to diagnose breakage.
The problem is that NetworkManager's OpenVPN handling tries to infer if it needs to set a host route to reach a remote gateway, rather than just using the explicit interface passed as part of OpenVPN's "route push".
For a proper fix, nm should pass the interface for each route all the way down to rtnl_route_add. That's a non trivial amount of work, which is probably why the effort stalled upstream.