Installing an encrypted openvpn on Lenny

Posted by pj on Mon 17 Jan 2011 at 22:00

Tags:

This article documents installing an encrypted openvpn server upon the Lenny release of Debian - read on for the motivation & documentation.

The motivation

While job hunting on Craigs List I came across this advert:

Multinational company seeks new recruits

Due to a technical problem in the holiday season, a fresh vacancy has come up with our client.

Our client is a well-known multinational specializing in PR and similar areas. It has an operations base in the UK, Yemen, Pakistan, Afghanistan and Saudi Arabia, along with subsidiaries operating semi-autonomously in many other countries.

The desired candidate should posses the following qualities:

    • Ability to speak English.

    • Single-mindedness dedication to the job undertaken (24x7 availability a must)

    • Ability to follow instructions correctly.

    • Ability to set up confidential VPN connectivity to our home base for secured information exchange.

    • Previous military experience will be considered a plus.

    • Willingness to set genitals on fire (if required) will be viewed favourably.

    • Remuneration for the right candidate will be extremely generous.

    • Bonus perks include 72 virgins upon completion of certain tasks.

For further details, please contact: 1-800-OBL-911

So, as you can see, building encrypted VPN tunnels in this day and age is a necessity, whether you are a road warrior or a religious nutjob.

Now, one of the earliest articles the venerable Steve wrote on debian-administration.org was about the wonderful openvpn tool. It is time we revisited and updated it to the needs of our times, in the era of Cisco solutions; corporate intranets; and secure connections.

The Scenario

Now suppose Mel, our road warrior, heads off to the wild outback with his laptop. He wants to sell some Redundantizer Rocket Propelled Grenades (RRPGs) to a client, the rather eccentric Mogambo.

Mogambo has some quirks, such as: he likes to be greeted with a Nazi salute; he likes to have his minions kill themselves by jumping into an acid bath to display their loyalty; and also likes hearing earth shattering kabooms. You get the idea.

Mogambo demands to hear what the RRPGs sound like when they go kaboom, but Mel doesn't care to waste a perfectly good RRPG just for that. Mogambo is unhappy and the argument goes back and forth, until eventually he agrees to go ahead with the deal if he can hear just a sound file of the kaboom.

Mel has the mp3 of the sound on his desktop back at the office, but to pull it out of there he needs to connect to the office intranet, and fire up his applications on the office LAN like he usually does. Mel knows that Mogambo is not trustworthy, and may have placed snooping devices on the network to sniff out Mel's authentication and access.

So, assuming the connection he is using may be compromised, how can Mel connect?

By using openvpn!

The details:

Here are the steps Mel's sysadmin did earlier. You may follow these too on a standard debian lenny system:

  1. On the server as well as on the client you do an:

    apt-get install openvpn

    That's the easy bit, of course. The configuration is the hard bit.

  2. Fortunately, the openvpn developers bundle the easy-rsa scripts with the package to make configuration easier. On the server, copy the easy-rsa scripts into an etc openvpn directory.

    cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/

    Let's change to the directory for the next step:

    cd /etc/openvpn/2.0

  3. Run the "vars" script in the shell to initialize some environmental settings for the next steps. (If you want to change stuff in vars, you can. Eg, you may want to (and actually for security, you should) change the default 1024 key size to 2048. But the defaults will run fine (even if you leave in the "KEY_*" variables unchanged)).

    . vars

    (The "." in the above is to "source" the file as part of the interactive shell itself in case your script-fu is a little rusty. It effectively means that variables set in the script are remembered when you get back to your shell prompt).

  4. Now make your server the certifying authority. Certifying authority for what? For validating the certificates that are going to be presented by the server to the clients during a normal VPN connection. Ie, when a client connects to the server, the server is pretty much saying "I signed the certificate you are reading for the first time (or have already stored) when you connect to me (and I am proving that it was me with the clever mathematical validation that runs when you connect to me as a client)".

    ./build-ca

    The above builds the ca.crt and ca.key files in /etc/openvpn/2.0/keys/

  5. Now build the Diffie-Hellman generating parameters.

    ./build-dh

    This builds your dh1024.pem key (or dh2048.pem if you altered the vars script accordingly).

    These are used later during normal use. Used for what? To establish the connection in a secure manner over insecure connections. (See http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange for more on this). Ie: snooping on the interaction during the DH key exchange won't let an eavesdropper decrypt the connection.

  6. Now we need to initialize some files that the build-key[-server] scripts in the next steps would otherwise stumble on. We do a touch on a file called "index.txt", and if the file "serial" doesn't exist, we initialize it with 01 like the fine manual tells us (and yes, the somewhat mysterious "0" in front of the "1" during the "echo" is needed):

    touch /etc/openvpn/2.0/keys/index.txt

    echo 01 >/etc/openvpn/2.0/keys/serial

  7. Build the VPN server key/certificate pair with the build-key-server script.

    ./build-key-server serverbox_vpn

    As the script executes, it builds the csr (Certificate Signing Request) file and prompts for signing. Go along with the prompt (you can press the enter key if you can't be bothered to change the defaults - the keys are unique, even if the claimed owner remains default). When you finish, you will now have serverbox_vpn.key and serverbox_vpn.csr added to the list of files in the keys directory, and they are certified by the CA you set up earlier.

  8. Now let's build the VPN client key and crt files with the build-key script.

    ./build-key laptop_vpn

    This also builds the csr file for the client and prompts for signing, and like before, you can just go along with the default and get your certified keys. This step is often done remotely by admins who know how to keep track of what is what. But it is simpler to just do it all on the server itself, and then copy it across with:

    cd keys

    scp laptop_vpn* LAPTOP.IP.ADD.RESS:/etc/openvpn/2.0/keys/

  9. Okay, everything is now in place. Our key/cert pairs have been signed by an authority and are now ready for use. For basic trouble-shooting and just generally getting our hands dirty, we simply fire up an openvpn server process on the server, and with corresponding parameters fire up an openvpn client on the client.

    Example: suppose we want to use adhoc IP addresses for the tunnel of 192.168.32.1 and 192.168.32.2 (this is known as p2p mode. As opposed to server mode, which gives you a pool of addresses that clients can use). We will use tcp port 443 (the https port). (this will usually be able to tunnel through anything if port 443 access is allowed):

    (use the full path for the certs and keys in the below bits)

    On the server we run:

    openvpn --proto tcp-server --tls-server --ca ca.crt --dh dh1024.pem --cert serverbox_vpn.crt --key serverbox_vpn.key --dev tun1 --ifconfig 192.168.32.2 192.168.32.1 --verb 4 --port 443 --user nobody --group nogroup

    On the client we run:

    openvpn --proto tcp-client --remote SERVER.IP.ADD.RESS --tls-client --remote-cert-tls server --ca ca.crt --cert laptop_vpn.crt --key laptop_vpn.key --dev tun1 --ifconfig 192.168.32.1 192.168.32.2 --verb 4 --port 443 --user nobody --group nogroup

    If udp is allowed on the port, you can just drop the "--proto tcp-*" options on the server and client.

    Eyeball the options one by one - they're pretty self-explanatory. man openvpn gives you more information. The only extra which I think deserves a little mention here is the "--remote-cert-tls server" bit, which protects against man-in-the-middle attacks.

  10. The debian init script for openvpn runs all *.conf files in /etc/openvpn. So, for regular use, we can do a no-brain-required conversion of the server command line above, to this config file on the server /etc/openvpn/openvpn.conf:


    proto tcp-server

    tls-server

    ca /etc/openvpn/2.0/keys/ca.crt

    dh /etc/openvpn/2.0/keys/dh1024.pem

    cert /etc/openvpn/2.0/keys/serverbox_vpn.crt

    key /etc/openvpn/2.0/keys/serverbox_vpn.key

    dev tun1

    ifconfig 192.168.32.2 192.168.32.1

    verb 4

    port 443

    user nobody

    group nogroup

    (You can do a similar thing for the client end, with the configuration lifted from the openvpn client arguments earlier. You would put the arguments into a file on the client, for example, /etc/openvpn/client.conf.)

That's it. You can now can softphone with ekiga/skype and access your lan applications just as if you were on the LAN itself. And it is secure, even if you are using the big bad internet to connect to your base.

The Limits:

Well, okay, it is secure, unless someone uses rubber-hose cryptanalysis or its variants (http://xkcd.com/538/). Mogambo will be happy to go that route. Oh dear.

The other problem is that openvpn isn't actually meant to hide that it is running a vpn. Openvpn as set up here hides the content, but does not hide the fact that it is doing vpn. This may be a problem if your eavesdropper is doing deep packet inspection. There are routers that will do that and will block vpn. There are no doubt ways to run vpn over port 443 so that not only the content is kept encrypted, but also the fact that a vpn is running is also kept undetectable, and I guess someone will elaborate on it in the discussion that follows.

Meanwhile, openvpn may be a solution for people in countries (like China, Australia, the UAE, Iran and Burma) who would like to bypass their national firewall and access the unfettered internet.

PJ

 

 


Posted by Anonymous (84.10.xx.xx) on Mon 17 Jan 2011 at 23:42
You forgot about ta.key, and that CA.key should not be at openvpn server ever.

[ Parent | Reply to this comment ]

Posted by pj (85.144.xx.xx) on Tue 18 Jan 2011 at 06:34
My take on this is that if ca.key is readable by an evildoer, then that person has root anyway. In which case you have MITM compromise at least.

ta.key is, from what I've understood, just an additional layer of security (http://openvpn.net/index.php/open-source/documentation/howto.html #security) and not necessary, though A Good Thing. I assumed it would be more cpu-intensive.

I could be wrong on both accounts. Like the security gurus say, real security is hard - so, discussion and corrections are welcome.

[ Parent | Reply to this comment ]

Posted by Anonymous (170.142.xx.xx) on Tue 18 Jan 2011 at 13:52
Nicely written. Thanks!

[ Parent | Reply to this comment ]

Posted by Anonymous (2a01:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 18 Jan 2011 at 21:13
Can someone provide me a list of advantages against using an SSH tunnel with -D switch?
The main drawback using SSH is the fact that it creates a SOCKS proxy, but the configuration is much easier than openvpn, and most of common network tools know how to connect through a SOCKS proxy.

[ Parent | Reply to this comment ]

Posted by marki (15.195.xx.xx) on Wed 19 Jan 2011 at 13:20
The difference is that with OpenVPN (in fact with every VPN solution) you become part of the target network and have direct connectivity.
In your SSH example you would need to re-configure all your applications when you will move between off-site and on-site locations - or run ssh even when on-site.
Another difference is that SSH doesn't support forwarding of UDP/ICMP/... connections, only TCP is supported.

[ Parent | Reply to this comment ]

Posted by mcortese (20.142.xx.xx) on Thu 20 Jan 2011 at 10:48
[ View Weblogs ]
Nice reading!

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 451 votes ~ 5 comments )