How to: Set Up Secure Remote Access with OpenVPN - Page 2
April 30, 2009
Providing a secure connection for your users
Getting your VPN link up and running, while infinitely satisfying, is something of a letdown. Sure your connection is unlikely to be spied on, but without some proper configuration, that shiny new OpenVPN link of yours is borderline useless. Follow along as we show you how to get the most out of your new, stealthy mode of communication.
Clearing the first hurdle
Setting up an OpenVPN server/client connection is straightforward in practice, if a bit tedious. You have undoubtedly noticed that it lacks any sort of immediate reward as its functionality is very limited without putting some further effort into configuring your setup for some useful activities.
One of the most common and useful activities for such a link is secure Internet access from any connection that your user happens to be on. Whether it's freely supplied wireless from the seediest of locales to their very own home network, you're certain to keep their web traffic hidden from prying eyes and your company's data secure.
This can also lead to issues with latency sensitive applications, such as VoIP, adding quite a few more hops between your user and their desired service is likely to introduce unintended results to their service experience, which will take some getting used to and could lead to disruptions.
Laying the groundwork
Oddly enough, piping your clients' traffic through your server requires just a few modifications to your server's OpenVPN configuration file. The first setting will inform your clients to forward all of their communications through the server regardless of the protocol.
push "redirect-gateway def1"
Add the line to your Windows OpenVPN server's config file, if your server and client are both residing on the same wireless network you'll want to use the following line instead:
push "redirect-gateway local def1"
As the OpenVPN server is now solely in charge of your clients' traffic you'll want them to have a working DNS server as they're no longer relying on the one their normal ISP's supplied them. Adding the next line should point them to use the machine as its new DNS server:
push "dhcp-option DNS 10.8.0.1"
We're still sticking with the default 10.8.0.1 IP address for the OpenVPN server, you'll want to change it to whichever address you decided on for your server earlier.
So now you have your clients pushing all of their data at your server expecting it to handle all of the duties a service provider would be responsible for. That'd usually be no small task and it'd require quite a bit of figuring out on your part if you wanted custom solutions for each and every protocol your users might require.
Thankfully Microsoft's Internet Connection Sharing is able to handle a good bulk of the traffic your server is likely to encounter from your clients. The simple act of enabling ICS and allowing the program to handle most of the common services will give your clients access to a bulk of the web services they'll need.
In order to enable ICS you'll have to open up the properties page for the connection, on your server, that's connected to your Internet facing network. You'll likely find it under the Network Connections option in the Control Panel. The advanced tab will allow you to enable ICS and some additional settings/services you might like to allow your clients to have access to.
You're likely thinking that third-party connection sharing applications can perform the same functions as ICS. However, for the sake of simplicity, we're sticking with what's freely available with most Windows installations.
Once you've restarted your OpenVPN server's session after all of these changes the simple way to test if all of this has worked would be to load up a IP Address lookup website (http://whatsmyip.org/). The result should match the actual IP Address of your server, confirming that the server is fetching and transferring files to your client correctly.
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.