In this article we explain how you can easily steup an OpenVPN server on Ubuntu 14.04, step-by-step with pictures.
Set Up the Certificate Authority
In order to get going with your OpenVPN setup on Ubuntu, you need to first setup your certificate authority. This enables you to create both public and private certificates for other computers which is important for you to set up encrypted connections between different computers.
sudo apt-get install openvpn easy-rsa mkdir /etc/openvpn/easy-rsa/ cp -r /usr/share/easy-rsa/* /etc/openvpn/easy-rsa/
Next step, edit /etc/openvpn/easy-rsa/vars and adjust the elements below to your environment:
—————————————-
export KEY_COUNTRY=”US”
export KEY_PROVINCE=”NC”
export KEY_CITY=”Winston-Salem”
export KEY_ORG=”Example Company”
export KEY_EMAIL=”bill@example.com”
export KEY_CN=MyVPN
export KEY_NAME=MyVPN
export KEY_OU=MyVPN
——————————————
Type in “sudo su” to become root. From now on, everything you will be running, will be run out as root. Root minimalises the number of errors. It isn’t a jolly game, but it is recommended.
cd /etc/openvpn/easy-rsa/ mkdir keys source ./vars ./clean-all ./build-ca
Afterwards, you will prompted by a message in which you will accept the defaults. It is possible to be prompted by an error message about that is similar to ” STR_COPY:variable has no value:conf_def ” which means that you will have to export a separate variable. In order to fix this, go to the line the error mentions and add the line export KEY_ALTNAMES=”<your alternate name here>” to the vars file. You should now return the commands “source vars” and “./clean-all” followed by “./build-ca”.
Create the Server Certificate
In this step we are setting up both public and private keys for the actual user to enable the server to establish its end of the encrypted tunnel between itself and any other computer.
./build-key-server <your server name>
Accept defaults. But, you will only need to change the password.
Next, say “yes” when you are requested to sign the certificate.
./bulid-dh cd keys cp <your server name>.crt <your server name>.key ca.crt dh2048.pem /etc/openvpn/
Create the Client Certificates
It’s time to create certificates to be used by the client. These certificates are generated on the server, then copied over to the client. Moreover, you should delete any client certificates when you are finished on the server because the server should only need these certificates when you want to keep a backup copy. Though this method couldn’t be ideal for business use, but it is good enough for home use. Note that if any attacker threatens your server, they can spy on any message you send out.
cd /etc/openvpn/easy-rsa/ source vars ./build-key your_client_name
Select default setting, but add a strong password. Sign the certificate and type y to confirm.
You should now copy the files below to your client.
/etc/openvpn/ca.crt
/etc/openvpn/easy-rsa/keys/your_client_name.crt
/etc/openvpn/easy-rsa/keys/your_client_name.key
I just zipped everything up with
zip <name of your archive> <file1_to_zip> <file2_to_zip> <file3_to_zip>
It doesn’t matter where you keep your files, for the moment. Only make sure you know where they are stored on the client.
Configuring Your Server
This step explains how you can configure your VPN server. You can start your VPN configuration by typing the code below. We will make some modifications later.
sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/ sudo gzip -d /etc/openvpn/server.conf.gz
Next open up /etc/openvpn/server.conf in an editor.
At this point you will need to modify the line below so that they can be pointed to the certificated you have generated in the steps above. You should be in “/etc/openvpn/easy-rsa/keys/” (on the server) by now. If you aren’t, then all you need to do is to change everything to the absolute path of wherever you stored them.
ca your_path/ca.crt
cert your_path/your_server_name.crt <— Same name as whatever you choose it the “Set Up Server Certificate Section”
key your_path/your_server_name.key
The line below is the final line you will be needing to modify in server.conf (same file as above). Now, look into your /etc/openvpn/easy-rsa/ directory. If you see “dh2048.pem” instead of “dh1024.pem” in the directory, you would have to change to have your absolute path to dh2048.pem instead, so your line will end up looking like this, for example: “dh /etc/openvpn/easy-rsa/keys/dh2048.pem”.
Now that everything is going well this far, you can move onto the next step:
sudo service openvpn start
This should start without any errors.
Try an “ifconfig”. A “tun0″ interface should appear indicating that everything is going fine.
Configuring the Client
Before you get down to configuring your client, you to need to first install OpenVPN.
sudo apt-get install openvpn sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/
Copy the client certificate and key files to the client. You now need to move the files from the client computer to the /etc/openvpn directory.
There should be by now: three the server’s ca.crt file and the two client files <name>.crt and <name>.key
Edit the /etc/openvpn/client.conf file.
Change the lines below to the correct path. Unless you stored your files in the /etc/openvpn/ directory, you will have to adjust the path.
ca ca.crt
cert your_client_name.crt
key your_client_name.key
Your configuration should have “client” command in it, so make sure that it does.
Next, change the following line:
remote vpnserver.example.com 1194
to the suitable name/ip and port of your VPN server.
Once you’re done with that, start the service with “sudo service openvpn start”. You should see by now a tun interface appearing in your ifconfig. If not, then run “sudo ifconfig” a few times in order to see it.
If you’re on the correct page, you should be able to ping the tun0 interface of the server by now. Remember to configure port forwarding for port 1194 to your VPN server, if you’re on a home network or any network with a NAT/firewall. A very common mistake among users is setting TCP forwarding instead of UDP, so remember that you are forwarding UDP port 1194.
Using Routed VPN to Connect to Subnet Behind VPN Server
You need to add a couple of routes to the VPN server in order to enable the VPN client to connect to the machines behine the VPN server. You can start by enabling IP forwarding with:
sudo sysctl -w net.ipv4.ip_forward=1
PAY ATTENTION! if you restart you will have to reset this option. However, if you want to set the option permanently, edit /etc/sysctl.conf and uncomment the line net.ipv4.ip forward=1. This action should take effect when you reboot.
This action alerts Linux to enable interfaces to forward traffic between each other. Next, you’ll need to add a route to your VPN server to order the server to route traffic inbound to your local subnet out the adapter associated with the local subnet. For example, you have a network that looks like the one below:
According to the above diagram <your_vpn_subnet_ip> = 10.8.0.0/24, <local_subnet_ip> = 192.168.0.0/24, <local_subnet_ip_interface>=eth0, and your internal gateway would be 192.168.0.1.
In order to add the routing routes we need, we will use iptables. Type the following on your server:
sudo iptables -I FORWARD -i tun0 -o <local_subnet_ip_interface> -s <your_vpn_subnet_ip>/mask -d <local_subnet_ip>/mask -m conntrack --ctstate NEW -j ACCEPT
You’re now telling Linux that you’re setting up a rule to forward traffic inbound to tun0, sourced from <your_vpn_subnet>, destined for <your_local_subnet>. What you want is allowing connection state tracking, applying the rule to new connections and making Linux to accept those connections automatically. Next you’ll type:
sudo iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PAY ATTENTION AGAIN! Similarly to forwarding, iptables rules don’t work though restaring. A fast and an easy way is to save the rules with with iptables-save > <your_file_name> and iptables-restore <your_file_name>.
You are now telling Linus that you’re setting up a forwarding rule and that you want to trace connection state, apply the rule to the related connections including new rules that are related to other connections, and that you want it also to accept these rules and connections automatically. You can test this action by setting up Wireshark, tcpdump.
You should now see traffic arrive at the box on your subnet, unless your default gateway is the same as your VPN server. In this case, pinging will be as successful.
Adding Routes as Needed
Attention! This step is only needed if your VPN server is different from your local subnet’s default gateway. You can skip this part if both your VPN server and your local subnet’s default gateway are the same.
Unless your VPN server and your default gateway are the same, you have a routing issue. Why is that? You can think of it like this, data traffic arriving from your VPN clients will reach your local subnet. Then, your VPN will transfer them to a box on your VPN server’s subnet, however, the box will have no clue where to return the traffic. There are two ways to solve this problem, you can either add a static route on each box you want to connect with on your local subnet. Another method is to one route on your default gateway. However which way you choose, the route should point traffic sourced from your VPN subnet (default is 10.8.0.0) to the local subnet IP of your VPN server.
Troubleshooting Tips
You have reached the point where you can ping from your VPN client to your VPN server as well as any box on your VPN server’s subnet. Howeverm if you still can’t, I suggest you follow these procedures.
Firstly, make sure that your client is able to ping the outermost interface of your VPN server’s network. This would be the the external interface of the router if you are using port forwarding with a NAT/Firewall. If this fails to work, then you need to check a layer 3 connection problem between your box and your router.
Once you’re done with that, make sure that your port forwarding rule from your router to your VPN server is working. To do that, you can easily scan using nmap with the command nmap -sU -p 1194 <external_ip>. This should at least show as open|filtered. If it doesn’t, then you either have a port forwarding problem or the server isn’t responding. Check if your openvpn is running on the server and that your forwarding rule works.
Are you able to ping from your vpn client to the vpn server’s vpn interface? If you aren’t able to ping from your vpn client to the vpn server’s vpn interface, it is possible that you have a configuration problem on one of the sides. The most common problem is that your certificates aren’t working. Try enabling logging on the server by commenting out the logging lines in server.conf. The log will output to /etc/openvpn by default after you reboot the openvpn server.
On the other hand, if you can already ping the server’s vpn interface, but can’t ping a box on the local subnet of the vpn server, the problem could be lying with your iptables setup. Check iptables rules with iptables -L and make sure that they are working. Last but not least, make sure your routes are working on either your default gateway or your clients. Wireshark or tcpdump can be used to check the traffic arriving. In addition, the command “route” can be used on Linux or Windows to manually check the routes.
