Sophos Wireguard

Posted on by



This article has been last updated on August 3, 2020.


There are countless Free an Open Source Linux/BSD distributions to choose from for your router. However, there are many outdated recommendations on the internet, so it's not an easy choice. For that reason, we have decided to create a definitive firewall comparison for 2020.

With SSL VPN in Sophos UTM, user will require any additional log-in in the client software and it does require a profile to be downloaded from the User portal for once or after any changes in the SSL VPN profile configuration. You may look into the possibility of using Sophos Connect Client VPN which uses IPSec. Applies to the following Sophos products and versions Sophos Firewall Registration of a Sophos XG device. Log in to MySophos Account. Click on Network Protection. Click on Register Device. Enter the Serial Number of the appliance and other information required. Then click on Verify.

Wikipedia has a list of router and firewall distributions, but the list is not useful, because it's inaccurate (as of August 2020) and it doesn't really compare these systems in any useful way. It also lists many outdated and irrelevant systems that should be avoided in 2020.

If you are looking to get the most of your hardware appliance, or are building a new firewall, we have done the research for you.

Why is our router distro comparison better than others?

For many years we have been selling hardware for building Open Source firewalls and routers. Over the last year, we have installed and configured most, if not all the distributions out there. We install and configure pfSense, OPNSense, OpenWRT, ClearOS, IPFire, and other OSes every day, so we have a good idea which Operating systems work better than others. We don't make any money from any software vendors, which make this recommendation relatively objective.
We hear customer feedback daily, if there are performance issues or problems with updates, we hear about it.

Top 10 Open Source Firewall Software to avoid - what you should NOT use.

Other comparisons out there are recommending Operating Systems that are long dead or no longer relevant. This is most likely because these 'Top 10 Open Source Linux Firewall Software' lists are copied from year to year by non-technical users, without doing the actual comparison.

Some Operating Systems have been superseded or simply stopped being maintained and became irrelevant. You want to avoid such systems because of security reasons - these distros use outdated and have insecure Linux/BSD kernels which can potentially expose you to security exploits.

1. IPCop - avoid at all cost

Once popular operating system, included in all 'top 10' lists such as this one. You should avoid using it. The last release was in 2015, and the system is ancient by today's standards. The official website is dead, but the source code is still out there. Don't use it.

2. Smoothwall - long dead

Smoothwall got some good reputation in the early days when it was competing with IPCop. It went silent in 2014. Smoothwall OS has been abandoned and is no longer relevant, or secure. You should avoid it. The website is still up and running, but hasn't been updated in many years.

3. DD-WRT - no longer competitive

This is a little controversial recommendation because I know that many users still feel that DD-WRT is good. It certainly was back in the day. Today DD-WRT is still functional and works, but it's not great or innovative. It's mostly unchanged since 2014 and fell far behind other open source competitors. Today there are many good alternatives, such as OpenWRT.

4. M0n0wall - retired

M0n0wall is the godfather of the most successful operating systems we have today. It's been one of the most innovative projects in its day, but it's now retired. System hasn't received any updates since early 2014 and is officially abandoned.
Manuel Kasper, the author of M0n0wall recommends OPNSense as its successor.

5. Tomato - not for new routers

Tomato is cool, and we love it, but it's a minimal firmware designed for flashing off-the-shelf routers such as D-Link and Asus. The system is still relevant if you want to resurrect your old hardware and make it functional again, but if you are building a new router you probably don't want to use tomato on it. We are building powerful routers from scratch, so we generally don't use this system (we still love it).

Wireguard

6. Zeroshell - poor choice

We like the concept of Zeroshell, and we hope it succeeds, but today the system is far behind it's competitors. The Web UI is very rudimentary, and the functionality is limited. We will keep an eye on it, and update this recommendation if things change. The website hasn't been updated since 2018, so at the moment this project doesn't look promising.

Not recommended because they are not user friendly

There are other systems that are relevant, and receive updates, but we still don't recommend them, at least to less technical users.

We don't recomment the below systems, because they require relatively high expertise to perform simple tasks. These days, SOHO routers (Small Office / Home Office) should be easy to setup and have Intuitive Web Interface to manage. For these reasons we don't recommend the following systems:

7. VyOS - no Web interface

We love VyOS, but we highly discourage our customers from getting it, unless they really know what they are doing. This system must be managed from command line, and it requires high level of expertise to maintain and use.

8. OpenBSD and FreeBSD - use only if you have 10+ years of the command line experience

Wireguard

OpenBSD and FreeBSD are actively developed and are very capable, but these systems require a high level of understanding of operating system internals, and low-level networking to be used as routers.

We routinely install both systems for customers that are experts, such as network administrators or software developers. If you don't want to mess with system internals and spend hours reading manuals, this is not a system for you. It does not provide any Web UI or GUI tools for configuration. It's a barebones terminal based system.

9. Debian and Ubuntu - don't use general purpose OS for your router

These systems are not intended for routers. They are general purpose operating systems, and should not really be used as routers. Similar to OpenBSD and VyOS, you will have to configure everything by hand without a Web Interface.

Nor recommended because they are not really free

There are also a few systems we don't recommend because they are not truly free or open source.

10. Untangle - is it really free if OS asks you to upgrade to a paid version?

Untangle NG Firewall is truly great software, with many happy users. We don't recommend it because the free version is very limited, and the operating system constantly incentivizes the users to upgrade to a paid subscription to unlock the cool functionality. The cheapest license is $50 USD/year.

11. Sophos - small fish in an enterprise pond

Sophos 'XG Firewall' distribution has a very nice user interface and is free for home use. We generally don't recommend it because it's not a system that Sophos itself promotes. Sophos' website seems to make it purposefully hard to find, and the community is very small. Sophos, in general, is an enterprise software company, with one community product. There's no Open Source spirit here.

12. Endian - you really have to pay to use it fully

Endian is actually pretty cool, and free. We don't recommend it because features like WiFi are available only in paid subscriptions. Similar to Untangle, it's good software, but you have to pay for it - this disqualifies it from our consideration.

To choose the best Operating System for routers we have set a few basic guidelines. All systems not compatible with these guidelines have been rejected.

Basic requirements for choosing Firewall Operating System

  1. The system must be actively maintained, and regularly receive security patches.
  2. The system must be fully Free and Open Source
  3. The system must have a Web interface or GUI. Command line operating systems are disqualified.
  4. The system must be performant, and work well for a typical user.

These basic requirements are reducing the list of recommendations to 4 systems. pfSense, OpenWRT, OPNSense and IPFire.

Creating a Site-to-Site WireGuard VPN for a home server

This guy is looking at pictures of my wife, probably. photo source

For the last decade or so, I’ve been steadily increasing the amount of data I send to the cloud. I sync photos of my friends and family to Amazon Photos, blast my private data off to Microsoft OneDrive, give my passwords to 1password, and trust my web hosting provider not to run away with my data.

I’ve been growing less satisfied with the privacy options afforded by major cloud providers. Amazon Photos, for example, has started using machine learning to identify the people in my photos. I’m not really keen on the mental image of Jeff Bezos, sitting on a yacht, looking at pictures of my wife.

For that reason, I’ve decided to start moving my personal data into my personal control. I want the bits and bytes that describe the intimate details of my life to live around under my own roof and only escape to the Internet with my permission.

I’d like to self-host NextCloud (to replace Amazon Photos and OneDrive), static site hosting (to replace my existing VPS and GitHub Pages), and continuous integration using GitLab CE (to replace Travis CI). It’s also a pipe dream to one day host my own email server, so I can move off of Google Apps.

To make all that possible, I’d need a way for Internet traffic to reach my home LAN, behind a router with a dynamic IP. I don’t want to use dynamic DNS, since I think it provides a poor user experience due to DNS caching. Also, my Internet service provider does not explicitly allow server hosting, so excess incoming Internet traffic might get me in trouble. 😅

The solution comes in the form of an Internet-facing server with a static IP. That server will receive requests and forward them to the LAN server through an encrypted, performant WireGuard tunnel:

Sophos

I chose WireGuard over other VPN candidates because of the simplicity of configuration and low server overhead. Without further ado, let’s get into how to set this up.

Step 1: Internet-Facing Server Setup

When choosing a server provider for your Internet-facing server, make sure to choose one with low latency to your home network, since that latency will be added to every request you make.

If the provider has test servers listed on their website, you can ping them from your home network to make an estimate of the round-trip-time that will be added to each request.

I chose RamNode for my hosting, since I get about 3ms of ping to their test IP in Atlanta:

Since WireGuard is really efficient, you don’t need a beefy, expensive server to run it on. I chose a server with 512MB of RAM, 1 CPU core, and 2 TB of outgoing bandwidth per month for $3/mo. This will be the only real expense of this project.

I installed CentOS on my Internet-facing server, but WireGuard is compatible with a wide variety of operating systems.

Once you have your server, SSH in and follow this guide to configuring WireGuard:

  1. Install WireGuard by following the instructions for your server OS.
  2. After installing WireGuard, you will have access to the wg command, which we will use to generate public/private keypairs for the server and client.
    • Run wg genkey to generate a private key. This will be the server’s private key. This should be kept a secret, as it can be used to decrypt data sent to the server.
    • Now, pipe that result into wg pubkey to generate the server’s public key. This will used later to configure the client to send encrypted messages to the server. For example: echo 'server-private-key' | wg pubkey
    • Repeat the above steps to generate a private & public key for the LAN client.
  3. Create a file using your favorite text editor in /etc/wireguard/wg0.conf, and fill it out using the below template. If you’re curious about the wg0.conf file format, check out the wg-quick man page for more information.

  1. Now that you’ve configured the server, you can bring up the WireGuard interface by doing wg-quick up wg0.

  2. Do wg show to see the status of your WireGuard network:

  3. Now use systemctl enable [email protected] to ensure that this interface is brought up on every boot.

Congrats! Your Internet-facing server is now set up to act as a WireGuard host. Now let’s proceed to the client configuration on the LAN server.

Step 2: LAN Server Setup

Follow these instructions on your home LAN server to set it up as a WireGuard client:

  1. Install WireGuard using the installation instructions for your OS.
  2. Create a file using your favorite text editor in /etc/wireguard/wg0.conf, and fill it out using the below template. Again, for more info on the wg0.conf file format, check out the wg-quick man page.

  1. Now that you’ve configured the client, you can bring up the WireGuard interface by doing wg-quick up wg0.

  2. Do wg show to see the status of your WireGuard network:

  3. At this point, you should be able to do ping 10.222.0.1 to reach your WireGuard server through your new VPN.

  4. Now use systemctl enable [email protected] to ensure that this interface is brought up on every boot.

Now your VPN is set up and you are ready to start exposing services on your home server through your VPN.

Step 3: Start Exposing Services

You’ll need a way to proxy traffic that hits your Internet-facing server through the VPN to your home server.

Sophos Wireguard
  • For HTTP traffic, set up a reverse proxy on the Internet-facing server. My tool of choice for this is nginx, which has a fantastic reverse proxy module. Here’s a very basic nginx config to proxy traffic for example.com to port 8080 on your LAN server:
  • For other TCP/IP traffic, set up rinetd on the Internet-facing server. It will tunnel TCP traffic on one port/interface to another port/interface. For example, if you have an IRC server running on port 6667 of your home server, you could put this in /etc/rinetd.conf to forward traffic from port 6667 of the Internet-facing server:

With both of these methods, keep in mind that the IP of the original client will be obscured by the reverse proxy. You’ll need to use other methods (such as an X-Proxied-For header containing the real client’s IP address) if you want to receive the client’s real IP at your home server.

Now you can start moving all of the services you want to self-host under your own roof! In future articles, I will discuss setting up your own self-hosted photo storage, continuous integration pipelines, web hosting, and others.

Extra: Securing Your Internet-Facing Server

One of the benefits to this setup is that you no longer need to expose your Internet-facing server’s SSH port publicly. You can use the VPN to access it instead.

  1. Set up your computer as a WireGuard client using the same method that you used to set up your home LAN server as a client. Or, just use your home LAN server as a bastion host, so you must be SSH’d into it to SSH into your Internet-facing server.
  2. Set up ufw on your Internet-facing server using these commands:

Now you should only be able to access SSH on your Internet-facing server via the VPN IP address, 10.222.0.1.

Extra: Alternative WireGuard Distributions

Sophos Wireguard

The official WireGuard distribution comes as a kernel mod. While the official implementation is best, there are also some alternatives that run in userspace, if you’re unwilling/unable to install a kernel mod:

Wireguard Project Security

  • wireguard-go - This is WireGuard’s official userspace implementation, written in Go. Recommended.
  • wireguard-rs - Another userspace implementation, also by the WireGuard authors, written in Rust. WIP, not recommended for production.
  • boringtun - Cloudflare’s unofficial userspace WireGuard client, also written in Rust. Used in their proprietary Argo Tunnel Site-to-Site VPN. Note: the original author of WireGuard, Jason A. Donenfield, has expressed some opinions about Cloudflare’s involvement in WireGuard.

Comments

Sophos Wireguard Mac

This blog uses Disqus for comments. To protect the privacy of visitors, comments are only loaded if you click the button below. Please enable JavaScript to view discussion.