This guide is pretty simple to follow and should have an OpenVPN server on debian or ubuntu working within half an hour. I’ll also explain how to connect to the VPN from a windows PC.

First, install OpenVPN on the server (you’ll need to be root for all of this guide)

apt-get install openvpn

Next, we need to configure the server. You need to make a decision here whether you want tun (routed) or tap (bridged) connections. The main difference is that tap will give the client a network address on the server network, whereas tun creates a private network managed by the server. In this guide I will use tap because I find that it works better with windows clients.

Now you need to create certificates for the server and client for authentication purposes (which is much more secure than the passwords used in pptp). This is done through a number of steps:

Preparing to generate the keys

mkdir /etc/openvpn/easy-rsa
cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa

Now you need to edit /etc/openvpn/easy-rsa/vars with your required settings. You only really need to change the last section which is the default values for the fields in the certificates.

Generate the certificate authority (CA) which will be used to sign the server and client certificates.

cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca

Next, we need to create the server keys

./build-key-server servername

Answer ‘yes’ when asked to sign the certificate and commit to the database, and then you’ll need to generate the diffie-hellman parameters which are used for key exchange between the client and server.

./build-dh

And finally, create some client keys which will be used to allow clients to authenticate with the server. I prefer to use pkcs12 which stores the client public key and certificate in one passworded file.

./build-key-pkcs12 client1

As before, sign the key and commit to the database. You will be asked for a password which the client will use to connect to the server.

Now all the keys are created, we need to configure the server.

vim /etc/openvpn/server.conf
(add the following lines)
port 443
proto tcp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/servername.crt
key /etc/openvpn/easy-rsa/keys/servername.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.1.0.1 255.255.255.0 10.1.0.236 10.1.0.245
push “route 10.0.0.0 255.0.0.0″
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3

The only lines which you will need to change are ‘server-bridge’, which is simply the default gateway, subnet mask, and the start and end IP’s to assign the clients, and the push route, which pushes specific routes to all clients.

Now we need to create an ethernet bridge. First, we need to install bridge-utils:

apt-get install bridge-utils

Rather than explain how to set up a network bridge, I found a shell script which will do it for you. This can be found here. Just edit this with your network settings and execute it. You will also need to set it to create the bridge at boot time:

update-rc.d bridge defaults

Now you can start the openvpn server

/etc/init.d/openvpn start

Now we need to set up the windows client. First, download the OpenVPN client from here (at the time of writing, select 2.1 RC15). Install it, and create a file ‘client.conf’ in the config directory with the following parameters

client
dev tap
proto tcp
remote x.x.x.x 443 # (replace with your server IP)
resolv-retry infinite
nobind
pkcs12 client1.p12 # (replace with the client name)
ns-cert-type server
comp-lzo
verb 3

You can also add ‘redirect-gateway’ to the client configuration to pass all traffic down the VPN tunnel (rather than just traffic intended for the VPN itself).

Now copy the client1.p12 certificate file to the config directory on the client, start the gui, and connect. Everything should now work.

If you need to create any clients in the future, do the following:

cd /etc/openvpn/easy-rsa
source ./vars
./build-key-pkcs12 clientx

If one of your certificates is compromised, you can revoke it using the guide here.

This guide has been written from my notes and what I remember, so there may be a couple of things which aren’t 100% right. If anything goes wrong then post a comment or contact me and I’ll update the guide.

Bookmark It

With the ease of use though, there are some downfalls. PPTP is known to be less secure than other VPN’s such as OpenVPN and IPSEC, but for most uses it should be fine. One advantage over my hamachi VPN is that you will end up with an IP on the remote LAN (instead of the 5.0.0.0/8 address you have from hamachi), meaning you don’t need to do any routing tweaks.

First, set up the server:

apt-get install pptpd

That’s it! Now, to configure, you just need to edit 2 files:

/etc/pptpd.conf
Just add 2 lines to the bottom of the file, for the internal IP address of the server, and a range of IP’s which the remote connections will use.
localip 10.1.0.50
remoteip 10.1.0.90-99

The comments at the bottom of the file show some other ways of assigning ranges of IP’s in the remoteip section.

Finally, to add a user, edit /etc/ppp/chap-secrets and add a line for a remote user in the format:

username pptpd password *

To limit connections from specific hosts, use them instead of the * at the end.

To set up the connection on a windows XP client, do the following (from Control Panel):

Network Connections
Create a New Connection
Next
Connect to the network at my workplace
Virtual Private Network connection
Enter your connection name
Do not dial the initial connection
Enter the IP of your server

Then run the connection with the username and password you entered into /etc/ppp/chap-secrets

By default this will route all your traffic (including normal web browsing) through the tunnel. If you don’t want this, go to the connection properties, then the networking tab. Choose TCP/IP properties, and click ‘Advanced’, then finally untick the ‘Use default gateway on remote network’ tickbox.

That should be all you need.

Soon, I’ll give OpenVPN a try, and try to write up a nice guide here.

Most of the information above came from other sites, and by googling. If anyone knows of a better or more secure way of using PPTP then please post comments below.

Bookmark It

This can all be done using the free hamachi version. I have a premium license so I can make the network more secure by having to authorise new members.

This guide covers connecting a windows XP machine to private networks with linux and windows machines acting as the routing nodes.

I have 2 networks in my office, 10.1.0.0 and 10.2.0.0. I use the VPN for connecting my laptop to these networks from home.

Setting up the ‘client’ XP machine (the one which needs to VPN into the networks)
- Download and install hamachi
- Create a new network specifically for the VPN.
- Add ‘RoutedTunneling 1′ to hamachi-override.ini and restart Hamachi. You may need to create this file by clicking Configure, Preferences, System, Open Configuration Folder – then create hamachi-override.ini
- Click Start, Run and type ‘regedit’, then set HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersIPEnableRouter to 1
- Reboot and open hamachi.

First ‘server’ – Windows (10.1.0.53 is the example local IP)
Follow the instructions above, but instead of creating a new network, join the one you previously created. That’s all you need to do to get a windows server set up.

Linux ‘servers’ (10.2.0.201 on my local network)
- cd /opt
- wget http://files.hamachi.cc/linux/hamachi-0.9.9.9-20-lnx.tar.gz
- tar -zxvf hamachi-0.9.9.9-20-lnx.tar.gz
- cd hamachi-0.9.9.9-20-lnx/
- mkdir /dev/net
- make install
- tuncfg/tuncfg
- hamachi-init
- hamachi start
- hamachi set-nick servername
- hamachi login
- hamachi join networkname networkpassword
- hamachi go-online networkname
- echo 1 > /proc/sys/net/ipv4/ip_forward

Note that whenever the linux machines are rebooted, /proc/sys/net/ipv4/ip_forward will reset to 0.

The server nodes are now setup to forward IPv4 packets around the network.

This next step is where most problems will occur. The server nodes will forward packets to the network, but other machines on the local networks don’t know where to send data to 5.x.x.x addresses. I set up rules on our firewall which work something like:
Requests to 5.0.0.0/8 need to be routed to 10.1.0.53 on the 10.1 network
Requests to 5.0.0.0/8 need to be routed to 10.2.0.201 on the 10.2 network
This is one rule for each of the networks I need to access. I’m not sure how to do this in different firewall setups so I’m not much help here.

Everything is now setup, but the ‘client’ node doesnt know where to send packets to any of the 10.1 or 10.2 networks. To fix this, we need to create routes on the machine. I created 2 batch files, one to connect the VPN, and one to disconnect.

Connect batch file

Obviously you’ll need to put the hamachi IP’s of each of the server nodes in this file.

Disconnect batch file

At this point everything is set up and ready to connect. You will need full connectivity to all the server nodes which you are using (green icons in hamachi).

Then you run the batch file to connect the VPN (or just type the route commands into a command prompt manually). Test pinging the local address of the server nodes, then other addresses inside the remote network.

Diagnostics
First, try pinging the local address of one of the server nodes (10.1.0.53 in my example). If this doesnt work, then my guess is that the route command hasn’t been done correctly.
Next, try pinging another machine on the local network (10.1.0.50 for example). If this doesnt work, then it’s likely that the server node isn’t forwarding the packets correctly, or the responses from the machine you’re pinging aren’t being sent back to the server node properly – check the firewall routing and make sure you’ve set /proc/sys/net/ipv4/ip_forward to 1.

Note that this whole setup will only work if the client node is actually off of the local network at the time you try to connect. By this, I mean that when I am at work, my laptop has the IP 10.1.0.56 and it connects out via 10.1.0.1 – obviously the VPN wont work while I’m at work because the route command will override the default gateway route and stop me connecting out at all.

Bookmark It