This is as intended and as implemented.

The default-routes on all the interfaces persist, not only the default-route on the "best" device.

As these routes have different metrics, the right route will be chosen by kernel.


Does this cause an actual problem for you?

Hi,

Jumping in here after a redirect from 1294309.

I guess my superficial discomfort with what NM is
doing here comes from the jarring sight of seeing
the old default route still there at all when my
server configuration says it should be gone. It
took a while to notice the game being played with
the metric settings. If some other bug or
misconfiguration deletes the default route through
the tunnel, the protection it offers will silently
vanish.  That other tunneled routes (e.g., to a
subnet behind the server) might persist makes it
even less likely the fault would be noticed.

More importantly, NM is suppressing server side
option settings in favor of its own view that one
configuration fits all use cases. It likewise
preempts configuration choices which might be made
by the local sysadmin. Well, one configuration
most emphatically does not fit all use cases.

I have situations where I need to bring up two
VPNs to a couple of different servers. One pushes
redirect-gateway and one does not. This is
deliberate, as the second server does not do
forwarding to the greater Internet.

In another case there is one server pushing routes
for at least one (but sometimes three or four)
clients so routing occurs among the hosts on the
subnets behind the server and clients. A mobile
client occasionally connects to the server in
order to reach all the other networks. In this
case it's typical the server does not push
redirect-gateway though that might be needed at
times.

Setting up traditional manually edited
configuration files and starting openvpn with
systemctl partly addresses these use cases. But if
openvpn is (prudently) configured to run as
nobody:nobody after the routing is set up, it
can't undo its routing changes when it's brought
down.

Ideally I would like to see NM's current behavior
simply be an option, a check-box set on by
default. If unchecked, what the server pushes is
honored instead.  Granted, this means NM would
have to keep track of each tunnel's routing
choices and undo them when that particular
connection is taken down. 

It would also be very useful to be able to bring
up multiple openvpn connections.  Since it's
entirely possible that servers might push
conflicting options, another option is necessary
to disregard routes pushed from the server. And
finally, an open format text box allowing
per-connection entry of openvpn command line
options should cover most all of the remaining
corner cases. Alternatively this could be
accomplished with an entry for specifying the name
of a traditional openvpn config file. That might
also be a way to allow for openvpn server setup
and control using NM.

(In reply to Dennis W. Tokarski from comment #2)
> Hi,
> 
> Jumping in here after a redirect from 1294309.
> 
> I guess my superficial discomfort with what NM is
> doing here comes from the jarring sight of seeing
> the old default route still there at all when my
> server configuration says it should be gone. It
> took a while to notice the game being played with
> the metric settings. If some other bug or
> misconfiguration deletes the default route through
> the tunnel, the protection it offers will silently
> vanish.  That other tunneled routes (e.g., to a
> subnet behind the server) might persist makes it
> even less likely the fault would be noticed.

If you have a buggy script that wrongly messes with your routes, your
expectancy of protection is low in the first place.


This bug is about NM adding an additional route to another destination with lower metric.

Say, NM wouldn't do this and only add the highest priority route. You are connected to vpn0 and eth0 with default-route via vpn0.
If your script deletes that route, NM would think: "Oh, the user doesn't want to have a default-route via vpn0 anymore, I got to restore eth0's route". And 10 milliseconds later won't be protected either.

Actually, the main reason to add the shadowed route right away is to avoid those 10 msec outage.



You ask for something else. You want that activating vpn0 prevents certain routes via eth0. But for how long? Only until vpn0 disconnects? That would mean after vpn0 disconnects, NM would again re-add the route via eth0 and you are not protected.

Well, surely this should be improved. Related:
  https://bugzilla.gnome.org/show_bug.cgi?id=749376
  https://bugzilla.gnome.org/show_bug.cgi?id=748442
  https://bugzilla.redhat.com/show_bug.cgi?id=1322932


This bug is merely about whether the shadowed, lower-priority route is a problem. Up to now I think it is not.


btw, if you want to ensure that eth0 doesn't get the default route, you could modify eth0's connection to be never-default=yes. You could have two connections, "eth0-with-default" and "eth0-without-default". And when you want to use VPN, you activate "eth0-without-default" + the VPN connection.




 
> More importantly, NM is suppressing server side
> option settings in favor of its own view that one
> configuration fits all use cases. It likewise
> preempts configuration choices which might be made
> by the local sysadmin. Well, one configuration
> most emphatically does not fit all use cases.
>
> I have situations where I need to bring up two
> VPNs to a couple of different servers. One pushes
> redirect-gateway and one does not. This is
> deliberate, as the second server does not do
> forwarding to the greater Internet.
> 
> In another case there is one server pushing routes
> for at least one (but sometimes three or four)
> clients so routing occurs among the hosts on the
> subnets behind the server and clients. A mobile
> client occasionally connects to the server in
> order to reach all the other networks. In this
> case it's typical the server does not push
> redirect-gateway though that might be needed at
> times.
> 
> Setting up traditional manually edited
> configuration files and starting openvpn with
> systemctl partly addresses these use cases. But if
> openvpn is (prudently) configured to run as
> nobody:nobody after the routing is set up, it
> can't undo its routing changes when it's brought
> down.
> 
> Ideally I would like to see NM's current behavior
> simply be an option, a check-box set on by
> default. If unchecked, what the server pushes is
> honored instead.  Granted, this means NM would
> have to keep track of each tunnel's routing
> choices and undo them when that particular
> connection is taken down. 
> 
> It would also be very useful to be able to bring
> up multiple openvpn connections.  Since it's
> entirely possible that servers might push
> conflicting options, another option is necessary
> to disregard routes pushed from the server. And
> finally, an open format text box allowing
> per-connection entry of openvpn command line
> options should cover most all of the remaining
> corner cases. Alternatively this could be
> accomplished with an entry for specifying the name
> of a traditional openvpn config file. That might
> also be a way to allow for openvpn server setup
> and control using NM.


Let's focus on the issue at hand. One bug should be
about one issue.

Related to what you said:
  https://bugzilla.gnome.org/show_bug.cgi?id=762911
  https://bugzilla.gnome.org/show_bug.cgi?id=760917#c1

(In reply to Thomas Haller from comment #3)

> You ask for something else. You want that activating vpn0 prevents certain
> routes via eth0. But for how long? Only until vpn0 disconnects? That would
> mean after vpn0 disconnects, NM would again re-add the route via eth0 and
> you are not protected.

In other words: NetworkManager currently has no concept of "one connection preventing routes on another connection". It does not understand, that you want to prevent routes on eth0 when activating vpn0. 

Fixing that is a valid RFE and what the mentioned upstream bugs are about.

The original bug reporter had two connections, both a with a default-route configured. And that is what NetworkManager does. The shadowed route there doesn't really hurt in that case (or does it??).

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.