I wanted a virtual private network (VPN) connection I could use between my laptop and my home system wherever I might be. A bit of research showed that VPNs can be tricky and messy, as well as leaving your home network wide open if you didn't do it right. I could do it with SSH tunneling, but experimentation showed that to be a bit clunky, and required me to write some custom scripts. Why not let experts write the scripts? Which brings us to OpenVPN, available on many Linux disties.
After much googling and fiddling around, I came across this set of instructions for a simple one client, one server setup. Let's look at the writeup's advantages and disadvantages.
Static Key advantages
- Simple Setup
- No X509 PKI (Public Key Infrastructure) to maintain
Static Key disadvantages
- Limited scalability -- one client, one server
- Lack of perfect forward secrecy -- key compromise results in total disclosure of previous sessions
- Secret key must exist in plaintext form on each VPN peer
- Secret key must be exchanged using a pre-existing secure channel
The two advantages are great. Simple setup is always good. I'm not sure what a Public Key Infrastructure is, but if I don't have to maintain one, that's fine by me.
Disadvantage one is actually an advantage for me. I only need one of each, and any more would be unnecessary, and so a potential security problem. Disadvantage four is a non-issue. I set up the laptop and tested the VPN from inside my home network, and scp does just fine. Disadvantage two could be serious, see disadvantage three. Disadvantage three could be serious if the laptop is ever compromised. So make sure the laptop is never compromised.
For a first go at a VPN, this is acceptable. I may later try a less vulnerable form of VPN; we'll see.
With that analysis done, it's time to implement the VPN. I followed the instructions with suitable changes for my situation.
It isn't clear in the writeup where the client and server configuration files live. They live in client.conf and server.conf, respectively, in /etc/openvpn. For Ubuntu, and possibly other operating systems, you can use any name you want so long as it ends in .conf. The startup script for OpenVPN will pick it up and attempt to open a VPN connection for you at boot.
After testing the simple configuration, I added compression and enabled the failure resisting features. I also set the two ends to run as daemons. This requires adding the user and group nobody to an Ubuntu system.
Now for the fun part: firewalling. The writeup says, "Bear in mind that 90% of all connection problems encountered by new OpenVPN users are firewall-related." I did all my testing so far inside my private network. So I could drop my firewalls. That's fine for testing but useless in the real world. Since I use Firestarter on my machines, I had to integrate the OpenVPN devices into Firestarter.
After much googling, I came across ngarret's writeup, Firestarter and OpenVPN, VMware, which refers to this page. The first page shows what to do for both OpenVPN and VMware. Since I also use my desktop as a virtualization host, I modified the lines for the latter for KVM, as follows:
root@dzur:~# cat /etc/firestarter/user-pre # Allow traffic on the OpenVPN interface $IPT -A INPUT -i tun+ -j ACCEPT $IPT -A OUTPUT -o tun+ -j ACCEPT # Allow virtual machine traffic $IPT -A INPUT -i virbr+ -j ACCEPT $IPT -A OUTPUT -o virbr+ -j ACCEPT root@dzur:~#
Note that these two stanzas allow traffic from the VPN and virtual machines indiscriminately, which may not be what you want.
(The first stanza is in the Firestarter documentation, but I didn't find that until I started on this writeup. Sigh.)
You can specify which VPNs OpenVPN will try to start when you fire it up. On Ubuntu, this and other options are set in /etc/default/openvpn. Since I have two profiles, and only one will work at a time, for remote access I set AUTOSTART="remote".
Since I don't use the laptop outside my own network very often, I have the OpenVPN daemon set to not run at boot. So I have to run it manually when I want it. This is acceptable, at least for now.
Field testing consisted of taking my laptop to the home of a friend who doesn't have the same ISP I do. The requirement is because my ISP, probably like a lot of them, does not allow traffic between two customers. So I can't SSH or VPN in to my home from my favorite local espresso stand/bookstore. Drat.
Field testing worked perfectly. I plugged the laptop in to my friend's cable modem. I had to hand configure the network (yet more Komic Koala Keystone Koppery?) but OpenVPN is independent of that. Once on the Internet, all I had to do was:
service openvpn start
I was able to access an internal web server and other services via my virtual device. Et viola! Proof of concept!
On conclusion of the testing:
service openvpn stop
To make life easier, it would be nice to have name resolution for the home network. I run bind 9 on the laptop, as a spare DNS server for the home network. So all that should be necessary is to make sure it's running, and then hack a localhost IP address into /etc/resolv.conf. That's next.