GNOME Bugzilla – Bug 762911
server's `push "redirect-private"` ignored
Last modified: 2020-11-12 14:28:10 UTC
with an openvpn server that pushes the `redirect-private` option, a regular openvp client would not set a default route via the vpn (eg. when the vpn is only used to access a local network), but network-manager nevertheless sets the route. server config (certificate config omitted): server 10.5.22.0 255.255.255.0 dev tun client-to-client push "redirect-private" regular client invocation that does not create a default route: openvpn --remote ... 1194 udp --dev tun --auth-nocache --client --ca ca.crt --cert myhost.crt --key myhost.key setting up the vpn with networkmanager and default options, a default route (that does not get routed by the server because it advertises against it so it's not configured) is added nevertheless. that can be worked-around by setting the "use this connection only for resources on its network" flag, but that should not be necessary. this was tested on a debian sid (network-manager 1.1.90-6) on the client and debian wheezy on the server (openvpn 2.2.1-8+deb7u3).
does redirect-private mean the server will not forward the default-route (i.e., it doesn't work)? Or does it mean the client should not use it as default route? Server configuration should not overrule client configuration, unless the configuration is not applicable because the server *really* doesn't forward the traffic (which, NetworkManager cannot really know). The "use this connection only for resources on its network" flag is called ipv4.never-default and it can only have the values yes|no. It cannot be set to "let-server-decide". But maybe it should...
don't take my word for it as i've just yesterday started setting up an openvpn server, but it is my impression that the "push" option allows the server to indicate to the client openvpn options that it suggest it better use. the default behavior is for openvpn to set a default route through the vpn, and `push "redirect-private"` makes the client not do that. it's thus not actual "server configuration", but rather a server's instructions to the client on what it should do with that connections. whether the server actually would forward packages is a matter of its ip settings and unrelated to openvpn, but a well-configured server that doesn't route would probably send that option to avoid implicitly advertising a route it does not serve. as for never-default, as i've now tried out, it seems not to exactly do what openvpn w/o network-manager does: with that setting on, i only get the point-to-point route and need to manualy add the route to the vpn's network (which is actively used in a client-to-client setting), while default openvpn sets the complete vpn subnet as routable through the tun device. as said, i'm not too familiar with openvpn as is, but i've observed that nm-managed openvpn doesn't work out of the box when a plain openvpn does, and nm should mimic the resulting behavior.
(In reply to chrysn from comment #2) > as for never-default, as i've now tried out, it seems not to exactly do what > openvpn w/o network-manager does: with that setting on, i only get the > point-to-point route and need to manualy add the route to the vpn's network > (which is actively used in a client-to-client setting), while default > openvpn sets the complete vpn subnet as routable through the tun device. "never-default" is in the UI called "use this connection only for resources on its network". Although you say differently, it ~should~ only affect whether there is a default-route(?). If set to "yes", the device will not receive the default-route. If set to "no", the device might receive the default-route if possible -- e.g. if we receive a gateway via DHCP. This ignores whatever the server says. (In reply to chrysn from comment #2) > it's thus > not actual "server configuration", but rather a server's instructions to the > client on what it should do with that connections. You basically ask for a third setting "no-unless-server-says-redirect-private", which is o course a valid request...
(In reply to Thomas Haller from comment #3) > If set to "yes", the device will not receive the default-route. > > If set to "no", the device might receive the default-route if possible -- > e.g. if we receive a gateway via DHCP. This ignores whatever the server says. the server would be ignored in the "yes" setting; in the "no" setting, it should listen to it. note that the route indication is a little backwards: instead of the server telling the client about a default gateway (which it does in dhcp), the client assumes that the vpn is a suitable default route *unless* the server tells it otherwise by `push "redirect-private"`. afaict, there is no dhcp involved here at all. > You basically ask for a third setting > "no-unless-server-says-redirect-private", which is o course a valid > request... i suppose the current settings are sufficient (one would need to argue for whether there's a use case for making the vpn the default route even though the server told the client not to), nm would just need to interpret "no" as "make this a default route unless the server says otherwise". ---- there seems to be a partially related issue i'd rather discuss here than open a new ticket for, let's call it "the whole-subnet issue": even with never-default=yes, the client's behavior differs from the well-functioning default openvpn behavior. i state that the issue is related to the above because as soon as never-default=no starts behaving like never-default=yes when the server sends `push "redirect-private"`, it would surface on clients in the default configuration: > Although you say differently, it ~should~ only affect whether there is a > default-route(?). yes...ish. the difference in nm between the setting on and off is whether a *default* route is added, but neither does what the openvpn client by default in a `push "redirect-private"` situation does, because that adds a *subnet* route: * new (relevant[1]) routes from nm with never-default=off: default via 10.5.22.5 dev tun0 proto static metric 50 10.5.22.5 dev tun0 proto kernel scope link src 10.5.22.6 metric 50 * new routes with never-default=on: 10.5.22.5 dev tun0 proto kernel scope link src 10.5.22.6 metric 50 * new routes with plain openvpn: 10.5.22.0/24 via 10.5.22.5 dev tun0 10.5.22.5 dev tun0 proto kernel scope link src 10.5.22.6 i'm not sufficiently deep into openvpn to tell whether the never-default=on setting works ever at all (i can't even ping my vpn server until i manually `ip r add 10.5.22.0/24 dev tun0`), but it seems rather impractical to me. [1]: i'm omitting the new hard-coded route that shows up to ensure reachability of the vpn server
As of now, this seems impossible to implement, since 'push "redirect-gateway/redirect-private"' are not visible in the environment. The following pull request is a first attempt to fix that: https://github.com/OpenVPN/openvpn/pull/69
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).