So you'll either want what's in updates-testing (which has some heuristics to do this automatically on upgrade), or you'll want to bring up the connection editor, VPN tab, edit your VPN connection, click the IPv4 tab, click the Routes button, and check "Only use this connection for resources on its network".

Previously (as in before Christmas) NM would only route everything through the VPN if the server sent static routes, or if static routes were specified in the UI.  Since in some cases that's not what is desired, that functionality was made more general (to be able to apply to *any* connection not just VPN) and moved to a checkbox in the Routes dialog.  I decided not to default everything to "Only use this connection..." for security reasons; becuase it's more secure to have users who know what they need check the box rather than open up everyone's routing.

If that doesn't work for you, let me know, reopen, and we can debug it further.

If the sysadmins want all of their users' traffic to go through the VPN, they should send a static route for 0.0.0.0 or whatever. If there are really "security reasons" here, then adding special behavior to NM doesn't address them, because people using vpnc (or the official Cisco Windows VPN client?) will continue to have the "insecure" behavior.

And if the sysadmins *don't* want all of their users' traffic to go through the VPN, then there are no security concerns. And users certainly don't want all of their traffic to go through the VPN if company policy doesn't absolutely require it. ("[X] Please slow down all of my network traffic by forcing it to travel halfway across the country first, and also, make all of my network connections break when the VPN bounces or when I disconnect from the VPN at the end of the day, so that I have to quit and restart Thunderbird if I want to still be able to check my personal email at night.")

Is it currently even possible for the sysadmins to configure the VPN so that NM would by default not route non-local traffic through the VPN? If not, that seems like a bug. (Is there any chance that it's not just a coincidence that vpn3.redhat.com ran out of memory yesterday? :-)

(The "more general"/"apply to any connection" thing is potentially nice. But I think that for VPN backends where the protocol lets the server send routes/netmasks to the client, that "Only use the connection for resources on its network" is the expected behavior, and should be the default.)

(In reply to comment #2)
> If the sysadmins want all of their users' traffic to go through the VPN, they
> should send a static route for 0.0.0.0 or whatever. If there are really
> "security reasons" here, then adding special behavior to NM doesn't address
> them, because people using vpnc (or the official Cisco Windows VPN client?)
> will continue to have the "insecure" behavior.

Yeah; they should.  But in practice the *never* happens.  Cisco VPN client on Mac OS X and Windows will lock down the local network and route everything over VPN even for the Red Hat VPN, which doesn't send 0.0.0.0 down to the client.  It's an administrator option and unfortunately something that the admin either has to configure on the client, or let the users know about explicitly.

Furthermore, until quite recently vpnc didn't even support split routing in it's vpnc-script; so just using plain vpnc would direct all your traffic through the VPN.  That's the reason we added the "only route these subnets over the VPN" option long long ago because none of us wanted that.

> Is it currently even possible for the sysadmins to configure the VPN so that NM
> would by default not route non-local traffic through the VPN? If not, that
> seems like a bug. (Is there any chance that it's not just a coincidence that
> vpn3.redhat.com ran out of memory yesterday? :-)

It's not possible to do that remotely without updating client settings as well.  Since users need to know a lot about the VPN setup (gateway, dead-peer-detection, potentially which ciphers to use, etc) this is simply one more decision that somebody has to make.  Usually that will be the administrator when setting up the machine *or* when creating the .pcf files that you can import into NetworkManager.  NM-vpnc in SVN does support the .pcf file option to toggle this behavior, so admins could certainly control it that way when rolling out the .pcf config files.

> (The "more general"/"apply to any connection" thing is potentially nice. But I
> think that for VPN backends where the protocol lets the server send
> routes/netmasks to the client, that "Only use the connection for resources on
> its network" is the expected behavior, and should be the default.)

It might well be a better default; however there's no good way to set that default on upgrade without breaking *somebody's* config.  Always setting it when updating the NM RPM will break those people who *do* want all their traffic to route through the VPN, but not setting it breaks those people who don't.  Part of the problem before was that there was no way to conclusively figure out what people wanted; it was based on voodoo and bad heuristics, which made a lot of people complain.  Now it's a lot clearer what the behavior will actually be, but it may require a small amount of action from the more knowledgeable users.

(In reply to comment #3)
> Yeah; they should.  But in practice the *never* happens.  Cisco VPN client on
> Mac OS X and Windows will lock down the local network and route everything over
> VPN even for the Red Hat VPN, which doesn't send 0.0.0.0 down to the client. 

Ah. OK.

Certainly I'd be less annoyed by this if it had *always* worked this way, since I did test the behavior when I first started using the VPN. So if the updates-testing version you mentioned has better heuristics for upgrading users then it sounds like it solves my problem. (Or at least, it would have if I had skipped the current version.)