Comment 29 for bug 269071

Xamusk,

it sounds weird, but the _real_ bug here is that OpenVPN does not pass the default route to NetworkManager. It only passes some /32-routes that's the link networks used by the OpenVPN server (given by the "server" statement in the server configuration file). There is as far as I've understood _no_ way for NetworkManager to detect that the server is using "redirect-gateway" or not. But this bug is, as I've understood it, in OpenVPN - not NetworkManager.

NetworkManager works around it, though. If the OpenVPN server does not push _any_ routes at all, NM figures that "since OpenVPN doesn't advertise any routes at all, I'm going to assume that it wants the default route, since a VPN tunnel with no routes to it is quite pointless". That's how it should look to NM if only redirect-gateway is in use... only that it doesn't. This workaround didn't take into account that the OpenVPN server (or client, I'm not sure) also announces a /32-route to the OpenVPN server's link network, regardless of this being configured in the server or not. So you end up in the situation where NM says "oh look, it told me to route these /32s over the tunnel, no need to apply the if-no-routes-then-set-default-route workaround then", and only the /32s are added.

It was fixed upstream, by simply making the workaround code disregard /32s when deciding to assume that the default route should be added or not. So when you set «Ignore automatically obtained routes», you do indeed make NM ignore those /32s, which in turn makes it apply the workaround since it can't see any routes at all. If you however add your own static routes in addition to setting the «ignore» option, you'll probably see that the default route is _not_ added (since these routes prevent the workaround to come into effect).

I hope that cleared it up - I was confused about the same at first, too. See the GNOME bug tracker for more comments from the upstream developer.

Tore