More accidental BitTorrent on our network

August 17, 2009

We've recently had another interesting case of 'accidental BitTorrent' on our network, different from the previous times. This time around it was through our VPN server, and just from that alone you can probably guess what happened.

Suppose that you are a user, sitting at home running BitTorrent in the background on your home machine while you do other things. You need to access some restricted on-campus thing; our generally supported way to do this is to fire up a VPN connection so that you are 'inside' as far as our various access controls are concerned. So you do so and browse the library, or get at our Samba server, or whatever.

And all the time that you're doing this, all of your network traffic is flowing over the VPN and out our network to the outside world. Including that BitTorrent client you have running in the background. Whoops.

Like the first time, this is not the user's fault; I can't expect even our users to all understand network routing and the fine details of how our VPN behaves. (Yes, this is obvious to us, but that's because we spend all of our time immersed in these things.)

This makes a nice illustration of something else as well: the perils of a mismatch between the user's view of what's happening and what's really going on. If the user's view is that they're using the VPN to access some inside resource, how would they even think about what's happening with their traffic to regular things? At a conceptual level it's not even related to what they're doing.

Comments on this page:

From at 2009-08-17 08:45:25:


I have sometimes troubles like this, but I realiced, for example on OpenVpn server you can select if want to direct all user traffic through the VPN server or don't touch routes on clien configuration. But, there is something that is true, the danger of get any malware and massificate on vpn computers and resources still exist.

From at 2009-08-17 09:41:25:

Is there a good reason to replace the user's default route?

By rdump at 2009-08-17 13:56:21:

If you don't want traffic routed through your user's box to your internal network from other systems out there on the Internet, then yes, you'll ensure that all the user's traffic goes across the VPN tunnel. You'll prevent that user's box communicating with and through anything but your VPN endpoint. Whether you do that by "replacing a default route" or you use something more sure, it's necessary.

If you don't care about other traffic routing through your user's box to your internal network (you judge the harm from this low, or you judge the likelihood of it happening low), then you may want to rethink why you even need a VPN.

You may be able to get more user satisfaction and understanding out of a different style of remote work support. For example, we're aiming for a suite that leaves the users free to both print locally and get at the resources they need on our internal net without the overhead (both cognitive and computing) of setting up a VPN.

By cks at 2009-08-17 15:46:47:

Unfortunately for us, there are excellent reasons to replace the user's default route. Our VPN gets used for three different reasons:

  1. getting access to internal resources.
  2. getting access to external resources that are only accessible from UofT IP addresses (some journal websites, for example).
  3. getting out of our local wireless network.

The third requires all traffic to go through the VPN, and in practice the second also requires it. The first could in theory get by with a large collection of specific routes (the UofT has multiple public subnets, and then there's the internal private ones), but it's much simpler and more reliable to use a default route.

From at 2009-08-17 16:48:26:

Could you limit the scope of traffic forwarded through the VPN to specific ports and IP address?

By cks at 2009-08-17 22:41:55:

Given the third reason for the VPN, not really. Even the second reason is infeasible to keep track of (especially since things like journal websites may well change IP addresses every so often).

Written on 17 August 2009.
« Testing versus extensibility
Why user programs mapping page zero is so bad news on x86 hardware »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 17 01:35:31 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.