Making your office VPN situation faster and easier to use

We recently started using a new VPN solution at OPLF.  It is faster than our previous VPN solution and has lower latency.  It has no recurring cost and the one-time cost to get it working was under $100.  In this article I will describe this new VPN solution in detail.  I will also explain how you could set this up yourself in your own office. 

By way of background, when the Covid lockdown happened, OPLF faced the same situation everybody faced, which was that we needed to make sure everbody could work from home.  This required VOIP phones that would seamlessly work as if they were in the office, and it required VPN connections so that our people could reach the many data servers in our office.

Over the past twenty years or so, we have used half a dozen different VPN solutions.  I feel very sorry for our long-suffering office colleagues who have had to install and configure one VPN solution after another, each of which had its own foibles and drawbacks.

Each time that we picked and tested yet another VPN solution, we tried to satisfy several goals:

• • No recurring cost.  What we did not want was any solution that involved paying monthly fees to some VPN service provider.
  • High level of cryptographic security.  We did not want to be using a security approach that was easy for a determined adversary to crack.
  • Non-proprietary.  We did not want a proprietary VPN solution.  With any proprietary solution, we faced the worry that the service provider might have included some “back door” in it.  A big advantage of an open-source solution is that interested persons can review the code to see if anybody had put a back door into it.  A second advantage of an open-source solution is that interested persons can see exactly which encryption algorithms are being used.  This relates to the previous point about wanting a high level of cryptographic security.  If the VPN solution is proprietary, then it is impossible to know whether the service provider chose wisely when it picked the encryption algorithm to be used.
  • Works through NATs.    Most of the time these days, a user will be “behind a NAT”.  NAT is “network address translation” and it is the way that a home or hotel or other public place will hand out non-routable IP addresses to users.   The NAT server typically receives one routable IP address from an internet service provider, and will then hand out as many as 253 individual IP addresses to users.  There are many implementations of NAT and some implementations are less friendly to VPNs than other.

A long time ago we used PPTP (point-to-point tunneling protocol) . This VPN often simply failed to connect at all depending on what kind of NAT was being used at the user’s location.  It also often failed to connect depending on the firewall settings at the user’s location.  Still another problem was that in the cryptographic community, it became apparent that there were cryptographic weaknesses in PPTP.  A determined adversary might be able to “crack” PPTP.   Here is what it says in a Wikipedia article:

The Point-to-Point Tunneling Protocol (PPTP) is an obsolete method for implementing virtual private networks.  PPTP has many well known security issues.

For a while we tried to use IPSEC.  This was very fragile in many user network configurations.  For a reliable IPSEC connection we needed to have a routable IP address at both ends of each connection.  This is nearly always impossible to achieve when the user is in a hotel or some other public place.  It is quite a lot of fuss and bother to try to get IPSEC to work “behind a NAT”.

We then migrated to OpenVPN.  This protocol is able to work “behind a NAT”.  When Covid struck, this was our day-to-day solution for our VPN needs.

But OpenVPN has a big drawback for us.   The VPN servers that we were using at the time of the Covid lockdown had a hardware limitation of five VPN connections at a given moment, for each server.  We found ourselves having to set up two or more VPN servers running in parallel to be able to accommodate the desired number of simultaneous connections.

Which brings us to Wireguard (Wikipedia article).  Wireguard has only been in production service for a little over two years.  But it is open-source and if there were weaknesses in it, I think they would have been uncovered by now.

One potential advantage of Wireguard is the size of the code base.  The code to make IPSEC or OpenVPN possible is 400,000 or more lines of code.  In contrast, Wireguard’s code base is only about 3800 lines of code. This means that an interested member of the public wishing to check for weaknesses or backdoors only has to review 3800 lines of code instead of 400,000 lines of code.

The “attack surface” available to those trying to penetrate the security is much smaller for Wireguard.

The actual instructions that are repeatedly executed to carry out the actual encryption and decryption are very few for Wireguard, as compared with a much higher instruction count for other approaches like OpenVPN or IPSEC.   The practical consequence is that the throughput of the VPN connection is often quite a bit faster for Wireguard.

Actual speeds and latency.  Actual speed tests and file upload-download tests by our colleagues at OPLF have found speed enhancements consistently at least ten or twenty percent faster, and in some cases the connection is as much as 2½ times faster.    Latency (for example ping times to a server) is consistently better with Wireguard compared with OpenVPN.  A ping time might be 60 ms rather than 80 ms, for example.

Implementing Wireguard.  A big enabler for us was the recent release of a high-bandwidth router that is optimized for VPN server functions.  This new router is called the Brume 2 or the GL-MT2500 router, shown at top right (manufacturer’s page).  An important thing about this router is that it is running an open-source version of Linux.  So you do not need to wonder whether the manufacturer might have included a back door or some intentional weakness in the cryptographic algorithms being used.  This router only costs $60, and that includes air courier shipment from the manufacturer to you.

The CPU in this router is a MediaTek MT7981B dual-core processor, running at 1.3GHz clock speed.  The ethernet ports on this router are gigabit or faster.

Here is how we implemented Wireguard in our main server farm in our office.

1. 1. Set up the Brume router to use DHCP on its WAN port.  Connect it to the LAN of the server farm.  Go look in the DHCP server to find out the WAN MAC address of the Brume router.  (Yes it is written on the bottom of the Brume router but then I would have to hand-key the MAC address in later steps.  At the DHCP server I can copy and paste the MAC address of the Brume router.)
   2. In the DHCP server, set up a static mapping from MAC address to LAN IP address.  Make a note of the mapped IP address.
   3. In the main router for the server farm (the router that is exposed to the Internet at its WAN port), set up a service called Wireguard which is defined as UDP port 51820.
   4. In that router, set up port forwarding for the Wireguard service to the mapped IP address of the Brume router.
   5. In the Brume router, go into the “applications” tab and turn on the native DDNS.  You will be assigned a DDNS domain name along the lines of “xza79dd.glddns.com”.    Optionally, also turn on “HTTPS remote access”.   This is not as risky as it seems given that nobody is going to be able to reach that HTTPS remote access unless they are already logged in with a VPN or are otherwise already trusted enough to be on the LAN of the server farm.
   6. In the Brume router, go into “System” and “Upgrade” and turn on automatic firmware updates.  Also, do as many manual firmware updates as needed to get up to date.  (At press time the version was 4.1.1, compiled in November of 2022.)
   7. In the Brume router, go into “VPN” and “Wireguard server” and “Configuration”.  Click to activate the Wireguard server, and click to turn it on.  Find “Wireguard server options” and turn on “Allow Remote Access LAN”.
   8. Within the Wireguard server tab, click on “Profiles”.  Click “+ Add” to add a profile.  A popup window will permit you to configure and download a configuration file.  Select “use DDNS domain”.  Click “download” to download the Wireguard client configuration file.
   9. If your remote device (such as a notebook computer) does not already have a Wireguard VPN client installed or built-in, then you will now need to download and install a Wireguard VPN client.  You can get it at https://www.wireguard.com/install/.
   10. In the Wireguard VPN client, click on “Add Tunnel”.  Select the Wireguard client configuration file that you downloaded two steps above.
   11. Now connect your remote device to the Internet in some way that is not the same as your office LAN.  Maybe use a hot spot on your mobile phone, or a LAN at home or in some public place.
   12. Test the new tunnel by clicking on “Activate” in the Wireguard VPN client.  You should next see two green checkmarks letting you know the Wireguard tunnel has been established.  Test it by trying to make use of server resources in your server farm.
   13. For extra credit, do some uploads and downloads of big data files and time the uploads and downloads.  Compare the upload and download times using Wireguard with the upload and download times using your legacy VPN solution.  Maybe it will be a lot faster.
   14. Repeat steps 8-12 above for each of your remote users.

Please post a comment below to let me know how this works for you.