OPNSENSEMore than a firewall

3|

3|

4|

5|

5|

5|

6|

7|8|

11|

10|

13|

17|

19|

19|

20|

18|

1. OPNsense – more than a firewall

2. Introduction to OPNsense

Secure platform Versions and release cycle OPNsense Business Edition

3. Structure

4. Interface

5. Packet filter and firewall

Order of rules Setting up basic firewall protection

6. Intrusion Detection/Intrusion Prevention

Setting up IDS/IPS

7. Virtual Private Networking (VPN) with WireGuard

Setting up WireGuard VPN

8. Hardware for OPNsense

Low Energy Systems Rack servers for greater flexibility Performance estimates

9. Conclusion and outlook

Web proxy for access control High availability Plugins for special scenarios

Table of contents

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.

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

Introduction to OPNsense

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

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.

• 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

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.

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".

Secure platform

Versions and release cycle

thomas-krenn.com | 5

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

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.

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

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.

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

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.

OPNsense Business Edition

3. Structure

4. Interface

5 OPNsense Business Edition: https://shop.opnsense.com/product/opnsense-business-edition/

thomas-krenn.com | 6

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

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

The core of the OPNsense fi rewall is the packet fi lter software pf, which is part of the standard operating system in all BSD variants. pf is a stateful packet fi lter at the kernel level of the fi rewall 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

5. Packet fi lter and fi rewall

thomas-krenn.com | 7

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.

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.

Order of rules

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

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:

• "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

thomas-krenn.com | 8thomas-krenn.com | 8

On the WAN side, the default settings shown in Figure 3, which block all traffi c, can initially be

adopted unchanged.

From the LAN side, the fi rewall is completely open at fi rst. 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).

Setting up basic fi rewall protection

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

Figure 4: As here for ports, aliases can also be created for other objects such as IP addresses.

thomas-krenn.com | 9

Following the same pattern, we can also create aliases for specifi c IPs, such as a network of a remote offi ce 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

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.

Figure 6: Dynamic lists of malware spreaders as URL table aliases can be regularly updated via the expiration settings.

Figure 5: The port alias is inserted into the new rule for TCP and UDP packets.

thomas-krenn.com | 10

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.

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.

• Network-based intrusion detection system (NIDS)• Network-based intrusion prevention system (NIPS)• Network security monitoring

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

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:

6. Intrusion detection / intrusion prevention

thomas-krenn.com | 11

Figure 7: Intrusion detection is pre-installed in OPNsense and can be started easily.

Figure 8: All preset rulesets of the IPS are active.

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 fi nd 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

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).

Setting up IDS/IPS

thomas-krenn.com | 12

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

Figure 10: Packets are not discarded until input fi lters are activated.

thomas-krenn.com | 13

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,

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.

7. Virtual Private Networking (VPN) with WireGuard

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.

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

Setting up WireGuard VPN

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 suffi cient 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 traffi c to pass for all protocols and destinations, as shown in Figure 13.

Figure 11: The confi guration of WireGuard starts with the local endpoint.

thomas-krenn.com | 15

Figure 12: The fi rewall for the WAN interface must allow WireGuard traffi c to pass.

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

thomas-krenn.com | 16

This concludes the basic confi guration. Next, the peers that are allowed to use WireGuard must be confi gured. This is done in the Endpoints tab of the plugin confi guration 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 confi gured. For the allowed IPs, we use the netmask suffi x /32 to ensure that the peer always connects to a fi xed IP (Figure 14). To complete the confi guration, 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

All steps of this short tutorial can also be found in detail in the Thomas-Krenn wiki.6 It also describes how to confi gure an Ubuntu computer as a

WireGuard peer7 and how to set up site-to-site connections with WireGuard8.

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

6 Setting up WireGuard step-by-step: https://www.thomas-krenn.com/en/wiki/OPNsense_WireGuard_VPN_for_Road_Warrior_confi guration7 WireGuard client confi guration: https://www.thomas-krenn.com/en/wiki/Ubuntu_Desktop_as_WireGuard_VPN_client_confi guration8 WireGuard for site-to-site connections: https://www.thomas-krenn.com/en/wiki/OPNsense_WireGuard_VPN_Site-to-Site_confi guration9 OPNsense-optimized servers: https://www.thomas-krenn.com/en/products/application/opnsense-fi rewalls.html10 Summary of OPNsense hardware requirements: https://www.thomas-krenn.com/en/wiki/OPNsense_hardware_requirements

When selecting the appropriate server for OPNsense, two conditions must be met: Firstly, the hardware must be compatible with the platform in the fi rst 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 confi gured individually. The variety of application purposes makes it diffi cult to assess performance requirements in advance. The offi cial specifi cations 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

8. Hardware for OPNsense

thomas-krenn.com | 18

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

"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.

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

have the ports on the front. You can recognize these servers at Thomas-Krenn by the trailing "F" (for front) in the server name.

Low Energy Systeme

Rack servers for greater flexibility

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.

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

SSD storage. In practice, much more RAM and CPU performance will often be required, especially when running IPS and VPN.

thomas-krenn.com | 19

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

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.

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

those described here. Further steps build on the practical knowledge that the administrator has acquired during the basic setup.

Performance estimates

9. Conclusion and outlook

11Performance-Tests für WireGuard VPN: https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_Performance_Tests

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

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.

Web proxy for access control

thomas-krenn.com | 20

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.

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.

High availability

Plugins for special scenarios

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_configuration14 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.AGSpeltenbach-Steinäcker 1D-94078 Freyungthomas-krenn.com