Secure your codebase: OpenVPN in the (Rackspace) Cloud

Imagine this scenario: your company is growing rapidly and you’re hiring tons of engineers.  The passwords to many of your servers are stored in plaintext in configuration files — everyone has access to them.  Your main database – the one with all the user data – is available to anyone who has that file.

You fire an engineer.  Now what?  He knows the passwords to everything.  Do you trust him? What if you’re firing him because he’s just a bad egg? What can you do?

Well, you could change the passwords on every single server… but that’s a huge pain in the ass for everyone involved.  Luckily, there’s a solution for this problem, one that comes with quite a few other benefits as well: you set up a VPN.

What is OpenVPN?

OpenVPN is open-source software that allows you to set up a Virtual Private Network.  Basically, it allows you to treat remote servers as if they were on your internal network. This gives you fine-grained control over everyone who has access to your systems.

Each computer that has access to the VPN is a “client”, and they each have their own certificate. If you want to remove someone’s access to your network, you just revoke their certificate.  It only takes a few seconds, and boom – problem solved.  The engineer you fired can’t access the MySQL server even if he knows the password because it’s only accessible via the VPN.

The Situation

At Mixpanel we use the Rackspace Cloud for hosting, so this guide (as you may have guessed from the title) will be written from that perspective.

Servers hosted at Rackspace come with two interfaces by default: the Public interface (eth0), which is accessible from the internet, and the Private interface (eth1, also known as Rackspace ServiceNet) that is used from intercommunication between your own servers.  Bandwidth on the private interface is unmetered (read: free) and actually uses a whole different ethernet port than the public interface.

The Plan

Our first goal in setting up the server is to secure the codebase.  To do this we need to do two things:

  1. Set up the OpenVPN server and generate clients
  2. Update the firewall on your other servers to block external connections and only allow connections via OpenVPN or the local network

After accomplishing (2) our infrastructure should resemble this diagram:

Basically, your whole setup will be walled off from the internet except for the servers that really need to be able to communicate with the outside world, namely the vpn server and your actual web servers.  All communication between servers should happen over the private network, since it’s both cheaper and more secure.

Setting up the server

Helpful links:

The OpenVPN HOWTO is quite comprehensive and useful. It should be the first thing you read:

If you get stuck, this wiki is helpful – particularly these pages:


1. Install OpenVPN:

This will put a bunch of files in /usr/share/doc/openvpn/, but you should make a copy so that your modifications don’t get lost in a software update (see next step)

2. Copy the examples folder to /etc/openvpn/:

3. Follow the HOWTO.  It will walk you through the rest of the steps, which I will go over briefly.

First we need to build the key signing infrastructure and the initial server keys. (Tip: do this as root, otherwise too many sudo)

Then we can build client keys – basically one for each computer that will connect to the VPN is a client.  I plan on using employee emails as client names, but you can use any unique naming scheme.

Just run the following command once for each client, replacing clientname with the name of your choice 🙂

Your server needs to retain clientname.crt, and the client needs both clientname.key and clientname.crt to be able to connect.

Before we go any further, let’s set up the server.conf – create a server.conf file at /etc/openvpn/server.conf and paste in the following code:

Next, try running the server – sudo openvpn server.conf.  It should run, and you should be able to connect from a client, but it won’t forward traffic across the network yet.

To do that, you need to set up IP forwarding – this is required to route traffic to other nodes:

The final step is to set up your iptables rules for the vpn server.  The most critical rule (and a curiously underdocumented one) applies to the NAT table – it will rewrite the packets that come through the vpn with the vpn’s ip address before passing them along.  If you don’t do this, the origin address on the packets is 10.37.73.XX, which the other servers on your network don’t know how to handle.

The important one is:

Here’s a sample iptables ruleset for your VPN server:

If you save this file as /etc/iptables.up.rules on the vpn server, and call sudo iptables-restore < /etc/iptables.up.rules then you should have a fully functional vpn server.  If you connect to it, you should be able to ping your other servers by their internal ip addresses from your local computer.

At this point we don’t have the rest of the network blocked off, but that’s the next step. Broadly, you will want to update the iptables firewall on all of your servers to restrict to a set of IP addresses that you own.  The rules will look something like this:

I’ll go into more detail on this part of the process in my next post. For now, you should enjoy your fully functioning OpenVPN server!

11 thoughts on “Secure your codebase: OpenVPN in the (Rackspace) Cloud

  1. Pingback: 404 Not Found
  2. Easily the post is actually the best on this deserving topic. I fit in with your conclusions and will eagerly look forward to your upcoming updates. Just saying thanks will not just be sufficient for the extraordinary lucidity in your writing.

  3. Publikacja elektroniczna jest od czasu do czasu ujmowana szerzej, skoro obejmuje materialy elektroniczne niebedace ksiazkami, niczym chociazby systemy pomocy. z trudem zrealizowac precyzyjna klasyfikacje oraz w gruncie rzeczy wolno przyklaskiwac rozmaite zakresy definicji publikacji oraz ksiazek elektronicznych. jest dozwolone jakkolwiek przychylic sie, iz ta ostatnia jest przeniesieniem klasycznej ksiazki czyli czasopisma az do swiata urzadzen komputerowych, co wyraza sie chocby w nazwie.

  4. Hi,

    My name is Ananjan Chaudhuri and I work for Packt Publishing, a U.K. based publishing firm specializing in focused IT books. You can read more about us here:

    I came across your blog through google search and noticed good amount of information on OpenVPN.

    I would like to inform you that Packt has recently published a new book OpenVPN 2 Cookbook, a new book which covers everything a system administrator needs to manage and run an OpenVPN network, from point to point networks to troubleshooting. Written by Jan Just Keijser, this book offers all the information you need to successfully manage your network. You may read more about the book here:-

    Keeping in mind your knowledge in this subject and having looked at your contributions, I feel you’d make an excellent reviewer of this book. In case you’d like to write a review on your blog/website and/or Amazon, simply let me know your shipping details (Required for the registration of new reviewers) and I’ll have the eBook added to your account and would provide you with the download instructions in my next e-mail. You can then download this book instantly.

    If you have any queries, do let me know and I’d be happy to assist.

    I look forward to hearing your thoughts on this.

    Have a good day!


  5. I’m getting the following error with CentOS 5.6 running OpenVPN 2.2.2:

    [root@server 2.0]# iptables-restore < /etc/iptables.up.rules
    iptables-restore v1.3.5: Line 53 seems to have a -t table option.

    Error occurred at line: 53

    Any help is appreciated.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.