While at a previous employer, I came across an interesting article in the now-defunct SysAdmin magazine which covered, soup-to-nuts, setting up a rather basic OpenVPN server and NSIS-based Windows client package. It wasn’t long before I got hip deep in to customizing the Windows installer NSI script, and tweaking the server configuration. Eventually, I configured up a Solaris 8 system in our data center to act as a secondary openvpn server (using the “tun” package), and all of the adminstrators/dba’s were very happy with the results.
Nearly two years and two employers have passed by, and I find myself going through a similar setup. Unfortunately, i discovered that the backup of the files I took when I left my employer did not contain some of the key files, so I had to start back at square one. The article was a great starting point, but I was worried that, since the magazine was now defunct, the article might not be around for much longer (although, as a subscriber, I received a CDROM containing all of the issues).
The article was also rather basic, and not very security conscious. Additionally, some key steps (such as managing client certificates) were completely left off. I’ve attached the original article for posterity.
The Server
To start off, the server needs to be set up and configured. Some key items to keep in mind:
The standard OpenVPN port is 1194. However, there is nothing stopping you from running it at a different port.
Decide between a “bastion host” setup versus a “completely integrated setup” (I’ll cover these in a moment).
On an RPM based distro, install the openvpn package. In addition to the core openvpn components, it will also install a series of SSL/cert management tools in a directory at /usr/share/doc/openvpn-<version>/easy-rsa. Copy that entire directory to /etc/openvpn/easy-rsa. Now, cd to /etc/openvpn/easy-rsa, and take a look at the README file to familiarize yourself with the steps. The general breakdown is:
cd /etc/openvpn/easy-rsa
edit the “vars” file to your liking. The only things I changed were the KEY_SIZE to make it 2048, and the KEY_ values to reflect the company’s information. Save the file.
Now that the certificate and keys have all been made for the server, there are a few additional steps to set up the directory structure and generate a server port key:
cd /etc/openvpn
ln -s /etc/openvpn/easy-rsa/keys keys
openvpn –genkey –secret port1194.key
useradd openvpn (if the account hasn’t been created already)
echo 1 > /proc/sys/net/ipv4/ip_forward
At this point, all of the security components are set up and actual configuration of openvpn is necessary. I’ve attached a modified version of the sample server configuration file, but the highlights of the file include forcing out DHCP entries, setting routes, communicating via UDP only (UDP is much more efficient than TCP in this situation, so use it if you can), and logging.
Openvpn can handle multiple port configurations as it will read the /etc/openvpn directory and look for all files ending in “.conf”. In most cases, you will only be working with one, but it is nice to know it supports multiple.
Once the configuration file is in place (openvpn Port Configuration File) in /etc/openvpn, start up openvpn via /etc/init.d/openvpn start and check the log files in /var/log/openvpn for information. The server is up, and now on to the clients.
The Clients
The poor-man’s way of doing things is to create one client certificate and hand it out to everyone. While this works, the down side is that it makes it next to impossible to seamlessly deactivate any one person’s access. The best practice is to create individual certificates for each user, and provide them to the individual users. Since the server has a copy of the user’s certificate, you can easily (re)move a certificate to disable a given user.
Remember these. We’ll need two of them (the .crt and the .key) for later use when they get copied over to the client.
Client Side
The article has some good coverage of the steps necessary on building the Windows client via NSIS, and, personally, I think it (NSIS) is awesome. After installing NSIS and downloading the openvpn gui (from the link in the article), I was testing the installer in no time. Now, I did have to tweak the nsi file a number of times, just to get the default version working since it seems that the NSIS plugins have been updated to conflict with some settings in the default NSI. So, I modified that NSI to get the final version of the openvpn.nsi file that is fully branded, installs our ca.crt (which was copied over from /etc/openvpn/keys/ca.crt), sets up all of the start menu items, and installs our client configuration file.
With the installer package built and tested, it can now be supplied to the user, along with the clientname.key and clientname.crt files and instructions as to where to place those two files.
Bastion host versus Complete Integration
Getting the user(s) access to the network via VPN is a good chunk of the battle, but you really have to decide how you want to support this new VPN network. Right now, the only access they really have is to the server running the openvpn process. The other machines on your network do not know how to communicate back to this new network you created (remember, you’ve just turned this server in to a router).
A bastion host is a host that sits within your network that your VPN user(s) can log in to, and, from there, jump around to the rest of the network. It is essentially a terminal server for those Windows folks out there.
However, if you would rather provide direct access from the machines coming in via the VPN, you would have to either:
On each host on your network, add a route to your new vpn network with your openvpn server as the gateway, or
On each router in your network, add a route to your new vpn network with your openvpn server as the gateway.
The party line from both RIM (makers of the Blackberry) and Verizon was that there was no way to move SMS messages from one Blackberry to another. The provided software from both parties only allowed backing up the contacts, email, and any related data (photos, video, etc), but they both stood hard and fast stating that those were the limits.
Unfortunately, we had a user who absolutely needed to have the SMS messages copied from their 8830 to their new Blackberry Curve, and they wouldn’t give up the old phone until the messages were moved over.
Linux to the rescue! Using the tool called barry, we managed to perform a full backup of the 8830 and successfully restore it to another 8830. Unfortunately, we couldn’t restore it to the Curve because barry wouldn’t recognize the curve with the version of barry that we had (0.12). Additionally, we couldn’t modify the backup file (a tar.gz file containing directories and binary files of the messages) in any way (not even a simple untar/uncompress and immediate tar and re-compress) since barry would immediately complain about the contents.
So.. here we had a backup, but couldn’t get it on to the curve. Some browsing through the mailing list archives for barry turned up an obscure reference to the CVS repository for another fix, so we checked out the CVS repository, built and installed, and gave it a shot.
It worked to a certain level.. It transferred 78 of the 128 SMS messages, then hung. A second attempt (after killing off barry) got to 108 messages before hanging, and the end user was happy with the 108 messages (they included the ones they wanted to save) and we left it at that.
Wiping the blackberry was easy:
Go To Options
Select Security Options
Select General Settings
Click the Menu key and select Wipe Handheld
Click Continue and follow the prompt by entering the word blackberry
The unit will then wipe itself and it will be back to factory defaults.
We have a number of systems that run the bleeding-edge RPM based distribution Fedora. Because of the rather quick Fedora release cycle, people are forced to either keep up with the curve, or be left behind in the dust. Typically, only the current and last most recent version are supported, and this support comes in the form of updated packages and/or security fixes. If you aren’t updating your systems regularly, it can become quite easy to fall way behind the curve, especially if you have even the slightest touch of the “If it ain’t broke, don’t fix it” mentality.
Although it is usually ill-advised, following the instructions at the YumUpdateFaq for performing live OS level updates via Yum has proved to be something that is both rather simple and extremely effective. Personally, I have seen a lot of success with it.
Recently, however, there was a need to upgrade a system from the i386 architecture to the x86_64 architecture, primarily to reduce the number of repositories that were being rsync’ed nightly, but also to utilize the full resources of the system. This type of upgrade is commonly referred to as a ‘cross-grade’. The first instinct with any upgrade is to perform a clean install and just move over the configuration files, and that method is truly the Best Practice ™.
Unfortunately, in this particular situation, a scorched-earth mentality did not seem to fly. This system runs a large amount of services (clustered, thankfully), and when trying to configure up the clean install, something (still not sure what) was not making it across. User account lookups (via nss_ldap) were hanging after an hour (or more) of system up time. It got to the point where we had to back out and go back to the old i386 install.
Again, using the VM image, we tried out the method found on Linux.com, which had a nice feature article (http://www.linux.com/feature/123800) on this very topic, and, while the article was a little fluffy in some areas, it was extremely accurate. This can be said because we were very very happy with the results. After proving that this method worked within our test environment, we backed up our production environment and went through the exact same steps.
Once the Yum upgrade was complete, we did have to fiddle with a few of the configuration files of some of the applications (samba, cups, etc) to get them working the way we wanted, we were back up and running live in very short order. Now that the system has been upgraded, we could address the numerous packages that we hand rolled (and yum did not know how to update) and the duplication in i386 and x86_64 packages while the server was still providing services to end users.