Bug 485346 - NetworkManager mistakenly routes all traffic through VPN
NetworkManager mistakenly routes all traffic through VPN
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-12 18:56 EST by Dan Winship
Modified: 2009-02-13 11:15 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-12 19:21:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Winship 2009-02-12 18:56:11 EST
When I connect to the Red Hat VPN via NetworkManager, it routes all of my traffic through the vpn:

danw@desktop:~> traceroute google.com
traceroute to google.com (74.125.45.100), 30 hops max, 60 byte packets
 1  vpn1.redhat.com (66.187.233.252)  44.735 ms  45.186 ms  45.743 ms
 2  router-vlan500.corp.redhat.com (172.16.51.14)  49.197 ms  49.727 ms  50.201 ms
 3  router.redhat.com (66.187.233.254)  50.564 ms  51.296 ms  53.367 ms
...

If I connect via vpnc instead, it does not (so it's not just that the VPN server is sending us a bogus netmask or something):

traceroute to google.com (74.125.45.100), 30 hops max, 60 byte packets
 1  10.68.0.1 (10.68.0.1)  6.071 ms  6.334 ms  6.834 ms
 2  ge-2-5-ur01.a2atlanta.ga.atlanta.comcast.net (68.85.233.193)  16.589 ms  17.210 ms  17.509 ms
 3  te-9-1-ur02.a2atlanta.ga.atlanta.comcast.net (68.85.232.38)  19.705 ms  19.969 ms  20.268 ms
...

I'm pretty sure this behavior started with NetworkManager-0.7.0-1.git20090102.fc10. I'm blaming NetworkManager rather than NetworkManager-vpnc because the changelog for the latter looks like nothing really changed there.
Comment 1 Dan Williams 2009-02-12 19:21:51 EST
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.
Comment 2 Dan Winship 2009-02-13 09:47:18 EST
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.)
Comment 3 Dan Williams 2009-02-13 10:26:47 EST
(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.
Comment 4 Dan Winship 2009-02-13 11:15:57 EST
(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.)

Note You need to log in before you can comment on or make changes to this bug.