The Case Against Home VPNs

Every once in a while, my path crosses with someone who is gung-ho about setting up their own home VPN.  Let me attempt to summarize the rest of this post for you:  Probably not worth it.

But before I start nay-saying, let’s look at some of the legitimate, desirable reasons for setting up a home VPN:

  1. Access your personal files from anywhere
  2. Encrypt your network traffic while using public WiFi away from home
  3. Share your home network resources with others (such as files or servers)

Let me validate these points.  There is nothing wrong with having these goals.  But, may I suggest that, for the majority of my readers, a home VPN is the wrong way to accomplish these goals.  Let’s see why.


I ran a home VPN for years.  I used Untangle NG Firewall (then, just named “Untangle”) as the gateway device for my home network.  Untangle includes an OpenVPN server, which can be configured fairly easily using their web GUI.  (This is one of the strengths of gateway services such as Untangle–simplifying what are otherwise daunting configuration tasks.)  Seems pretty nice, eh?

These bundled meta-services work well–except when they don’t.  I was caught on the latter end a few times, and I was frustrated by how little Untangle let me tweak.  (Frustrating for a nerd like myself.)  Eventually, I concluded that, if I want to be in control, I have to setup and configure the service myself.

What’s involved in rolling your own VPN setup?  Setting up hardware (or a VM), setting up the server in your network, adjusting your firewall to accommodate, (re)setting your DMZ and/or setting up port-forwarding, configuring the VPN server itself, installing/configuring VPN clients on your desired devices, distributing keys out-of-band, and managing VPN authentication (passwords/keys).

Side note:  Some of these tasks should not be taken lightly, as even a slight misconfiguration can result in drastic security vulnerabilities.  I encourage you to consult an expert if you don’t know what you’re doing.

Take-away:  Unless you’re a hobbyist, stick to the bundled meta-services, such as Untangle, or even OS X Server‘s VPN feature.  However, even then, you can expect bumps, and security should not be assumed.

Let’s wave a magic wand, and pretend that you’ve gotten your home VPN server installed, securely configured, and functional.  Congratulations!  You scurry out the door and head to the local Starbucks to try it out.  You arrive, order your macchiato, open your laptop, and fire up your OpenVPN client.  What’s that?  It’s not working?  Should have gotten that coffee to go.  You can’t configure your VPN if you can’t connect through it.  (And, even if you could, it’s a Bad Idea.)  So, you head home.  Tweak some settings.  Head back to the coffee shop.  Rinse and repeat.  Four times over.  Ugh.


Finally, your client connects at the coffee shop, and you try to exercise the VPN tunnel by watching a video of your child’s school play.  Unless you have a media server at home, you can’t stream it.  Your only option is to download it to your laptop’s hard drive.  Fine.  Clickety-click, and it’s downloading.  Estimated download time … 3 hours?  Surely, that can’t be right…

Actually, it probably is.  Think about what kind of bandwidth you pay your ISP for.  For me, it’s 15 Mbps download and 1 Mbps upload.  That’s far sufficient for all that I do at home.

The trick with VPNs is that your download speed at the coffee shop is limited by your home ISP’s upload speed.  So, that’s a best-case of 1 Mbps download, which translates to 125 kB/s.  At this rate, a single 5 MB MP3 file would take 40s to download.  To put things in perspective, in my case, my download speed over VPN is 15 times slower than my download speed at home.

So, beware:  Your download performance over VPN will be poor at best, and you can probably assume that streaming video is out of the question.


After a few years, my home VPN stopped working.  For no apparent reason.  All of my various in-home tests succeeded.  After some poking around, I was able to infer that my ISP started blocking incoming connections on port 1194 (which is the IANA-assigned port for OpenVPN).  If I really wanted to, I could have started to play games with unofficial ports.  However, two things held me back:

  1. Untangle didn’t make it very easy to do so
  2. How long before my ISP caught on again?

Take-away:  Not all home ISPs allow incoming connections for VPN ports.  Further, some ISPs don’t allow any incoming connections, regardless of port.


Once I resigned to giving up my home VPN, I eventually just replaced my home gateway server (which was powered on 24/7) with a hefty Apple AirPort Extreme.  (Side note:  It’s solid.)  The biggest difference that I noticed?  I started saving ~$25/month on my electric bill.  (YMMV.)

Decide for yourself:  What’s a reasonable amount to pay on your monthly electric bill for your home VPN service?  Could that money be better spent?


The elephant in the room.  First, a few basic principles:

  • Whatever device you connect directly to the Internet (i.e. from your ISP) had better be darn secure.  It’s your first (and most effective) line of defense.
  • Any port persistently left open (such as for a VPN server) is begging for attention on the Internet.  You can expect that it’ll be hit.
  • If you can access something remotely, then it’s feasible that a hacker could too.
  • If your gateway device is compromised, it’s as if you’ve given a hacker the WiFi password to your network.  They’re in.  (How much more serious if you plan on storing personal files directly on your gateway device.)

In terms of the device you connect directly to the Internet, what’s more secure?  A server with an open port, or a WiFi router with no open ports?  Generally, the best security is having no front doors.

Don’t get me wrong–VPN servers employ security measures to keep the bad guys out.  But what happens when the next 0-day hits?  Or, when someone steals your VPN password/key at a coffee shop because you don’t use a firewall on your laptop?  The best security measures on the planet are useless if the hacker can get in the same way you can.

Standard risk/reward:  Is the risk of compromising/losing your personal data (financials, photos, passwords, etc.) worth the reward of having a home VPN?

Done Better Outside the Home

Let’s revisit our 3 goals for using a VPN:

  1. Access your personal files from anywhere
  2. Encrypt your network traffic while using public WiFi away from home
  3. Share your home network resources with others (such as files or servers)

Let me propose that #1 and part of #3 can be done better (and for free) outside the home by cloud services like Dropbox.  And I’d put my money on their security over yours–especially if you turn on their 2-factor authentication.  If you’re worried that Dropbox won’t fit all of your media files in their free tier (2 GB), then try offloading your music in the cloud using Google Music.  For 90% of us, 2 GB is way more than we need.

Let me propose that #2 can be done better (though rarely free) outside the home by services like Private Internet Access.  Lifehacker offers some good tips on choosing the right one.  For most of us, however, we can skip the paid services and satisfy our basic paranoia by using the free HTTPS Everywhere plugin.

If the above services are cost-prohibitive, then just consider using some of the ~$25/month that you’re “saving” by not running a server at home 24/7.  $10/month buys you 100 GB on Dropbox.  Just sayin’…

No, really…

The astute among you will realize that part of goal #3 cannot be done better outside the home:  If you run a server at home, and you absolutely must have access to that specific, exact server while outside of the home, then congratulations–you’re among the 1% of readers who actually could use a home VPN.  Hopefully you’re also a hobbyist.

For the rest of you, I’ll see you on Dropbox.

In fact, if you want to be nice, use this link when you sign up; Dropbox offers 500 MB of bonus space for every referral.  ;-)


Where to Store Your Document

Somewhat frequently, I’m asked about the security of storing documents using services like Google Drive, Dropbox, and SkyDrive (among others).  Instead of jumping immediately into the technical specifics, I’ve found it useful to first ensure that the asker understands the essence of the services he/she is asking about.  More specifically, I’ve found it helpful to present comparisons of the basic philosophies for document storage:

Consider these carefully, and decide which best suits your document needs.

Risk Assessment

The next step in choosing where to store your document is weighing the risks.  It’s a common fallacy to assume that risk increases with more technical solutions.  Let’s explore risks for all three categories:

Okay, great.  All three categories have risks.  Which one should I choose?


Choose a physical document if…

  • you don’t need to access the document remotely
  • you don’t need to collaborate with other people
  • you don’t need to maintain revision history
  • you don’t need to store the document encrypted

The biggest risks using a physical document are loss and theft.

Choose a digital document if…

  • you don’t need to access the document remotely
  • you don’t need to collaborate with other people
  • you wish to manage your own document encryption

The biggest risks using a digital document are theft of computer and having your computer hacked.  If you’re emailing copies of the document around for collaboration, you should go ahead and assume that somebody’s changes will get lost.  For most documents, this is the wrong solution.

Choose cloud-based document if…

  • you need to access the document remotely
  • you need to collaborate with other people
  • you need to maintain revision history

There are minimal risks for using a cloud-based document.  The biggest downside, however, is trusting someone other than yourself to store your data.  (Believe it or not, Google isn’t very interested in stealing your term paper.)  Provided that you’re using good technology hygiene, this is often the best solution for most documents.