Since the yum update that included /var/log/yum.log:Jan 08 10:55:00 Updated: NetworkManager-glib.x86_64 1:0.7.0-1.git20090102.fc10 /var/log/yum.log:Jan 08 10:55:09 Updated: NetworkManager.x86_64 1:0.7.0-1.git20090102.fc10 /var/log/yum.log:Jan 08 10:55:21 Updated: NetworkManager-vpnc.x86_64 1:0.7.0-1.svn13.fc10 /var/log/yum.log:Jan 08 10:55:25 Updated: NetworkManager-openvpn.x86_64 1:0.7.0-18.svn11.fc10 /var/log/yum.log:Jan 08 10:55:37 Updated: NetworkManager-gnome.x86_64 1:0.7.0-1.git20090102.fc10 I did not have networking over VPN, even tho the client is connected and authenticated to the gatway. i had to revert to NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10.x86_64 to get things working again.
if it helps, here is my route during the problem: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface XXX.XXX.XXX.X YYY.YYY.YYY.Y 255.255.255.255 UGH 0 0 0 eth0 192.168.151.0 * 255.255.255.0 U 0 0 0 tun0 192.168.150.0 * 255.255.255.0 U 0 0 0 tun0 192.168.152.0 * 255.255.255.0 U 0 0 0 tun0 YYY.YYY.YYY.Y * 255.255.252.0 U 1 0 0 eth0 default * 0.0.0.0 U 0 0 0 tun0 and when reverting to older NetworkManager, netowrking was fin with: # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface XXX.XXX.XXX.X YYY.YYY.YYY.Y 255.255.255.255 UGH 0 0 0 eth0 192.168.151.0 * 255.255.255.0 U 0 0 0 tun0 192.168.150.0 * 255.255.255.0 U 0 0 0 tun0 192.168.152.0 * 255.255.255.0 U 0 0 0 tun0 165.112.132.0 * 255.255.252.0 U 1 0 0 eth0 default YYY.YYY.YYY.Y 0.0.0.0 UG 0 0 0 eth0 note the diffrecess in the last "default" lines
I can confirm this same problem with... NetworkManager-glib-1:0.7.0-1.git20090102.fc10.i386 NetworkManager-1:0.7.0-1.git20090102.fc10.i386 NetworkManager-gnome-1:0.7.0-1.git20090102.fc10.i386 NetworkManager-vpnc-1:0.7.0-1.svn13.fc10 Success with... NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10.i386 NetworkManager-glib-0.7.0-0.12.svn4326.fc10.i386 NetworkManager-gnome-0.7.0-0.12.svn4326.fc10.i386 NetworkManager-0.7.0-0.12.svn4326.fc10.i386 Invariant... vpnc-0.5.3-2.fc10.i386 netstat -rn output for: failure... Destination Gateway Genmask Flags MSS Window irtt Iface XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY 255.255.255.255 UGH 0 0 0 wlan0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 success... Destination Gateway Genmask Flags MSS Window irtt Iface XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY 255.255.255.255 UGH 0 0 0 wlan0 0.0.0.0 YYY.YYY.YYY.YYY 0.0.0.0 UG 0 0 0 wlan0 (not shown are the routes configured for the vpnc connection)
So basically, new NetworkManager isn't routing *all* traffic over the VPN, whereas previous version did?
Could I possibly get somebody to mail me the lines from /var/log/messages that NetworkManager spits out that contain the VPN settings? I'm specifically interested in what the VPN gateway and static routes that NM gets back from NetworkManager-vpnc are. They should look like: Jan 19 10:21:38 localhost NetworkManager: <info> VPN connection 'My VPN' (IP Config Get) reply received. Jan 19 10:21:38 localhost NetworkManager: <info> VPN Gateway: 1.2.3.4 Jan 19 10:21:38 localhost NetworkManager: <info> Tunnel Device: tun0 Jan 19 10:21:38 localhost NetworkManager: <info> Internal IP4 Address: 10.16.10.131 Jan 19 10:21:38 localhost NetworkManager: <info> Internal IP4 Prefix: 23 Jan 19 10:21:38 localhost NetworkManager: <info> Internal IP4 Point-to-Point Address: 10.16.10.131 Jan 19 10:21:38 localhost NetworkManager: <info> Maximum Segment Size (MSS): 0 Jan 19 10:21:38 localhost NetworkManager: <info> Static Route: 10.0.0.0/8 Next Hop: 10.0.0.0 Jan 19 10:21:38 localhost NetworkManager: <info> Static Route: 172.16.0.0/17 Next Hop: 172.16.0.0 Jan 19 10:21:38 localhost NetworkManager: <info> Static Route: 192.168.0.0/17 Next Hop: 192.168.0.0 Jan 19 10:21:38 localhost NetworkManager: <info> Internal IP4 DNS: 10.16.255.2 Jan 19 10:21:38 localhost NetworkManager: <info> Internal IP4 DNS: 10.16.255.3 Jan 19 10:21:38 localhost NetworkManager: <info> DNS Domain: '(none)'
*** Bug 480556 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > So basically, new NetworkManager isn't routing *all* traffic over the VPN, > whereas previous version did? Er, no. The other way round, I think... (In reply to comment #1) > if it helps, here is my route during the problem: > default * 0.0.0.0 U 0 0 0 tun0 > > and when reverting to older NetworkManager, netowrking was fin with: > default YYY.YYY.YYY.Y 0.0.0.0 UG 0 0 0 eth0 (In reply to comment #2) > failure... > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 > > success... > 0.0.0.0 YYY.YYY.YYY.YYY 0.0.0.0 UG 0 0 0 wlan0
Right, misread the route dumps. Will work on how to transparently transition to 0.7.1 here. Instead of the obscure behavior before where, if the VPN server returned static routes *or* the user entered static routes in the conneciton editor, NM would never select the VPN as the default route, NM will now only make a connection the default route if the checkbox "Use this connection only for resources on its network" is checked in the Routes dialog in the connection editor for that connection. This was added to allow more flexibility for users who, for example, had two ethernet NICs and wanted a specific one to be the default route, or to allow people to micromanage which connections got the default route and which didn't irregardless of what the VPN server sent. There were many requests for this both on RH and upstream bugzillas, so it was added to 0.7.1. What's missing is a transparent upgrade path to preserve user intent from before, where the user intent wasn't actually able to be expressed.
(In reply to comment #7) > never select the VPN as the default route, NM will now only make a connection > the default route if the checkbox "Use this connection only for resources on > its network" is checked in the Routes dialog in the connection editor for that Correction: the above is reversed. NM will only make a connection the default route if the checkbox "Use this connection only for resources on its network" is NOT checked. That box must be unchecked (unchecked is the default) for any connection to get the default route.
(In reply to comment #7) > Instead of the obscure behavior before where, if the VPN server returned static > routes *or* the user entered static routes in the conneciton editor, NM would > never select the VPN as the default route, Er, wtf? The default route isn't special. It's just another normal route, with a small netmask. If I _give_ you a list of routes in my configuration, I most certainly do _not_ want you to make up another route and add it to my list. So this 'obscure' behaviour of which you speak is the _only_ behaviour which makes sense, surely? If I _wanted_ a route with a /0 netmask, I'd have included it in my list. > This was added to allow more flexibility for users who, for > example, had two ethernet NICs and wanted a specific one to be the default > route, or to allow people to micromanage which connections got the default > route and which didn't irregardless of what the VPN server sent. OK, now if we stop thinking of the 'default' route as special, and rephrase that accordingly... We want to cope with people who have more than one connection, and both connections claim some route or other. And the user wants to control _which_ of the connections actually _gets_ the route to that particular range of addresses. My approach to solving this would be a list of routes which are _deleted_ from those requested by the server. So if you know your VPN is going to request 192.168.0.0/16 and 10.0.0.0/8, you could say "actually, don't let it have 192.168.0.0/16". And that approach works nicely for the default route _too_.
(In reply to comment #4) My output is the same as yours modulo the fake gateway and the IP4 address. The "Ignore automatically obtained routes" and "Use this connection only for resources on its network" options seem to have no effect at all. I tried "VPN Connections" -> "Configure VPN" -> "Wireless" to make my network connection "Use this connection only for resources on its network" with little luck. I actually managed to get NM to crash if I add a route, specify only the address and hit "Ok" with a netmask of 0, only to have NM crash.
(In reply to comment #9) > > (In reply to comment #7) > > Instead of the obscure behavior before where, if the VPN server returned static > > routes *or* the user entered static routes in the conneciton editor, NM would > > never select the VPN as the default route, > > Er, wtf? The default route isn't special. It's just another normal route, with > a small netmask. If I _give_ you a list of routes in my configuration, I most > certainly do _not_ want you to make up another route and add it to my list. So > this 'obscure' behaviour of which you speak is the _only_ behaviour which makes > sense, surely? If I _wanted_ a route with a /0 netmask, I'd have included it in > my list. Nobody actually does that, yet most VPNs (including the Cisco VPN client) actively try to ensure that the VPN is where your packets go. Seriously. I've never seen a VPN implementation run by anyone other than interested users actually push a route with a /0. That's just not how things work in the real world. Furthermore, some VPNs don't have the capability to push routes down to the client (PPTP) and thus if you want to route certain subnets over the VPN specifically, but not direct all your traffic over it, you need to manually enter some routes. However, just because you've entered some routes does not necessarily mean you want only those routes to go over the VPN Imagine you have eth0, and you normally route 192.168.1.0/24 and 192.168.2.0/24 over it. However, when you're on VPN, you want traffic for everything *except* 192.168.1.0/24 to go over the VPN. So you enter 192.168.2.0/24 into the "Routes" dialog in the connection editor, but you do *not* check "Use this connection only...". In the correct implementation (and NM does not do this yet, but it will), the VPN gets /0 *and* 192.168.2.0/24, while only 192.168.1.0/24 is routed over eth0. Contrived, but possible; say you are testing a mirror of whatever is on the VPN 192.168.2.0/24 on your local net because you're a sysadmin. It's also possible with the current Fedora ifcfg scripts (set up a routes-eth0, routes-whatever and set GATEWAYDEV=whatever). > > This was added to allow more flexibility for users who, for > > example, had two ethernet NICs and wanted a specific one to be the default > > route, or to allow people to micromanage which connections got the default > > route and which didn't irregardless of what the VPN server sent. > > OK, now if we stop thinking of the 'default' route as special, and rephrase > that accordingly... Except that it *is* special. It has properties that other routes don't, precisely because no other route can be lower than it, and thus after the default route, all route processing stops. It's like a mail filter at the bottom of your filter list that dumps everything not already filtered into the trash; if it wasn't there, everything that didn't match would still be cluttering your inbox. > We want to cope with people who have more than one connection, and both > connections claim some route or other. And the user wants to control _which_ of > the connections actually _gets_ the route to that particular range of > addresses. Yes, that's one of the things we want to do. However, almost *never* is a /0 returned from either a DHCP server or a VPN, so we simply don't have the information to make that decision for the default route. Thus it has to be either inferred, or explicitly stated by the user. > My approach to solving this would be a list of routes which are _deleted_ from > those requested by the server. So if you know your VPN is going to request > 192.168.0.0/16 and 10.0.0.0/8, you could say "actually, don't let it have > 192.168.0.0/16". And that approach works nicely for the default route _too_. Could work, however you never know exactly what routes you're going to get from the DHCP server or the VPN server beforehand when you're configuring the connection if you do so manually, thus having a "if the server sends this route, ignore it" sort of thing doesn't work well. However, if you're talking about *internally* to NetworkManager as an implementation detail of how to processing routing from multiple sources, that could be part of the solution.
Another option would be to assign priorities to each connection -- which could be directly translated into route metrics. That doesn't necessarily cover every use case though.
(In reply to comment #12) For me and likely anyone else who's hit by this issue, we're just hoping our use case (that we had before) is expressible soon. Alternatively, we can find a way to make the new package update widgets ignore NM packages. I have a single interface, wlan0, everything flows through it. I start up a VPN interface, tun0, that has specific routes associated with it, 10/8 192.168.21/24. When the VPN is running I want it to handle only traffic for the routes I've configured. Everything else should go through the original interface. This is simpler than what is being discussed. There isn't a 3rd interface with overlapping routes. A priority scheme seems useful and reasonable. You'll have to do some clever work to split overlapping routes.
(In reply to comment #13) > (In reply to comment #12) > > For me and likely anyone else who's hit by this issue, we're just hoping our > use case (that we had before) is expressible soon. Your use-case is the normal one for most of the Red Hat users I know. It's completely expressable by checking the "Only use this connection for resources on its network" checkbox in the routes dialog of the IP4 tab for that VPN connection. You can check that box now and get your desired behavior. What's actually broken is the upgrade to svn4326 to git20090102. Behavior in svn4326 used a somewhat broken heuristic to automatically "check the box" so to speak, but since that heuristic is broken, it was moved to an explicit user choice. However, git20090102 doesn't have compatibility code to automatically check the box on upgrade. You can check it yourself however. > Alternatively, we can find a way to make the new package update widgets ignore > NM packages. > > I have a single interface, wlan0, everything flows through it. I start up a VPN > interface, tun0, that has specific routes associated with it, 10/8 > 192.168.21/24. When the VPN is running I want it to handle only traffic for the > routes I've configured. Everything else should go through the original > interface. You can get this capability by checking the "Use this connection only for resources on its network", and then manually entering your desired routes into the dialog. Note that the VPN server will *also* send a set of routes which get applied (in addition to ones you've manually entered) unless you check the "Ignore automatically provided routes" checkbox.
(In reply to comment #14) > You can get this capability by checking the "Use this connection only for > resources on its network", and then manually entering your desired routes into > the dialog. Note that the VPN server will *also* send a set of routes which > get applied (in addition to ones you've manually entered) unless you check the > "Ignore automatically provided routes" checkbox. I tried that, back in comment #10, with no luck. I updated NM, service restarted it, edited the VPN to "Use this connection only for resources on its network" and then connected to the VPN. A /0 rule was still created for tun0.
Hi, I am suffering the same issue as the submitter, and enabled the checkbox to fix it as suggested. I am really puzzled how on earth I got a default route pointing to an internal ip (that of the br0 interface) of my openvpn gateway since it is not being pushed. As a result I lost connectivity to everything other than internal and had to fix it manually. I am using openvpn in windows also and I never got similar issue. I think the new behavior is trying to be a little smarted than it should. I can understand the use cases that could make such a feature useable for NetworkManager, but I still cannot understand what I am seeing.
*** Bug 482967 has been marked as a duplicate of this bug. ***
The next update will automatically check the "Use this connection only for resources..." box on upgrade if there are manual routes assigned, which was the default behavior for NM 0.6 and earlier NM 0.7 builds up to 2008-10-10. Cases where the server passed static routes and the user wants only those routes used for the VPN connection will need to check the box manually.
I can confirm that the bug I was running into appears to be caused by having multiple connections setup as the default interface, e.g. setup *without* "Use this connection only for resources on its network" checked.
I have a vpn connection that since this software release will now only work successfully if I connect to it via the vpnc command line. When I connect via the NetworkManager (which as exactly the same simple config) I am unable to connect to/ping any hosts at the other end. I've tried all combinations of the routes tick boxes. netstat -rn differs only slightly: via NM: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface XX.XXX.X.XX 10.0.11.1 255.255.255.255 UGH 0 0 0 eth0 192.168.140.0 0.0.0.0 255.255.255.224 U 0 0 0 tun0 10.0.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 with command line: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface XX.XXX.X.XX 10.0.11.1 255.255.255.255 UGH 1500 0 0 eth0 192.168.140.0 0.0.0.0 255.255.255.224 U 0 0 0 tun0 10.0.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 I can provide the verbosity from /var/log/messages if required.
Is this still an issue with latest NetworkManager and NM-vpnc packages from updates? Also try: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-10546
There's still no option to obey what we're told by the VPN server. Sometimes it wants us to add the default route; sometimes it doesn't. In the case of the berkeley.edu VPN, the user actually gets to choose as they're logging in. They enter VPN type, username and password. And when they're running from the command line using the normal vpnc-script, everything works fine and they get what they asked for. But when they're using NetworkManager, its hardcoded setting overrides the server's indication of whether to set the default route or not.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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. Thank you for reporting this bug and we are sorry it could not be fixed.
Comment #22 still applies in Fedora 12. There's still no option to make NetworkManager just do what the VPN server tells it to.
The scenario noted in comment #13 seems to be fixed in release 2.git20100411.fc12, currently in updates-testing.
To clarify my previous comment, I was experiencing the same symptoms with NetworkManager-openvpn and forgot to properly cross-reference this bug's listed component. My comment was not in regard to NetworkManager-vpnc and should be disregarded.
I filed https://bugzilla.gnome.org/show_bug.cgi?id=621698 -- thought I'd done so a long time ago, in fact, but if so I can't find it.
This is now fixed in F14 and F15 for OpenConnect, but not yet for vpnc (see my latest comment in the GNOME bug).
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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. Thank you for reporting this bug and we are sorry it could not be fixed.