Software Choices

There are several popular open-source products that work very well with commercial-grade networking equipment. Each has its own use cases and counterindications.

The first question you need to answer when choosing your router software is, what is your device's architecture? In simpler terms, what kind of processor does it have? We are all familiar with the PC architecture, first developed by IBM around 1980. Its current incarnation is often called x64 or amd64. A lot of larger server-like network appliances are x64 devices. Smaller appliances, however, can have a different architecture, such as ARM or PowerPC. There are quite a few of those. For example, the Check Point L-50W you've met on our home page is a Kirkwood device built around a Marvell Feroceon 88FR131 processor.

The second question is, what about wireless? Does your device have wireless networking capacity and, if so, what kind? Today, the cutting-edge wireless standard is 802.11ax (often called simply AX), but previous standards, such as 802.11ac (aka AC) and 802.11n (aka N) are still in wide use.

With this in mind, let's take a look at four popular open-source operating systems for networking equipment, listed here in alphabetical order.

1. DD-WRT

DD-WRT was originally developed for small resource-constrained networking devices. The first version came out all the way back in 2005. DD-WRT is available for a bedazzling variety of architectures and has very modest system requirements. The current version of DD-WRT, generally speaking, requires 64 MB of memory and 64 MB of storage to run (on some architectures, it can be even less). DD-WRT is based on Linux.

One slight disadvantage of using DD-WRT on x64 hardware is that it requires activation. This is not a problem for an end user installing DD-WRT on their own equipment, but can be inconvenient when transferring the equipment to another person.

2. OpenWrt

OpenWrt is conceptually similar to DD-WRT, except it has been around even longer, since 2004. It is also based on Linux and available for a wide variety of architectures, including x86. Unlike DD-WRT, however, it doesn't require activation on x86 equipment. For that reason, we have a slight preference for OpenWrt over DD-WRT.

3. OPNsense

OPNsense has been around since 2015. It is a fork of pfSense (described below). OPNsense is available only for x86 architecture. Because it is based on FreeBSD, support for wireless networking in OPNsense can be lagging (currently, FreeBSD does not support AC networking). For wired-only devices, however, OPNsense is a solid choice. Compared to pfSense, it has better compatibility with hardware, but since it is a newer product and the developer is located in The Netherlands, OPNsense has somewhat weaker name recognition in North America. However, OPNsense has one feature that pfSense chose not to implement, a "nano" install. It is very useful in situations when the router has to boot off a CF card, SD card, or similar media. It is not recommended for advanced networking, but for basic routing and firewalling it works very well.

4. pfSense

pfSense has been around since 2006. It is based on an open-source product called m0n0wall (an implementation of FreeBSD for networking equipment), which has since been discontinued. Because it is based on FreeBSD, the level of support for wireless networking in pfSense is the same as in OPNsense (AC networking is not supported). pfSense is well suited to industrial-grade x86 equipment. There is a version of it for ARM, but it is available only on devices sold by Netgate, the company that develops pfSense. pfSense is well known in the network engineering community and has been deployed in systems serving up to tens of thousands of concurrent users. There are two small drawbacks compared to OPNsense. One is hardware compatibility. In rare cases, pfSense would refuse to install on a piece of equipment with which OPNsense wouldn't have a problem (we experienced it firsthand on Zotac Zbox mini PCs). The other is distribution policy: Netgate prohibits commercial redistribution of pfSense. Whether and how this is enforceable is an open question, but this is what you technically agree to when you install pfSense.

So How Do We Choose?

For wired-only x64 hardware, especially if it is rack-mountable, it makes every bit of sense to choose pfSense or OPNsense. Larger organizations can also consider commercial versions of these products that come with support or purchase pre-configured hardware from the developers of pfSense or OPNsense.

At the same time, pfSense and OPNsense can have issues with some older hardware. For starters, they are no longer available for 32-bit processors. They can also be picky when it comes to BIOS. For example, they really don't like certain Sophos models that combine x64 processor with IA32 BIOS, so much so that they simply freeze in the beginning of the install process (there's a fix for it though).

OpenWrt, meanwhile, has no problem with any of it. It is available for 32-bit processors (we installed OpenWrt on Check Point U-5 running an early Intel Celeron), the 64-bit version negotiates with IA32 BIOS just fine, many AC and AX wireless cards are fully supported, not to mention the availability for multiple non-Intel platforms. However, as we noted above, OpenWrt has been developed for resource-constrained situations. It is first and foremost a miniature system. As a result, is lacks certain refinements. For example, let's say you install a new feature. This feature relies on a certain library, which will also be installed. The version of this library will be that required by the new feature. When installing the new feature, OpenWrt will overwrite any earlier version of the library if it is present. In rare cases, this can create a problem for previously installed features that require an earlier version of the same library. Long story short, advanced features should be used cautiously and tested thoroughly.

A Note on the Worst Cases

Not every piece of networking equipment can work with open-source software. Some companies choose to manufacture their devices with custom-designed chips that work very well with their proprietary software but cannot work with open-source software at all. One company that consistently does this is Fortinet. As a result, there is no open-source system that would work on Fortinet equipment.

Some companies have different product lines built on different architectures. Sophos, for example, has SG and XG lines, which are based on x64 and work very well with open-source software (so do their UTM devices, but they are no longer manufactured). Their RED line, however, is based on Freescale processors, which currently have limited open-source support.

Conclusion

Open-source networking is a wide field. There are options, but they are not applicable to all cases equally. Open-source deployments tend to work best in situations when budgets are limited and needs are relatively simple.