GNOME Bugzilla – Bug 758702
[RFE] "bypass/exclude" routes for VPNs, special route gateways
Last modified: 2020-11-12 14:30:04 UTC
Currently NetworkManager sets up the default route through the VPN, and adds a direct route for the VPN server itself (through the LAN gateway). It would be very useful if NM could also add *custom* routes the same way – for example, use the LAN gateway for 10.0.0.0/8, but keep using the VPN for everything else. (The existing "static routes" feature is insufficient here, since the gateway might change depending on where I connect from. The kernel's automatic "link routes" are also insufficient, since I want to exclude several ranges, not just my own LAN subnet.) For comparison, OpenVPN supports a magic value "net_gateway" in its --route option for this purpose.
Nice feature. maybe in general, we could extend the configuration for routes to add a special "default-gateway" value that means: use the current IPvX default-gateway for the route. On the D-Bus API, routes are already transmitted as a tuple: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/libnm-core/nm-utils.c?id=39e97c9339a189ce378a72025c05192fecbaf58b#n2005 So, instead of setting "next-hop" to be a IP address (or absent, which equals "0.0.0.0"), it could be "default".
maybe we could even support the gateway like: "interface:eth0" (but that's more complicated)
Agreed this would be nice. But its use is not only limited to VPN, you might for some reason want to have a more-specific using the default gateway on a less-preferred interface as a next-hop (say, prefer to use 192.0.2.0/24 and 2001:db8::/32 via the default router on a wifi interface even though a cabled interface is connected). This would be easy to do if the magic "default" next-hop value was recognised on the ipv[46].routes property of the wifi interface the route is bound to (as opposed to being specified on the VPN interface it is supposed to be excluded from). And it'd mean "the same as the default route next-hop on *this* interface/connection, even though that's not the system default at any given time» That would mean that when the VPN (or cabled interface) is disconnected, the route would still be there and redundant, but that's not a big deal I think. Tore
*** Bug 781575 has been marked as a duplicate of this bug. ***
Originally this feature talks about the default-gateway (which openvpn calls "net_gateway"). But it also makes sense for the dynamically received gateway from the same connection (openvpn's "vpn_gateway"). And, it should not be limited to VPN, it is generally useful. These should all be handled together.
*** Bug 796001 has been marked as a duplicate of this bug. ***
coming from a duplicate #796001: yes, ability to define route's gateway dynamically as current connection's gateway would also be useful for DHCP profiles where the gateway is not known beforehand or can change. Also, specifying another interface's gateway is a cool idea too. Need to generalize the keyword: gateway - use current connection's gateway gateway:dev:eth0 - use gateway on eth0 device gateway:con:myprofile - use gateway from device where 'myprofile' connection is currently active
*** Bug 796433 has been marked as a duplicate of this bug. ***
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).