OpenVPN on Ubiquiti EdgeRouter

A Virtual Private Network (VPN) allows a remote machine through an encrypted connection to connect to a local area network as if it was a local machine. It’s useful when traveling and you need access to a computer on a lan behind a firewall for whatever reason. Typically you’d use this to securely access your work network from the outside, but you can create the same functionality on your home network.  It’s also useful when away on a connection which is blocking ports, blocking websites, or monitoring your traffic. You can connect to your home VPN through a single encrypted port and use the internet as if you were in the privacy of your own home.

There are several protocols for making a VPN. Here is a good overview of PPTP, IPSEC and OpenVPN. I chose OpenVPN because it can run on any port, and seems to be the most recommended. I configured my server to run on port 443, the same port as HTTPS.  This makes fairly sure you can always access your home VPN from any other network as they most likely will not restrict HTTPS access. Warning though, OpenVPN is probably the most difficult to set up out of all the options.

EdgeRouter and OpenVPN

Here I talk about the EdgeRouter Lite

Steps for turning EdgeRouter into a DHCP Router 

Even though the EdgeRouter has the capability to run OpenVPN server, its completely absent from the web config. Most of it has to be done through the command line. It was also difficult to find good guides on how to set it up, there are many steps and concepts which can be confusing.  Searching for OpenVPN on Vyos or Vyatta helped to find additional resources.

OpenVPN Concepts

• There are servers and there are clients, we want our router to act as an OpenVPN server and any remote computers to have client access. Technically though clients can be servers and vice versa, but we won’t get into that.
• OpenVPN can run in several modes to authenticate clients and servers, making a confusing process even more difficult. Wikipedia has a concise summary of the available methods.  We will be configuring the Public Key Infrastructure based solution, which also happens to be the most complex option.
• We will be using OpenSSL encryption tools for public/private key and certificate generation. Public key encryption details are beyond this the scope of this article, but wikipedia has more information.
• The OpenVPN clients/server authenticate each other with certificates signed by the a trusted Certificate Authority (CA). We will be creating a CA to do this.
• There will be a lot of “certificates” and other such cryptographic files we will need in order for this to work. These are simply just text files with unique values which are generated by OpenSSL scripts in the router command line. Some of these files should be kept secure, others can be shared insecurely.

---

Getting Started

I looked for many tutorials, this is the one I followed, and this guide will reference it heavily. I recommend following it directly if you want a quick and dirty step by step guide. My goal here is to understand what is happening with each step, as I found myself wondering just what in the heck I was doing. There are also a few “gotchas” which I ran into and I try to mention in this guide.

Another good guide based on VyOS can be found here, it uses an alternative method to generate keys and also talks how to configure dynamic IP services.

 Create a Certificate Authority (CA)

Our router comes installed with OpenSSL which contains several useful scripts in times when we need to generate cryptographic files.

CA.sh -newca generates a folder called demoCA with a bunch of files and folders in it. According to OpenSSL, these are the files needed for minimal Certificate Authority application. A certificate authority is trusted party responsible for issuing signed certificates for clients and servers.  If a client and server trust the CA, then they can trust each other if they hold certificates signed by the CA.

We need to fill in a bunch of required data before generation is complete. You will see this screen several more times during this process. If you skip fields generation may fail. You may be prompted to create a password, if you skip it generation may fail. Just restart the process if it fails. If you see these files, then you succeeded:

Files in the demoCa folder, taken from openssl.org docs

We only really care about cakey.pem and cacert.pem for our purposes.

cakey.pem is the private key of the CA, it is important that this is kept secret. Anyone with this key would be able to issue new certificates to connect to your VPN.

cacert.pem is the public key, publicly accessible which clients and servers eventually add to their trusted certificate authorities.

Generating VPN Server Public/Private Key

CA.sh -newreq This script will prompt you again for generating a password, information about location, names, etc. Just fill it out. The passwords don’t really matter, but you will need to remember them.  Also the common name field should be unique.

There are 2 files which get generated:

newreq.pem is the unsigned public key of the server which needs to be signed by the CA.

newkey.pem is the private key of the server, this needs to be kept secret.

CA.sh -sign  The servers public key gets signed by the CA making a public certificate. Now clients know that they can trust the server bearing this certificate. You may be prompted for a password during this command, use the one you created when making the CA.

The certificate is a new file: newcert.pem

Securing Server Keys and Certificates

There are 4 files we have generated so far which we need to save permanently:

demoCA/cacert.pem The public key of the CA, made during the CA creation process

demoCA/private/cakey.pem The private key of the CA, used to sign new certificates for users of the VPN.

newcert.pem The signed public key of the OpenVPN Server.

newkey.pem The private key of the server, used to encrypt communication.

All these files get moved to the /config/auth/ folder of the router, an area on the filesystem not affected by firmware upgrades.

Diffie-Helman Key Exchange

We are generating another file here, and it takes a long time to do, like maybe 10 minutes on the router. Its essentially searching for a really long prime number. Using this number and some fancy math, it allows client and server to generate unique session keys without ever transmitting the key at all.  This identical secret key is used to encrypt all further communications between client and server. This key is something only client and server can deduce, even if a third party has intercepted all communication.  A really good explanation on stackexchange.

Generating Client Keys

This is the same as generating the server keys, but you will do this for each client you want to have access to your VPN.  Remember to save the password, and use a unique common name.  We then need to move these files to the client computer, theoretically through a secure connection, as we don’t want the key file to end up in the wrong hands. Notice we are also copying the client private and public certified key as well as the cacert.pem file, which is our CA’s public key.

Summary of Generated Files

Taken from OpenVPN Docs

Nice summary provided by the OpenVPN docs to remind you which files are private, and which are public and where they need to be. The filenames don’t match exactly but hopefully you can figure it out.

We need to do one more thing, remove passwords from our server private key file. Remember when we generated keys and were asked for passwords? Well OpenVPN will complain if our server key is encrypted with a password because you aren’t able to provide it in non interactive mode. You can also remove passwords from client private key as well if you want.

openssl rsa -in /config/auth/host.key -out /config/auth/host-nopass.key

This concludes the OpenSSL portion of the walkthrough. OpenVPN and Edgerouter configuration is next.

---

Configuring OpenVPN Server on EdgeRouter

Things to consider:

• One step they neglected to mention, type “configure” before any of the above to enter the configuration program. This was not obvious to me.
• We want tls key-file to point to the /config/auth/host-nopass.key instead of the host.key, otherwise OpenVPN will throw an error on startup.
• We also need to set the port using: set local-port 443 
• The server subnet needs to point to a different subnet than your DHCP server, for example, my DCHP subnet is 192.168.0.0/24 and my VPN subnet is 192.168.1.0/24. I don’t know why this is, but OpenVPN will fail to start if they are the same.

This is the command line equivalent of this in the web gui “Config Tree” tab:

Next we want to make the rest of our lan accessible to VPN clients

Things to consider:

• We push routes to our LAN and WLAN interface addresses, in my case I have a bridge interface with the ip 192.168.0.2 which handles both LAN and WLAN
• We can assign static IPs to our clients on VPN by using the Common Name we entered when generating our client keys. Remember to put these static ips on the VPN subnet.  I don’t think this step is strictly necessary, you can skip if you don’t care about static IPs.

Things to consider:

• I wanted my OpenVPN server to run on port 443, the same as HTTPS. This lowers the chance an outside network will block access. Change the port from 1194 to 443, or the port you configured for the server.
• You may also need to set this (after top command) for internet to work:

set service dns forwarding listen-on vtun0

That’s basically it for the server configuration

These commands tell the “configure” program to save and apply the changes to the system.  OpenVPN should be up and running and ready to connect to from clients.

---

Setting Up Static External IP for your Server (Dynamic DNS)

I failed to mention that your network needs to have a static IP and/or domain address so that you know how to find it from the outside world. You can probably purchase a static IP one from your ISP, or use a dynamic dns service to map a domain to your dynamic IP. I ended up using DuckDNS, which is free dynamic dns service.  You will use your IP or domain name for your client configuration.  Check this tutorial in the last section to see how to use DDNS with the EdgeRouter.

---

Testing a Client Connection

The easiest way to test your VPN server is from another Linux computer, by following these steps.

Step 4 is the real meat and potatoes of the client setup. This is what you need in the client.conf, which openvpn will use to connect to your server. You will have to adjust some things here:

• remote vpn.dlasley.net 1194 If its not obvious, replace this with your server’s external ip/domain and port. In my case the port was changed to 443.
• ca, cert, key These are the 3 files you needed to copy to the client, adjust directory and names accordingly.

If you followed these directions you should be ready to test your VPN. The tricky part now is testing from an external network. OpenVPN did not work unless I was running the client from an outside network. I tethered my laptop to my phone to test things.

Once on an outside network, connect to your VPN:

sudo openvpn client.conf

Try ifconfig, and look for the tun0 interface. If there is a local IP address assigned to it then that is a good sign. Try pinging a machine on your lan, you should get a response. Test that the internet works by visiting a website. If all that works you should be good to go. Hope this helps, and if I’ve missed anything please let me know. 

Configuring an Ubiquity EdgeRouter as a plain old DHCP Router

I recently got an EdgeRouter, I talk about it here

What you need to understand with the EdgeRouter and VyOs in general is that you will need to configure every aspect of the routing process. Your consumer grade router is doing a lot of things in the background you don’t realize when you plug it into your cable modem and everything just works. This makes them easy to use.  The Edgerouter is a bit of a paradigm shift.  You have control (even if you don’t want it) over every sub-process in the routing configuration, this gives you power, but also makes it difficult for the average user. Here are some high level concepts to understand:

• Install the latest firmware. This adds a more powerful web config interface.
• Each port on the router ( excluding console) is essentially its own isolated network card, this means they are not configured to talk to each other unless you explicitly set this up. It also means each port can basically act as their own independent router.
• There are 3 ports for a reason. The typical setup is that port 1 should be configured for your cable modem, port 2 should be configured as a DHCP server for your wired network (LAN) and port 3 should be configured for your wireless access point (WLAN). You can create a bridge between ports 2 and 3 so that they essentially act as one network.
• The VyOS is a flavor of Debian Linux. Everything you can do in the web config can be accomplished through the console or SSH into from a remote terminal by the “configure” command.
• The big feature of VyOS is that all network related configuration has been organized for you, which you can find in the “Config Tree” tab on the web client. All changes to your router configuration are reflected here.
• Ubiquity’s web interface gives you a configuration wizard and the ability to save as well as restore configurations. Many people have shared common configurations, like a basic dhcp router, you can use these things to get you up and running quicker.

So what is so complicated about routing internet to devices on the local network? Here is what I learned thanks to EdgeRouter:

• We need to configure a port, in my case eth0 to talk to your modem. It needs to obtain an external IP address to get on the internet. This is usually called the WAN (wide area network) port.
• Need the other ports, in my case eth1 and eth2 to use a DHCP server. This means they will hand out dynamic and static ip addresses to devices connected to them.
• Also would like eth1 and eth2 to allow all devices to communicate with each other on the local network regardless of which port they connect to.
• Most importantly need eth1 and eth2 to serve internet from eth0 to all devices on the network.
• While we are at it, should set up firewall rules and port forwarding if need be.
• Put my other wireless router into AP mode and connect it to the EdgeRouter.

---

First Steps and Quick Links

You need to connect to the router on eth1 or eth2 and get to the web interface, from here we can start configuration. Use the official documentation to get you to the web config page:

Quick Start Guide

Official DHCP Walkthrough (Slightly different from this one, configures each port rather than bridging)

The Latest firmware

Forum posts with premade configs

Configuring ETH0 as a WAN Port

In the web interface dashboard shows us the physical ports. Configure eth0 like so:

This should allow ETH0 to be assigned an IP address from your modem. I had to cycle power on cable modem and router before it picked up an IP.

Creating a Bridge between ETH1 and ETH2

This is not strictly necessary, but a bridge between these 2 ports will allow them to act identically without a separate configuration and DHCP server for each. When your bridge is made, your ETH1 and ETH2 ports will not need to be assigned an IP individually, the bridge will act like a virtual port and we will configure that instead.

In the version of the web config I used we have to add a bridge through the “config tree” tab. Add a bridge, I called it br0, then at the bottom hit preview and commit.

We can now go back to the dashboard and see a new interface called br0. Mine has an ip address assigned, but it won’t when you first add it.

Hit actions -> config to bring up this menu:

In the Basic tab, define a local IP address. This will be the new address where we will eventually access the router web page on the local network.

In the Bridge Interface tab, bridge eth1 and eth2:

Starting a DHCP Server

Right now our computer needs a static IP assigned to access the web config page. We want a DHCP server to handle assigning dynamic and static addresses. We start in the “Services” tab and add a DHCP Server.

Let me explain some of these fields

• DHCP Name – arbitrary name we want this server, for administrative purposes
• Subnet – The scope of IP address which this server is responsible for watching
• Range Start – The lowest IP address that will be dynamically assigned to a device on the network
• Range Stop – The highest address which will be dynamically assigned
• Router – The IP address of interface that the server acts on, in this case it is our bridge interface.

If all went well, we should have a DHCP server and bridging running, and any devices plugged into a ETH1 or ETH2 should get assigned a dynamic IP. Internet still does not work, but that is next.

Getting Internet Working (NAT, DHCP, Forwarding)

This step will enable internet from ETH0 to devices on ETH1 and ETH2. In the “Firewall/NAT” tab, we need to enable NAT masquerading for ETH0.

This magically allows internet to pass through ETH0 to all other interfaces on your router.

I also have some port forward rules which can be found in the Firewall/NAT Port Forward subtab:

We also add a DNS rule.  In the “Services”  “DNS” subtab:

Finally

At this point you have the functionality of a regular DHCP router.  You can see, its a bit complicated to do and you still probably want to configure the firewall. Here is a good resource for that. Connect your access point to eth1 or eth2 and connect your devices. Also try a speed test.

Thoughts on Ubiquity EdgeRouter

Recently purchased an Ubiquity EdgeRouter Lite, a fast wired router which runs Linux. It was a bit of an impulse buy, but a friend of mine convinced me it would be worth it, and it is pretty cheap. The router runs a proprietary version of Debian Linux maintained by Ubiquity called EdgeOS. It has a close open source cousin called VyOS.

My old router, an Asus RT-N66 was no slouch, but I wasn’t able to get full download speeds at home. I thought it was my service, but it was actually my router not able to handle those speeds. I pay for 150mb down, but was only able to get about 100mb with the Asus, with the EdgeRouter I get full 150mb down on my wired computers. The cost of the EdgeRouter Lite? Only 90$.

Before Speed using Asus Router

After Speed using EdgeRouter lite

The EdgeRouter’s drawback is that it requires IT level skills to configure. Even though they provide a web interface, it requires a lot of googling to figure out how just set up a dhcp router, something you can do with a few clicks on the Asus. I consider myself pretty tech saavy, but it took me several hours to figure that out, and several days more to get an OpenVPN server running. Overall its nice to have such a powerful and fast router on the network, it works very well despite the steep learning curve.