To introduce you to the OPNsense project, I'll first need to tell a bit of my story and how I fell in love with it.

Project history

To tell the OPNsense story, we need to go back to 2003, when the initial release of m0n0wall was released. The main goal of this project was to have FreeBSD-based firewall software with an easy-to-use web interface (based on PHP) that worked on embedded PCs and old hardware with a good performance but that was just focused on Layer 3 and Layer 4 firewalling. m0n0wall was a good achievement. Still, picky network and security admins were claiming for other features such as web proxying, intrusion detection and prevention systems, and some other features that commercial firewalls were delivering as a default Unified Threat Management Solution (UTM). So, in 2004 a new project began, a m0n0wall fork, with its first public released in 2006. The fork's name? pfSense, and, as the name suggests, it used Packet Filter (PF) as a firewall-based system instead of the ipfilter (another FreeBSD packet filter)of its predecessor. For a long time, pfSense was a unique open source firewall solution, with a big active community and constant improvements. Many network and security administrators that only accepted Linux-based firewalls (yes, I was one of them too!) started to migrate to this FreeBSD-based firewall. These two projects coexisted until 2015, when m0n0wall was discontinued. There were signs of discontent back then; part of the pfSense community was not happy with some things such as changes in licenses and the direction the project was heading in.

Back in 2014, a brave group of developers decided to fork from pfSense and m0n0wall and started the OPNsense project. The first official release was in January 2015, inheriting a lot of code from its predecessors. Still, with a very ambitious plan to change how a lot of things were being done, OPNsense quickly rose as a pfSense alternative and received an important recommendation from the m0n0wall founder, Manuel Kasper, encouraging users from his project to migrate to OPNsense. It was the start of one of the best open source firewall projects.

A new project with a lot of improvements on old code

The following are some of the key features that OPNsense came with:

• OPNsense came with many new concepts and features that the community could claim credit for, such as a Model View Controller (MVC)-based web interface, a fixed release cycle, and a genuinely open source aspiration. The release cycle is done in two major versions each year, one in January and another in July (the community version) – for example, in 2021, the first version was 21.1 (January 2021), and the second one was 21.7 (July 2021), with a predictable and well-written roadmap. For the business edition, the releases are launched in April and October. The business editions are targeted at businesses and enterprises, containing the improvements delivered to the community version users first.
• As a Chief Technology Officer (CTO) with dozens of managed OPNsense-based firewalls, it is strategic to use firewall firmware with a predictable roadmap and release life cycle. This way, we can plan things with companies whose business depends on our managed firewalls.

Talking about versions, we need to introduce you to the flavor available:

• OpenSSL: The default one.

If you don't have any reason to choose LibreSSL, I'll advise you to pick the default one, OpenSSL. We will talk more about versions and installation media in the next chapter.

Talking about improvements, we must speak of the project architecture, starting with the frontend, the Phalcon PHP framework. This framework is used to implement webGUI and its APIs (another considerable improvement compared with its predecessors). It will do the work to render and control all that you can see and do using your web browser to manage your OPNsense.

The OPNsense framework also contains a backend, which is a Python-based service, also known as configd. This backend service will be in charge of controlling services, generating daemons and service config files from Jinja2 templates, and applying these configurations to an operating system.

With this architecture, OPNsense has a significant advantage – a secure way to manage and apply configurations to an operating system without executing root commands directly from the PHP web interface (as pfSense did, for example), reducing the risk of a flaw in webGUI compromising the whole firewall system.

So, now that we know how OPNsense evolved and its benefits, let's take a look at the operating system that serves as the base to this incredible firewall platform – FreeBSD's fork, HardenedBSD. It's essential to understand how the whole system and its components work to become a good OPNsense administrator. Let's go!

Before exploring OPNsense, let's look at its kernel: the almighty FreeBSD, the operating system that has the power to serve!

FreeBSD

First, FreeBSD isn't Linux! If you are a long-time FreeBSD user, don't be mad with me, as you probably have heard this statement before! If not and you thought that FreeBSD and Linux were the same, no problem! That is a common mistake people make. Let's first find out what FreeBSD is in a short introduction.

FreeBSD is a free and open source operating system. It is a Unix-like system but different from Linux; it is a complete operating system, including the kernel, drivers, and other user utilities and applications. Linux only includes the kernel and drivers, and everything else is built as the distribution or just distro. The FreeBSD project has an outstanding security reputation, and it has a dedicated team taking care of this at the code level. This has built a well-known reputation for a very secure operating system!

If you have never installed FreeBSD before, you must be thinking that you will use it for the first time on OPNsense, right? Not necessarily! You have probably used FreeBSD a lot already. Don't believe me? One of the strong points of the FreeBSD project is its licensing model, which is considered permissive. Add to that the system liability, robust security, and good hardware support and you have a lot of reasons to choose FreeBSD as your new product base operating system. Many companies have – Apple's macOS, iOS, and other OSes are based on FreeBSD code, Sony PlayStations 3 and 4 use it, and many network appliances make use of it too! If you have an iPhone, that also runs a FreeBSD-based operating system!

Now that we are introduced to OPNsense's operating system, let's explore why we should consider it for our network firewall.

To give a short answer – because it is the best genuinely open source firewall project currently available!

Not satisfied with this answer? Fair enough! Let's go to the long one!

My personal experience

Back in 2009, I was a pfSense user and enthusiast when I decided to move from Linux-based firewalls to FreeBSD. Back then, I created a managed firewall service for small and medium businesses using Linux firewall distros. At that time, I was using IPCop and SmoothWall Express, two Linux-based distros. I started this project with IPCop, but I decided to move to Smoothwall Express later, from which IPCop was forked. Both were good options to run in an embedded firewall appliance with limited resources. As a long-time Linux user, I was very comfortable using something based on this operating system. I am from a time when we built firewalls using ipchains and, later, iptables scripts, without any GUI help. I know – I'm getting old! Changes were happening and the service grew, with customers demanding bigger firewall appliances with high availability capability. At this point, Linux had a problem; there was no good support for this feature, so I needed to go back to the drawing board.

From research, I have found two possible alternatives – OpenBSD and FreeBSD. The first one was a well-known security-focused operating system with a strong reputation, which looked like a great option to run as a firewall solution. However, there were some hardware compatibility limitations and a lack of a GUI to manage it. It was a crucial need that customers were asking for. I couldn't find any firewall GUI option available back then, and developing a new one as a one-person development team was not a suitable option. It was time to look at the FreeBSD choices.

By doing a quick Google search, I found a good option – m0n0wall. So, I downloaded it and started the tests! It impressed me! It was a light operating system with a good WebGUI running on a solid operating system. But at the very beginning, I found a problem – reading the official documentation, specifically on the topic of what m0n0wall is not, I discovered that it wasn't a proxy server, an Intrusion Detection System (IDS), or an Intrusion Prevention System (IPS), and losing these features was not an option! So, it was back to square one!

Googling again, I found a m0n0wall fork – a project called pfSense. It looked like a promising one, with everything I needed to implement at that time – WebGUI, high availability, and some plugins such as Squid/SquidGuard for proxying and web filtering, Snort for IDS/IPS, pf as the packet filter. Bingo! I had found what I was looking for! My first impression when testing on the PC engine-based hardware was disappointing! The performance was too low compared with the Linux options and even with m0n0wall. There were too many features for a hardware platform with few resources. Another problem to solve was that even the more powerful hardware I was testing on used a compact flash disk as mass storage, and enabling a service such as Squid for proxying and web filtering with a lot of disk writing meant that the Compact Flash (CF) card got damaged very quickly. But there was another option – installing the NanoBSD flavor of pfSense made things easier for the embedded hardware to run more smoothly, and with some coding, I was able to bypass the CF card limitations. So, I ran this solution as a firewall to many customers until 2015. That was the year I became a little bit frustrated with how the project was being driven; a lot of ideas were popping into my head, but the project community was not the same anymore. It was time for a fresh start. I even talked with some project contributors about starting a new fork, but the idea was not accepted by most of them. It was time to go back to Google to look for a good open source firewall project.

On one of these rainy days, when your creativity is low and you have no intention to code or think of a new solution, I decided to google for some open source firewall alternatives, and the results surprised me! I found something, a project called OPNsense, and it was a pfSense fork! At that moment, the sun shined on my keyboard, and I thought, that's it!! The more I read about the project history, the more convinced I became that I had found the perfect solution backing!

So, I started the tests, and it was fascinating! It was pretty easy to convert pfSense's XML configuration file to OPNsense, so my first labs were based on production systems, and the results were very satisfying. It was time to migrate the first customers to this new firewall platform. However, it had a limitation – web filtering. We had developed a custom SquidGuard plugin for pfSense, but it wasn't easy to convert it, as the webGUI was different. Fortunately, our first customers didn't need this feature. The first migration to OPNsense was a success! So, it was decided that OPNsense was the new option for our firewall appliances! Later, I developed a SquidGuard-based plugin for OPNsense, and we were able to migrate all the customers. Since then, I have moved from this company to a new one, CloudFence, and we have decided to support the OPNsense project as much as possible.

Some of the key features that led me to dive into the OPNsense project were: genuine open source motivations with the freedom that an actual open-sourced project must have – an MVC-based webGUI without direct root access to the operating system (except for legacy components), IDS and IPS with netmap support, excellent available plugins, two-factor authentication for VPN, and cloud backups, to mention just a few! The list is increasing with each new version; later, we will see each feature in detail, so don't worry about it for now!

Okay, so this book isn't a novel, but I had to tell my personal history with OPNsense because choosing an open source project as a contributor and user isn't like buying a product. It is about personal life decisions; it's about what you want to support and are passionate about, and that project was right for me. I tried to help it! This is a little bit of my personal story with OPNsense; I hope it can inspire you somehow! The whole story might need an entire book, and it isn't the purpose of this one to tell stories but rather to improve your OPNsense skills, so let's move on to OPNsense's features!

Let's dive into OPNsense's core features and the most common scenarios to deploy it.

Core features

What are the core features? The OPNsense core features all come with the default OPNsense installation, without any additional plugins.

The core features are as follows:

• 802.1Q virtual LAN (VLAN) support: The IEEE's 802.1Q, also known as Dot1q, is a network standard for supporting VLANs. This allows us to set a lot of different networks, with logical divisions or broadcast domains, using a VLAN-capable network switch. This is very useful when we need to define different networks using a single physical network interface, with which we can separate packets from different networks sources, using VLAN tagging. We will explore this in more detail in Chapter 3, Configuring an OPNsense Network.
• Stateful inspection firewall: OpenBSD's PF firewall, or just pf, was ported to FreeBSD in version 5.3. This packet filter is very flexible and easy to use. As someone who comes from the Linux world, I must admit it's easier to understand than iptables. The OPNsense webGUI generates the pf rules that are used for packet filtering and Network Address Translation (NATs). If, like me, you're a curious person and have access to a running OPNsense firewall, you can sneak a peak at the /tmp/rules.debug file to see some of the pf rules. But be warned – don't touch anything there yet! In Chapter 5, Firewall, we will dive into the world of firewalls. If you are not running OPNsense yet, don't worry! In the next chapter, we'll install and configure it.
• Traffic shaper: OPNsense uses another firewall component, ipfw, the native packet filtering for FreeBSD, to classify and prioritize packets for the traffic shaping. With a traffic shaper, you'll be able to limit and reserve bandwidth and prioritize Quality of Service (QoS) traffic.
• DHCP server and relay: The Dynamic Host Configuration Protocol (DHCP), as the name suggests, is a protocol to lease IP addresses to hosts in a network. OPNsense has both server and relay capabilities; the most common one, the DHCP server, is used to set an address pool configured dynamically to hosts on the network. The second one is used when hosts can't access the DHCP server directly, such as if the DHCP server relies on another network segment.
• DNS forwarder: The Domain Name System (DNS) is the base of our modern internet; without it, we would need to know every website IP address to access it. The DNS server and forwarder do the job of resolving domains to IP addresses. OPNsense has more than one native service to do this job, Unbound and Dnsmasq; both are resolvers. To enable a DNS server, such as Bind, you will need to install the Bind plugin. We will talk about plugins in the next chapter. The default option in the core OPNsense installation is the Unbound service.
• Dynamic DNS (DDNS): OPNsense has a dynamic DNS client to update its hostname to an external DNS service. This is often used to access OPNsense externally while using a dynamic IP address; in this way, every time the ISP's IP address changes, the DDNS client will update the hostname in the external DNS service. Otherwise, you will only be able to access OPNsense by externally finding a way to discover which IP address your OPNsense machine is using at the moment.

  Important Note

  Dynamic DNS is a plugin installed by default on OPNsense.

• Intrusion Prevention System (IPS): Also known as an IDS, an IPS, or an IDPS, this is one of the most significant improvements in OPNsense compared to pfSense. The service used for pfSense is Suricata. Unlike Snort, which was used in the pfSense versions back in 2015 (when OPNsense was forked from it), it runs multithreaded. The OPNsense team implemented support for netmap, a network framework for high-speed packet processing. Moreover, the OPNsense project has Proofpoint support, which allows its users to use a high-quality ruleset. Instead of blocking a source or destination IP after matching a rule (as pfSense's IPS implementation used to work), OPNsense now just blocks the connection that corresponds with a rule, if in IPS mode; otherwise, it is in IDS mode, it will just alert. How does this improve IPS filtering? Suppose that one host in your LAN matches with an IPS rule, and it's a false positive if the system blocks the source IP. The host will stop communicating with the internet, and the user will be calling your boss, complaining about you and the firewall. However, if the IPS blocks the single connection that is matching with a rule, maybe the user will notice that a single application or website has stopped working, which has to be better, right?
• Forwarding caching proxy: This is also known as a web proxy. This service is native to OPNsense; it can be used to cache websites components like JavaScript, Cascading Style Sheets (CSS), images, fonts, and so on. You can also use it to control access to the internet using authentication, block websites with blocklists, make some basic access control lists, and intercept HTTPS/SSL traffic in transparent mode. In Chapter 13, Web Proxy, we will talk about it in detail and present some alternatives maintained by third-party developers such as CloudFence, such as installing and using those alternative plugins. What really matters is the possibility of doing high-quality web filtering using OPNsense, and it is indeed very much possible because of this open source beauty!
• Virtual Private Network (VPN): The VPN options available in the OPNsense core are IPSec and OpenVPN. Both can be used as site-to-site and client-to-site (also known as roadwarrior) setups to connect a user securely over the internet.

Captive portal: Talking about guest networks and controlling users to join a network, this also applies to the captive portal in OPNsense. This feature can be used with the web proxy to authorize users to use the internet and has widespread usage in hotels, airports, shopping centers, and so on.

• Built-in reporting and monitoring tools: These features can help a lot in troubleshooting scenarios. There are real-time and historical graphs, with a friendly user interface, packet capture (also known as tcpdump), and Netflow, and the list is increasing with each new version.

Here are some of the other great OPNsense features:

• QoS
• Two-Factor Authentication (2FA)
• OpenVPN
• IPSec
• High availability (CARP)
• A captive portal
• Proxy
• A web filter
• IDPS
• Netflow

There are many other features that can be added in OPNsense through plugins, and we will see in detail each core function and some plugins later in this book.

Note

You can obtain a full list of features at https://opnsense.org/about/features//.

Common deployments

OPNsense is very powerful and versatile and can be used in many ways. I'll try to cover the most common deployments, as follows:

• Network router: We can use OPNsense as a network router. It even has an option to completely turn off packet filtering, which improves the network throughput a lot, becoming just a network router without firewalling and NAT functions. Without additional plugins, the routing capabilities are minimal, straightforward, and serve well in a small network. Using OPNsense as a simple network router is the same as buying a Cirrus aircraft to fly in the same airdrome forever; you know that you can fly for hundreds of miles but prefer to stay just a mile away from the same runway. As a private pilot, I can't think of anything better than this comparison.
• Firewall with WAN failover: This is one of the most common deployments – OPNsense as a perimeter or an internal firewall. You can even use it as a cloud firewall, combined with some plugins such as the ZeroTier VPN, which we will explore in detail in Chapter 8, Virtual Private Networking. A firewall without additions will cover network Layer 3 and 4 packet filtering, and only that! In this scenario, it will probably be used to block untrusted packets from an external network. It can also be used to port forwarding (NAT and PAT) and block outgoing packets that aren't allowed to leave the LAN. When more than one WAN is available, it is possible to enable failover and outbound load balance to ensure good availability of internet access.
• I[DP]S: Whether combined or not with the firewall function, OPNsense can be used as a great network IDS or IPS, alerting and blocking (with the IPS turned on) packets from the monitored networks. The Suricata implementation in OPNsense is very well rounded, and with suitable hardware, you can achieve a few gigabits per second of throughput.
• Guest network wireless gateway (a guest network): With a captive portal enabled, you have a lot of control over a guest network. You can combine a firewall, WAN failover, an IPS, and a web proxy with the captive portal to build a robust solution.
• VPN server: OPNsense has excellent support for Certificate Authority (CAs) and certificates, users, and group management, locally and externally, and you can, for example, use it as a robust OpenVPN server solution for hundreds and maybe thousands of simultaneous users, using proper hardware. It will cover two-factor authentication and many features that can be enabled to work with a VPN, such as web filtering and DNS filtering.
• Web proxy and filtering: Using Squid as the web proxy server, OPNsense can act as a powerful web proxy and web filter. As a well-known and ubiquitous web proxy service, Squid allows you to do web proxying in transparent or explicit modes, HTTPS/SSL intercepting, web filtering with an external categories database, and so on.

There are other possible deployments, such as a web application firewall, a next-generation firewall, an advanced network router, a DNS filtering appliance, and Software Defined WAN (SD-WAN). It's not possible to cover all the possibilities in one book, but we will explore the most common ones in the following chapters.

Have you had trouble or don't know how to use a feature? Didn't understand what the official documentation says? Take it easy! We are a big and strong community, and someone in it will try to help you for sure!

Some facts

While selling OPNsense-based firewall solutions in comparison to commercial firewall closed-source solutions, customers commonly ask us a question such as, "Okay! It seems that this open source solution you are offering in your service can do anything that other closed source commercials listed in the 'some magic geometrical guide' (which I will not mention the name of here) solution can do, but what about support? When we need support or an urgent security fix, who are we going to call?" Our answer? "Not the Ghostbusters!"

Okay, just kidding – but let me tell you about some of the myths that the closed source firewall vendors teach customers about open source support and how to answer them!

• Open source has no professional support: So, let me tell my story – I've been paying my bills for almost the last 15 years by offering professional support! Deciso is the company that founded and maintained the OPNsense project, and it is a company, not just a couple of genius guys (although there are genius guys there too)! But they are doing an outstanding job as a company! They provide professional services, hardware, and so on. If we look at the open source world, we can see many companies providing support and, making money. Yes, you can make money with open source! Just search on Google for open source professional support, and you will see that it is not a rare service.
• Security fixes/software improvements: Some commercial vendors fail to perform quick security fixes – you can find some examples on Google; some took more than a year to fix a known vulnerability. However, if you repeat the search and use OPNsense as an example, you will see that security fixes are done quickly! Talking about the software improvements, let's suppose your customer asks you about custom features. Try to ask a big vendor to know if you even will be heard! Probably not! I know what I'm talking about, and I used to work with them a long time ago! With an excellent open source project such as the OPNsense project, you can ask (open an issue) or even write code and submit it on GitHub (a pull request). Most of the time, you will be heard, and sometimes after a lengthy discussion and code review, the community will probably accept it! Again, I know what I'm talking about!

So, after this introduction, let's see where else we can find help:

• OPNsense docs: The OPNsense documentation is incredible! You will probably find there a lot of answers to your questions already. So, before you start typing questions anywhere, read the docs!
• Official forum: Always search first in the forums for questions like the one you intend to ask. Maintaining a helping platform, such as a forum, demands a lot of work, so please respect that and avoid duplicating questions. I'm not against WhatsApp or Telegram groups, but they aren't the best medium to get help. Think about it – if you just arrived in one of those groups, you can't see the message history, so all of the effort done before answering questions like yours is lost. Some of my OPNsense course students often ask me about those groups, and I always say, "No! And I wouldn't!" and discourage them from using those groups as a trusted source of information. Please prefer using the official forum!
• IRC: There is an OPNsense channel on IRC Libera (https://web.libera.chat/#opnsense), and you can chat about it there!
• Commercial support: Suppose you are in a hurry or have some critical issue and can't wait for the community to answer. In that case, you can count on the commercial support provided by several reliable companies that support the OPNsense project. As we discussed in this section, there are many ways to get help with OPNsense, maybe more than some of its commercial competitors; this is the advantage of an open source project. You can always count on the community and the companies that support it and are not left with just one option!

This brings us to the end of the chapter, which has provided an overview of OPNsense.

In this chapter, you were introduced to OPNsense, its project history, versions, and the improvements made by pfSense and m0n0wall. I also shared a little bit of my history with you and why I decided to use it, with some examples. We learned about FreeBSD and what it is and is not, and about its hardened fork, HardenedBSD. We explored the OPNsense core features and typical deployments, with some examples of how you can deploy them in your network environment. Finally, we dived into support options and how to use each of them. Now that we know how OPNsense works, we can find help if needed, which versions are available, and the most common scenarios to deploy it. We will now move on to the following chapters, which will help you better understand some of the concepts discussed in this chapter more practically. In the next chapter, we will see how to install OPNsense and explore some of its features!