Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1275012
Summary: | default route not deleted when server pushes redirect-gateway | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dimitris <dimitris> |
Component: | NetworkManager-openvpn | Assignee: | Lubomir Rintel <lkundrak> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | choeger, dcbw, dwt, huzaifas, lkundrak, psimerda, steve, thaller |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-19 18:19:49 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dimitris
2015-10-25 00:00:11 UTC
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. |