OPNSENSE

More than a firewall

Table of contents
1. OPNsense – more than a firewall 3|

2. Introduction to OPNsense 3|

Secure platform 4|
Versions and release cycle
OPNsense Business Edition 5|

3. Structure 5|

4. Interface 5|

5. Packet filter and firewall 6|

Order of rules 7|
Setting up basic firewall protection 8|

6. Intrusion Detection/Intrusion Prevention 10|

Setting up IDS/IPS 11|

7. Virtual Private Networking (VPN) with WireGuard 13|

Setting up WireGuard VPN

8. Hardware for OPNsense 17|

Low Energy Systems 18|

Rack servers for greater flexibility
Performance estimates 19|

9. Conclusion and outlook 19|

Web proxy for access control

High availability 20|
Plugins for special scenarios
 thomas-krenn.com | 3

OPNsense – More than a firewall

OPNsense is a platform that covers nearly all
aspects of perimeter security in the broadest sense
– from the IP layer to the application layer. Though
perhaps best known for its firewall capabilities, the
software is capable of much more. The functional
scope of OPNsense ranges from intrusion prevention
systems to VPN, web proxy, traffic shaping and virus
scanner applications to comprehensive monitoring
solutions. With its ability to easily connect to
existing infrastructure and the combination of open
source components under the OPNsense umbrella,
the platform covers various use cases that most
closed source products cannot match.
However, this flexibility also makes it challenging
to find the "right" entry points into the system.
Inexperienced administrators may invest a lot of
effort for little gain in security. This e-book aims
to help the reader avoid such outcomes. Here,
we describe a basic security setup for a small
network – limited to a firewall, intrusion detection
and VPN – as a basic example. This scenario was
chosen as most smaller companies have similar
network constellations and requirements. The book
also covers the functionality of the components
discussed – ensuring that both the "how" and the
"why" are adequately understood.
This e-book was developed in cooperation with
Thomas Krenn's Munich-based partner m.a.x.
Informationstechnologie AG (m.a.x. it), a service
provider with more than 30 years of experience in
the security, infrastructure and solutions business.
m.a.x. it actively contributes to the further
development of OPNsense, advises companies on its
use and develops customer-specific extensions for
the platform. You can find additional information,
how-to articles or webinar recordings in video form
at the m.a.x. it and Thomas-Krenn websites. This
book assumes that OPNsense is already installed
and the network interfaces are set up. Installation
instructions can be found readily on the internet,
including at the Thomas-Krenn wiki1 or in the
extensive official OPNsense documentation2.

Introduction to OPNsense
The software has its origin in 2015 and is a fork of the
well-known open source firewall software pfSense,
which started in 2004 as a project fork of m0n0wall.
The basic idea of all these projects was to combine
the functionalities and management of firewall
rules under one graphical interface. However,
there are important technical differences, which
are explained in the technology blog produced by
m.a.x. Informationstechnologie AG3. The name
"OPNsense" is derived from the combination of
"pfSense" and "open source". The founders of
OPNsense cite five central arguments for the fork:4

1
Installation (Thomas-Krenn-Wiki): https://www.thomas-krenn.com/en/wiki/Install_OPNsense
2
Installation (OPNsense Manual): https://docs.opnsense.org/manual/install.html
3
Unterschiede zwischen pfSense und OPNsense: https://techcorner.max-it.de/wiki/OPNsense_vs._pfSense_-_Im_Vergleich
4
Begründung für den OPNsense-Fork: https://docs.opnsense.org/history/thefork.html
 thomas-krenn.com | 4

• Technology – High code quality and well-structured development methods as

well as achievable goals in a roadmap with regular releases
• Security – No tasks executed in the GUI require root access and potential
security risks are dealt with at an early stage
• Quality – All new functions are created using a solid framework (Phalcon) with
a Model–View–Controller approach
• Community – A productive community of developers and users with barrier-
free access to codes and systems
• Transparency – Possible changes are communicated transparently and
OPNsense is based on the proven, open source 2-clause BSD license

The OPNsense project is financially and technically
supported by the Dutch company Deciso B.V., which
was already active as a sponsor and co-developer
for the two OPNsense predecessors, pfSense and
m0n0wall. The "original project" m0n0wall has
been discontinued in the meantime. The founder
of the latter has spoken out in favor of switching
to OPNsense. Though pfSense continues to exist
in parallel, its significantly more restrictive license
and lack of open plugin interface (along with
various controversial business decisions made by its
founder) have seen it fall behind the competition.
OPNsense is now the more comprehensive and
technically advanced solution.

Secure platform
Security software is supposed to protect the
infrastructure and the privacy of users, but such
software is increasingly becoming a gateway for
attackers – sometimes with severe consequences.
Therefore, it is vital that both the software itself
and its development process are as secure and
transparent as possible. This is generally the case
with long-standing and successful open source
projects.
OPNsense is based on the HardenedBSD operating
system, a derivative of the Unix operating
system FreeBSD, which a very active community
has developed for decades. FreeBSD is already
considered a very secure operating system, while
HardenedBSD introduces numerous additional
features at the kernel level that make it even
more difficult for an attacker to gain control of the
operating system through loopholes in application
programs. HardenedBSD is not a true fork of
FreeBSD, as all current FreeBSD developments are
also incorporated into HardenedBSD in a timely
manner.

Versions and release cycle

New major releases of OPNsense appear in a
regular cycle every six months. Between these
dates, minor updates can be expected about
every two weeks. These minor updates not only
eliminate security gaps but often also include new
functionalities. OPNsense follows the pattern set
by other open source projects like Ubuntu with this
release practice. It even adopted the same naming
conventions for its versions, using the adjective plus
animal scheme with each having the same initial
letter. Thus, the July 2020 version bears the number
20.7 and the name "Legendary Lion".

OPNsense Business Edition
Many administrators reject frequent updates on
critical infrastructure, especially when they also
bring new and potentially untested features. For
this reason, the "OPNsense Business Edition"5 has
been available for a fee since 2020. Companies can
subscribe to this edition, which accesses a separate
code repository, for one- or three-year terms.
Currently, the Business Edition also adheres to the
half-yearly rhythm for major releases. However,
the code base is an older and therefore extensively
3. Structure
The key strength of OPNsense is its modular
structure, which can be easily extended by plugins.
Plugins can be combined so that the Unix principle
of "one tool for one task" is implemented in an
exemplary manner. For example, one of the typical
tasks of a web proxy is to scan data transmitted
over the web for viruses. The built-in proxy uses
the ClamAV plugin for this purpose. The plugin
can also be used by a mail server if OPNsense
is also used to run a mail relay. The plugins are
often interfaces to popular powerful open source
4. Interface
The OPNsense web interface should be intuitive for
most users of other commercial or open source
firewalls. All system components and plugins are
accessible via the vertical menu bar on the left. The
dashboard on the home page is configurable via
widgets (Figure 1). Especially useful is the intelligent
5
OPNsense Business Edition: https://shop.opnsense.com/product/opnsense-business-edition/
thomas-krenn.com | 5
tested community version. Updates appear less
frequently and are limited to fixes that are relevant
for security and stability. Furthermore, the Business
Edition includes additional plugins that are not
under an open source license. The most important
of these is OPNcentral, which allows the centralized
administration of multiple OPNsense instances.
The full range of its functionality is still under
development.
software packages. In many cases, these programs
do not have a graphical administration interface
but are controlled via configuration files and the
command line. Logic and syntax for management
often differ considerably. OPNsense plugins unify
management. Though administrators still need
to know their general functionality and features,
they no longer have to deal with the intricacies of
configuring, say, an intrusion detection system or a
VPN solution.
search function with auto-completion in the upper
right corner, which Figure 2 shows in action. From
there, you can go directly to the corresponding
configuration page. It is usually the fastest option
for navigation as opposed to clicking through the
menus.
 thomas-krenn.com | 6

Figure 1: The OPNsense dashboard is configurable via widgets if needed or desired.

Figure 2: The search function allows quick navigation throughout the system.

5. Packet filter and firewall

The core of the OPNsense firewall is the packet filter
software pf, which is part of the standard operating
system in all BSD variants. pf is a stateful packet
filter at the kernel level of the firewall operating
system and inspects every IP packet. Two things
play an essential role here: the ruleset, which
the admin creates, and a lookup table, which the
software generates and keeps up to date. This table
also stores the state of the connection, i.e. source
and destination, among other things, so that the

table is used for the vast majority of traffic and
packets rarely have to be checked on a rule basis.
As a result, rulesets can become very complex
without impacting performance. Even packets
from stateless protocols end up in the table. The
• "Pass" allows the passage from source to destination
• "Block" discards the package without notifying the sender (sometimes
also called drop)
• "Reject" drops the packet and, in the case of TCP and UDP protocols,
returns appropriate messages to the sender
Order of rules
When defining the rules, there are differences
between the default behavior of the packet filter
and the defaults that OPNsense makes via its
interface.
The packet filter allows you to specify the order of
rule execution yourself. The default setting there is
that the last rule in a chain always takes effect. The
rules you define in the OPNsense GUI are so-called
"quick rules", which the filter executes immediately
when a matching packet comes in, i.e. at the first
match – in contrast to the default. This makes it
easier to keep track of things and takes some of the
complexity out of firewall configuration.
Some rules are bound to a specific interface and
affect the incoming traffic at the interface, i.e. at
the WAN from outside, at the LAN from inside.
The considerably more complex "floating rules"
work differently. They apply to multiple interfaces
and may also apply to traffic originating from the
interface. They have a higher priority than rules for
individual interfaces. Individual floating rules are
not essential for basic protection, so they should
only be used if you have sufficient experience with
OPNsense.
thomas-krenn.com | 7
packet filter works here with heuristics that work
excellently in practice. The rules specify which of the
following three actions the firewall should perform
on a packet:
As a default value, OPNsense sets up a block-any
rule on the WAN side that blocks all packets that
do not match any of the individual rules. This rule is
defined as a floating rule, i.e. it takes effect before
the rules for the interfaces. It is implicit, so it does
not appear on the WAN side. On the LAN, on the
other hand, the default setting is pass-all, so that
all packets are initially allowed through from the
inside to the outside.
These settings can be tightened with additional
rules, for example, by restricting ports to 80, 443
and 53 on the LAN side, allowing only web browsing
and name resolution via DNS. When setting up the
rules, one usually works with aliases, for example,
one assigns a list of ports to a variable for which
a rule is then applied. In the same way, you can
assign a list of IP addresses to another alias – for
instance, to allow additional ports only for specific
hosts via another rule.
The firewall also combats spam using the same
logic. Various providers maintain dynamically
updated IP address lists of known spammers
available on the internet. These can be assigned to
aliases just like local IP lists.
 thomas-krenn.com | 8

Setting up basic firewall protection

On the WAN side, the default settings shown in adopted unchanged.
Figure 3, which block all traffic, can initially be

Figure 3: Initially, no changes are necessary on the WAN side of the firewall.

From the LAN side, the firewall is completely open
at first. Since most attacks require the involuntary
cooperation of users in their own network, additional
restrictions make sense here.
The procedure is always the same. First, we set the
stage by creating the appropriate aliases, in this
case, _PORTS for the aforementioned ports 80, 443,
and 53 (Figure 4). In the second step, we create a
pass rule in the corresponding LAN interface that
applies to all IPs and set the previously created alias
for ports (Figure 5).

Figure 4: As here for ports, aliases can also be created for other objects such as IP addresses.

Figure 5: The port alias is inserted into the new rule for TCP and UDP packets.
Following the same pattern, we can also create
aliases for specific IPs, such as a network of a
remote office or a server at an external hoster,
allow all protocols there, for example, and create
the corresponding rule. After saving the rule, we
should not forget to activate it as well.
Dynamic lists of known malware distributors and
Figure 6: Dynamic lists of malware spreaders as URL table aliases can be regularly updated via the expiration settings.
thomas-krenn.com | 9
spammers are already available as aliases and can
be used in rules according to the same principle.
One should take care to update these regularly.
The lists are restrictive in different ways, so it can
happen that legitimate requests are blocked. The
Spamhaus list (second entry in Figure 6) contains
fewer potentially problematic entries than the more
extensive FireHOL list.

6. Intrusion detection / intrusion prevention
Whether an intrusion prevention system (IPS) should
be considered part of a network's basic security is
a matter of debate. Such intrusion detection and
defense systems are complex and, if misconfigured,
occasionally do more harm than good. Since a
• Network-based intrusion detection system (NIDS)
• Network-based intrusion prevention system (NIPS)
• Network security monitoring
The difference between a firewall and an IDS/IPS
can be illustrated with the following imperfect
but useful analogy: In a medieval city, the firewall
rules would determine which gates (ports) should
remain open for, say, foot soldiers, horsemen or
chariots (packets of network protocols), while the
IPS/IDS would act as the guardian on the tower.
Based on his orders and experience, he assesses
the danger posed by a small group of walking
monks (application protocol) approaching the open
pedestrian gate. If he knows that robbers disguised
as monks are currently on the loose, he will sound
the alarm in his capacity as NIDS, but as NIPS he
will have the supposed monks intercepted. These
would then be scanned for concealed weapons, if
necessary (deep packet inspection).
So an IDS/IPS needs signatures, rules and heuristics
to detect threats at the application level. These
must be kept constantly up to date. There is always
a risk of false alarms (with IDS) or even mysterious
connection errors (with IPS) if too many false
positives occur. On the other hand, an IPS that is
set too laxly creates a feeling of false security.
thomas-krenn.com | 10
powerful IPS is integrated into OPNsense, its use
will be touched upon here nevertheless.
In this case, the IPS is the open source software
Suricata. Extensive and flexible, it can serve the
following purposes:
As a rule, an IDS/IPS requires much more knowledge
and administrative effort than a firewall. With
Suricata, a command line program without a GUI,
there is the added challenge of dealing with the
syntax of the commands and options. However,
OPNsense does a surprising amount of work for
the administrator here. The IPS can be put into
operation with a few clicks in the GUI.
If Suricata is deployed directly on the OPNsense
firewall, the IPS mode is available. In IDS mode, all
traffic is usually mirrored to a second interface to
decouple the analysis from the real-time traffic. As
an IPS, Suricata controls traffic directly on the firewall
interfaces. However, it is strongly recommended to
run a longer test with alerting before arming the
IPS and to evaluate the generated alerts regarding
false positives.
Of course, an IDS/IPS only makes sense on the WAN
interface if the firewall has open ports. Therefore,
it makes sense to limit the IPS to the LAN at this
point.

Setting up IDS/IPS
With the default settings, it is possible to put the IPS
into operation without any risk. This is done in the
Settings tab of the Administration menu item, as
Figure 7 shows. In the Download tab, you can find
a list of rulesets. To activate them, you just need
to select them and then click Download & Update
Rules. As Figure 8 shows, the Filter table column
is still empty. That is, even though IPS mode is
Figure 7: Intrusion detection is pre-installed in OPNsense and can be started easily.
Figure 8: All preset rulesets of the IPS are active.
thomas-krenn.com | 11
enabled, no packets are dropped. However, the
IPS already generates alerts, which are displayed
in the corresponding tab. Here, Figure 9 shows
obvious false positives (the suspected packets
come from the Google DNS). So, we need to disable
the corresponding rules. After the alerts are clean,
we can begin to arm individual or all rulesets, i.e.,
actually discard packets (Figure 9).
 thomas-krenn.com | 12

Figure 9: False positive warnings occasionally occur after the rulesets are activated.

Figure 10: Packets are not discarded until input filters are activated.

7. Virtual Private Networking (VPN) with WireGuard
Companies that offer home office, work with
external freelancers or operate multiple locations
generally require a virtual private network for
secure employee access. OPNsense provides
several options here. The classic options OpenVPN
and IPsec are available without additional plugins.
Plugins allow the use of additional protocols
such as PPTP, Stunnel or the Cisco AnyConnect-
compatible OpenConnect. Recently, WireGuard
has been gaining increasing acceptance. OPNsense
has a plugin for this as well, but it is not (yet) part
of the core distribution. Compared to OpenVPN
or IPsec, WireGuard has some unique features
that are generally advantageous in the enterprise
environment. That is why we are covering it here.
WireGuard is a comparatively new development
that originally comes from the Linux environment.
Since March 2020, the software has been part of the
mainline Linux kernel, and since December 2020, it
has enjoyed official support in the FreeBSD kernel,
starting with FreeBSD 13.
WireGuard has a clear performance advantage over
other VPN solutions (including OpenVPN) in most
use cases, uses modern cryptographic algorithms,
and was developed to be lean.
The most important difference compared to
OpenVPN is that WireGuard does not use certificates,
but only Public Key Encryption like SSH or PGP.
This eliminates the need to create and manage
Certification Authorities. WireGuard is not designed
to protect user anonymity, as the IP addresses of
connected devices are stored on the server. However,
Setting up WireGuard VPN
The configuration starts with the setup of the local
endpoint in the Local tab of the WireGuard plugin.
There we activate the plugin, give the endpoint a
name and enter the tunnel address of the endpoint.
thomas-krenn.com | 13
user anonymity is not usually a primary goal of VPN
applications for enterprises – the focus is generally
on connection security. WireGuard client software
is available for all common platforms and can be
easily installed via the software management or
the corresponding app stores. This applies not only
to all common Linux variants but also to Windows,
macOS, Android or iOS.
The WireGuard plugin for OPNsense was initiated
by m.a.x. it München in 2019 and has since been
further developed by m.a.x it, OPNsense employees
and the community. It has been classified as
stable since mid-2020. At the moment, WireGuard
is only recommended for scenarios involving a
modest number of clients or company networks, as
currently, every connection still has to be configured
manually.
The plugin with the name oswireguard is installed
via System -> Firmware -> Plugins on the user
interface. After successful installation, WireGuard
appears in the VPN section of the OPNsense
interface. It then offers two different configuration
types: "Site-to-Site" for connecting to an external
office network, for example, or "Road Warrior",
which – despite the name – is also the configuration
of choice for individual home office workstations.
Since WireGuard works according to the peer-to-
peer principle, i.e. it is not a client-server system, the
terminology occasionally causes confusion. So in
Road Warrior mode, each "client" to be connected
is a peer.
If the port setting remains empty, OPNsense
selects a suitable port itself. Alternatively, we enter
the desired (unprivileged) port ourselves (Figure
11). OPNsense generates public and private keys
 thomas-krenn.com | 14

automatically. In the second step, we open the
WAN interface for the port used by WireGuard using
a pass rule. UDP is sufficient as the protocol because
WireGuard tunnels all protocols via UDP (Figure 12).
Since WireGuard creates a separate interface for
the local endpoint, we need to create a rule for it as
well, which in the simplest case allows all traffic to
pass for all protocols and destinations, as shown in
Figure 13.

Figure 11: The configuration of WireGuard starts with the local endpoint.
 thomas-krenn.com | 15

Figure 12: The firewall for the WAN interface must allow WireGuard traffic to pass.

Figure 13: A rule is also required for the WireGuard interface.

 thomas-krenn.com | 16

This concludes the basic configuration. Next, the
peers that are allowed to use WireGuard must be
configured. This is done in the Endpoints tab of the
plugin configuration and can only be done when the
public key of the remote endpoint is known. The VPN
user must therefore already have the corresponding
client program installed and configured. For the
allowed IPs, we use the netmask suffix /32 to
ensure that the peer always connects to a fixed
IP (Figure 14). To complete the configuration, go
back to the Local tab, where you can now add the
existing endpoints in the Peers menu item.

Figure 14: When adding WireGuard peers (endpoints), their public key must be known.
 thomas-krenn.com | 17

Figure 15: All or selected peers are added to the local endpoint at the end.

All steps of this short tutorial can also be found in WireGuard peer7 and how to set up site-to-site
detail in the Thomas-Krenn wiki.6 It also describes connections with WireGuard8.
how to configure an Ubuntu computer as a

8. Hardware for OPNsense

When selecting the appropriate server for
OPNsense, two conditions must be met: Firstly, the
hardware must be compatible with the platform
in the first place, and secondly, it must deliver the
required performance for the intended purpose.
When using BSD-based systems such as OPNsense,
it should be noted that hardware components
are often not supported to the same extent as
Linux, for example. Therefore, it is advisable to
use tested and optimized systems, such as those
available from Thomas-Krenn. The overview page
in the Thomas-Krenn online shop9 lists all of the
approximately 40 different base systems, which
can be configured individually. The variety of
application purposes makes it difficult to assess
performance requirements in advance. The official
specifications of the OPNsense project regarding
hardware requirements are very general. They can
be found in a summarized form in the Thomas-
Krenn wiki.10 The documentation only differentiates

6
Setting up WireGuard step-by-step: https://www.thomas-krenn.com/en/wiki/OPNsense_WireGuard_VPN_for_Road_Warrior_configuration
7
WireGuard client configuration: https://www.thomas-krenn.com/en/wiki/Ubuntu_Desktop_as_WireGuard_VPN_client_configuration
8
WireGuard for site-to-site connections: https://www.thomas-krenn.com/en/wiki/OPNsense_WireGuard_VPN_Site-to-Site_configuration
9
OPNsense-optimized servers: https://www.thomas-krenn.com/en/products/application/opnsense-firewalls.html
10
Summary of OPNsense hardware requirements: https://www.thomas-krenn.com/en/wiki/OPNsense_hardware_requirements

between the three levels "Minimal", "Reasonable"
and "Recommended", though the specification is
very modest even for "Recommended" with 8 GB
RAM, a multi-core CPU with 1.5 GHz and 120 GB
Low Energy Systeme
For those who only need to manage smaller
networks and do not have a dedicated server room,
passively cooled, silent and power-saving mini
servers can be an ideal solution. At Thomas-Krenn,
this hardware is pooled under the LES series (Low
Energy Systems). All current OPNsense-compatible
LES systems meet the specifications indicated as
Rack servers for greater flexibility
Rack servers, by comparison, offer added flexibility.
In most cases, a server with one height unit and one
CPU socket will suffice. For network infrastructure,
such as firewall servers, it can be convenient to
Figure 16: Three examples of OPNsense-optimized servers from Thomas-Krenn: The low-cost and power-saving LES compact 4L, the flexible
and powerful LES network+ and the RI 1102D-F infrastructure server with front IO, Xeon CPU and up to 128 GB of RAM.
thomas-krenn.com | 18
SSD storage. In practice, much more RAM and CPU
performance will often be required, especially when
running IPS and VPN.
"Recommended". On the less expensive models,
such as LES v3 and LES compact 4L, the CPU is
hardwired, while the CPU on the LES network+ can
be replaced. The maximum RAM configuration
ranges from 8 GB to 32 GB. The four LAN ports on
the LES compact 4L – and six on the LES network+
– ensure good network management.
have the ports on the front. You can recognize
these servers at Thomas-Krenn by the trailing "F"
(for front) in the server name.

Performance estimates
The individual components of OPNsense place
very different demands on the hardware. The
packet filter itself is the most frugal and also the
easiest to estimate. RAM is the most crucial factor
here. However, an average state table with 1,000
connections requires only 10 MB, so there are hardly
any limitations here with modern systems. The CPU
load due to the packet filter is also relatively low.
However, the Suricata intrusion detection/
prevention system is different: Here, the CPU load
can become very high during heavy use. The load
depends not only on the number of users but also
on the number of rules. In addition, IDS/IPS checks
9. Conclusion and outlook
With the configuration of the packet filter, IPS and
VPN on the appropriate hardware, a large part of
basic network security has been covered. But these
three modules offer much more possibilities than
Web proxy for access control
In many cases, setting up a web proxy will be one of
the subsequent steps. A web proxy performs several
tasks: By caching content, it helps save bandwidth
and increases browsing speed.
It can also control which user is allowed to access
which web content, and finally, which content
should be blocked for the entire network.
The most important part for basic protection is the
Performance-Tests für WireGuard VPN: https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_Performance_Tests
11
thomas-krenn.com | 19
the packets before they reach the packet filter. As a
result, Suricata can become a limiting factor.
A VPN can also place a heavy load on the CPU and
become a bottleneck if the hardware is insufficient.
The Thomas-Krenn wiki contains detailed
performance measurements for WireGuard and
other VPNs with the LES compact 4L and the LES
network+, which can serve as a basis for deciding
on a hardware purchase. The test setup is described
in detail so that it can also be used for comparisons
with other servers or with minor adjustments for
other OPNsense modules.
those described here. Further steps build on the
practical knowledge that the administrator has
acquired during the basic setup.
filtering of malicious content for the entire network,
called category-based web filters in OPNsense. This
is done using blacklists – some of which are available
free of charge, others only against payment –
which are integrated directly into the interface. The
recording of the joint webinar by Thomas-Krenn
and m.a.x. it shows, among other things, how to
get started with proxy configuration.
 thomas-krenn.com | 20

High availability
After OPNsense is configured to your satisfaction,
you will usually want to secure it against failure. High
availability and failover are comparatively easy to
realize with OPNsense. Support for the appropriate
technology, such as Common Address Redundancy
Protocol (CARP) and firewall state synchronization,
are already built into the system. A detailed article
in the Thomas-Krenn wiki demonstrates how to set
up high availability in OPNsense.

Plugins for special scenarios

By combining different OPNsense plugins, the
system can be adapted very precisely to your
infrastructure and particular tasks, such as
connecting to user authentication, protecting mail
servers, expanding monitoring possibilities and
much more. The free e-book "OPNsense – The open
source firewall in practice" describes several such
approaches, including how to implement WLAN
protection (FreeRADIUS), secure an Exchange
server (Postfix, plugins and free virus scanners), or
set up traffic visualization and alerts (Grafana and
Telegraf).
In addition, the "OPNsense" category of the
Thomas-Krenn wiki constantly contains new or
updated articles on topics related to the free
security platform.

12 OPNsense webinar:
https://www.thomas-krenn.com/de/tkmag/webinare/opnsense-fuer-anwender-wie-sie-die-firewall-richtig-nutzen-und-absichern/
13 Setting up an HA cluster step-by-step: https://www.thomas-krenn.com/en/wiki/OPNsense_HA_Cluster_configuration
14 E-book on OPNsense: https://www.thomas-krenn.com/de/tkmag/allgemein/kostenloses-e-book-opnsense-firewall-in-der-praxis/
15 OPNsense in the Thomas-Krenn wiki: https://www.thomas-krenn.com/en/wiki/Category:OPNsense
Thomas-Krenn.AG
Speltenbach-Steinäcker 1
D-94078 Freyung
thomas-krenn.com