Virtual Private Networks (VPN’s) allow for users to bridge network connections using the Internet. Such connections and setups are routinely employed by businesses in order to allow employees traveling outside of the office to connect to the same servers and services that users would typically only have access to if they were sitting inside of the building. However, if you are running a Linux server of your own (either a remote VPS or dedicated box), you can employ the same mechanism to connect securely to your server. Why would you want to do this? For one, savvy users can better lock-down otherwise public services to bind to “internal” VPN IP addresses so that only users connected and authenticated to the VPN can use them. Moreover, if you have excess allowances of bandwidth on your server, you can take advantage of the VPN to route all of your Internet traffic through your server. There are various reasons why you would want to do this, including connecting to regionally restricted services and maintaining a static IP address.
Now, I personally recommend setting up OpenVPN if you are looking for a more secure setup. However, users looking for a simpler option will definitely want to look into the Point-to-Point Tunneling Protocol (PPTP) daemon package available on pretty much every well-supported major Linux distribution as the setup process is much easier.
So how do you set up the PPTP server? To start off, you need to be on an Xen VPS (not OpenVZ) or on a dedicated server, as we will be using IPTables to control traffic routing. In this example, I am using a copy of Debian on a VPS. The first step is to log in as the root user via SSH and install the package.
apt-get install pptpd
Of course, if you do not have access to the root user but do have access to a user in the /etc/sudoers file, you can prefix the command with “sudo” from a standard account in order to achieve the same task.
sudp apt-get install pptpd
Once you have the package installed, you will want to edit the main configuration file for the daemon so that you can define a local IP address for the VPN interface on the server. The main configuration file is called “pptpd.conf” and can be found in the “/etc” directory on the server. To edit it, use the following command, prefixing it with “sudo” if necessary.
Using the arrow keys on your keyboard, you will want to navigate to the bottom of the file and add two lines that will define the IP address for the server to use as well as the IP address range that you would like to be assigned to clients connecting to the VPN. One thing that you will want to keep in mind is the fact that you will need to use internal IP addresses that are reserved for such localized uses in private network. For more information about the reserved ranges that you can use, you should look at the RFC 1918 specifications.
In my case, I’ve opted to use “192.168.216.1” as the VPN interface IP address for the server, as it is a designated/reserved local IP and is outside of other ranges that I use so I will be able to avoid confusion. Likewise, I have opted to use “192.168.216.2” through “192.168.216.5” as the IP addresses that will be assigned to clients. To achieve this, I will be adding the following lines;
With this task completed, you need to close the nano text editor and save the file using the “Command + X” key sequence on your keyboard, selecting “y” to confirm the changes, and pressing the return key to confirm the location of the file.
Next we’re going to pop open the PPTPd “options” file and add a handful of additional lines at the bottom.
At the bottom, add;
Keep in mind that you will need to change the “ms-dns” option (shown in my example as “0.0.0.0”) to the DNS server provided to you by your server host. Again, use the “Command + X” key combination to save and close the file and nano text editor.
Once we have the bulk of the PPTPd configured, you will want to configure the users, passwords, and hosts that you would like to be able to connect to the VPN. To do this, use nano to edit the “/etc/ppp/chap-secrets” file.
In this file, you will want to add users in the form “pptpd”. For example, if I wanted the user “mike” to be able to log in with the pass “abc123” from the IP address “0.0.0.0”, I would add the following line to the chap-secrets file;
mike pptpd abc123 0.0.0.0
At this point you should also take note that the “host” field can contain wildcard “*” characters. With this in mind, I could allow the same user to log in with the same password by adding this line instead;
mike pptpd abc123 *
Again, save the file and close nano.
At this point, you can apply the changes that you’ve made by restarting the point-to-point daemon by using the init.d file that the package created during installation. From your terminal, run the following command;
Once you’ve completed these steps, you should have a working daemon setup. Consulting the networking documentation for your operating system should provide specific information for setting up the VPN connection on your client desktops, but in general you simply need to navigate to your network utility and follow the wizard to create a new VPN connection. Provide it with the IP address or hostname of your server, as well as your username and password that you configured in the chap-secrets file and you should be able to connect.
But what if you want to bridge your Internet connection or make other network resources (services and servers on the same network as the server) available to remote users? This requires a couple more steps, but isn’t that big of a challenge.
We need to open the “sysctl.conf” file that resides in the “/etc” directory on your server.
Next we simple need to hunt down the line containing the option “net.ipv4.ip_forward”. Make sure that said line isn’t commented out (there isn’t a “#” in front of it) and that the value is set to “1”. When all is said and done, the full line should look like this;
Now, this has changed a setting on the server and will not be applied immediately. To apply the setting, you can restart the server or issue the following command from the terminal;
Last but not least, we will need to allow the bridging/routing in IPTables by running the following command, replacing the IP (in my example, “192.168.216.0/24”) with the range you specified as “remoteip” in the “pptpd.conf” file earlier in this example.
iptables -t nat -A POSTROUTING -s 192.168.216.0/24 -o eth0 -j MASQUERADE
And if you’re using port whitelisting with IPTables, you will need to unblock port 1723 in your firewall.
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
If you want your computer to route all Internet traffic through the VPN, you will probably need to enable an additional option when setting up or configuring the VPN on your desktop. In Mac OS X, this can be achieved in the “Advanced” tab in the VPN settings panel.
Once your VPN is all setup, you can toy around with different settings. In one example, I have used a VPN to bind the listening daemon of the ZNC IRC bouncer to the local VPN interface (in my example, I used “192.168.216.1”) so that only users connected via the VPN can utilize the service. This process varies from daemon to daemon, and you should consult your application documentation before doing anything like this.
As always, I highly recommend that you try this out on a non-production testing server before you implement it. Personally, I would consider a low-cost server provider such as Rackspace CloudServers to test on as you can delete your deployment immediately after using it and only be billed for your usage. Keep in mind, though, that while CloudServers is very cost-effective, their bandwidth can bite a pretty large hole in your wallet if you’re not mindful of your use. That said, I’d definitely look at other providers who give pre-defined bandwidth allowances. You should also note that when using PPTP as a bridge to route Internet traffic through you will be using double the amount of bandwidth you would use if you were connecting directly. Why? The content is downloaded pulled to the server once, and then is sent out to the client. Downloading and re-uploading utilizes twice the amount of bandwidth.
Use this setup at your own risk, and always be mindful before making changes on your server. For a simpler solution that doesn’t require the use of your own server to bridge networks (this option does not allow for Internet bridging, though), you may also consider something like LogMeIn Hamachi for a zero-configuration VPN.