Securing your network locally is, relatively speaking, a simple process given that you have physical control of all the cables and hardware that your machines are connected to, so there’s no real need to worry about the data being shared. Things get a bit more complicated when your employees are working in remote locations where your valuable data could be passing through compromised networks.
In this guide, we’ll be taking a look at the budget-friendly and open-source way to offer road warriors a secure connection back to home base.
The list of instances where some form of remote network access is necessary has grown as an appreciation for the value of data and its secure transfer (as well as the productivity of employees working during their weekends off) has opened the eyes of many a manager.
There have been plenty of choices (read: hacks) when it comes to offering secure, remote access to network resources, but as with any market, most everyone settled on a single approach that works well enough and manages to handle a company’s needs without much fuss.
Virtual private networks (VPNs) are capable of creating an encrypted data transfer layer over a network that provides secure communication regardless of where the clients and server are located. There are several choices available vying for your networking dollars but one of the most powerful and flexible options just so happens to be open-source.
The last command created the software’s certificate authority and its key.
Up next we’ll be creating a key for the server itself, its Common Name entry should be server. Acknowledge both questions in the affirmative:
That’s all for now on the server side of things, up next we’ll be creating some keys for the clients you’ll have connecting to your VPN server. The keys can be named whatever you’d like although a naming scheme would be preferable and, once again, the Common Name entry must match the key’s name:
Alternatively the build-key-pass command can be used in place of build-key in order to password protect client keys.
Finally the last command you’ll have to run creates Diffie Hellman parameters:
Here’s the point in time where you’ll have to transfer your keys and certificates to the machines that need them, all of which currently reside in the keys sub-directory in the easy-rsa folder.
Each client should have a copy of their generated certificates and keys, which should have the naming scheme client.crt, client.key and a copy of the ca.crt file. On the server side of things you’ll have copies of ca.crt, server.crt, server.key, and dh*.pem.
The keys and certificates didn’t play all to well under the Program Files directory so you’ll want a simple directory structure for them to reside in.
Setting it all up
OpenVPN’s configuration files control the program’s function making it either a server or a client. You’ll find a trio of configuration files under the sample-config directory in the main OpenVPN folder. Server.ovpn is of course set up for a server role. You’ll want to point the ca, cert, key, and dh settings to the files you created earlier. At this point you should also set the port you want the server to listen for connections on.
Client.ovpn sets your remote client up to connect to your brand new VPN server. For this you’ll need to add your server’s web address and port setting on the remote line overwriting the my-server-1 line. Continuing on, you’ll have to point the ca, cert, and key lines to the corresponding files you copied over to your client.
Be sure to make a few last minute checks on your network to make sure you port forward your VPN’s port to the server. It’s a simple oversight but it’s bound to cause plenty of headaches.
If all has gone well you’ll have two last tasks, starting the server with its configuration file, waiting for it to initialize, then starting the client’s software with its very own config file. Simply right clicking on the respective .ovpn file and choosing Start OpenVPN on this config file will begin the process on each machine.
A message on the server stating Initialization Sequence Completed will inform you that everything went fine on its end while a ping command on the default IP address OpenVPN at 10.8.0.1 should show successful responses.
Most issues encountered at this point have to do with an improper setting for the server’s hostname or port number in the client’s configuration file or an issue with the public facing port not being properly routed to the server.
All of your hard work has netted you a VPN connection between two machines. Unfortunately it’s not capable of doing much until we configure some settings further. We’ve covered plenty of ground so far, but stay tuned to explore the benefits of your VPN connection.
Something you’re likely to run into when tinkering with ICS settings is OpenVPN’s apparent unwillingness to work on your server, spitting out “Warning: route gateway is not reachable on any active network adapters” errors. Windows doesn’t seem to play nice with OpenVPN on occasion but the prowess of the Internet at problem solving has come up with this gem of a forum thread with a working solution should things head south on your server.
The following commands in a command prompt and a subsequent reboot should give you a working configuration again:
netsh int ip reset logfile.txt
netsh winsock reset catalog
If everything went smoothly, your clients should have a safe and secure method of browsing the Internet at large and use the various the web-based applications they require. However, there are as many use cases as there are corporate networks There is more to OpenVPN which we’ll be sure to cover in future installments.