Open Source Software: Costs and Benefits

Some of those accessing this blog are undoubtedly considering deploying pfSense on their home network, or perhaps in a small office/home office (SOHO) environment. For that reason, I thought it might be useful to devote an article to the costs and benefits of using free and open source software (FOSS) versus commercial software and hardware when deploying a firewall/router.

Open Source Software: Factors to Consider

open source software

The Linksys WRT54G, an example of a consumer grade router.

The most obvious factor to consider is the monetary cost. Initially, this would seem to weigh heavily in favor of pfSense and other free firewall software. For $20 to $50, however, you can purchase a small Linksys, Netgear or Asus router, which uses almost no power and supports port forwarding, performs Network Address Translation (NAT), acts as a Dynamic Host Configuration Protocol (DHCP) server, and provides stateful packet filters. If you use Linux and netfilter, or for that matter m0n0wall or pfsense, even if you have an old PC on which to run the software, it will cost you at least a few dollars a month in electricity. Unless you are familiar with the software you are using, you will find it more difficult to configure than one of the cheap consumer-grade routers, so there is an additional investment of time. If you are setting it up for a small business, it will cost more to pay for the employee’s time to set up a Linux or pfSense firewall than the Linksys would cost to buy. If all you require is a router/firewall than can do port forwarding and DHCP, then there are readily available commercial solutions that are affordable.

If you require additional functionality, however, the situation may change. Commercial VPN solutions can be staggeringly expensive. Yet free solutions such as pfSense and m0n0wall will also work. Even taking into account the fact that the free solutions may not have the same features and capabilities of the commercial version, if you need to implement a virtual private network and there is open source software that meets your requirements, then you can achieve substantial savings.

There are additional factors, some of which are related to cost. For example, support: what does it cost, is it available, and how timely is the support? Moreover, what format does support take: phone, e-mail, online forums, service calls, and so on?

open source software

If installing and configuring netfilter, pfSense or another open source solution doesn’t sound intimidating, an old PC may be suitable.

Time is another factor, and this can cut both for and against open source software. Take the case where a business is considering entering into a partnership with another company. This other company is concerned because the partnership requires sending sensitive data, and the business only has a consumer-grade firewall. The IT department could recommend the purchase of an enterprise-level firewall. This will require contacting vendors, getting quotes, passing a quote on to a manager for approval, and then submitting a purchasing order to the accounting department. Or the IT department can just find an old PC, load Linux and netfilter onto it (or m0n0wall or pfSense or IPCop or any one of a number of open source software solutions), and be done with it, especially if time is of the essence. On the other hand, if your IT department is not familiar with Linux or BSD, deploying an open source solution may actually cost you time, so you would be better off seeking a commercial product.

Another related factor is performance. Speed, efficiency, and reliability are important indices of performance. A fast solution that crashes all the time isn’t very useful. Conversely, a reliable software package that runs slowly may not be the best option.

Usability is another factor, and it relates to cost. If the learning curve is very high, then your training costs will rise. You may want to consider whether a product is customizable if it does not do exactly what you want it to do.

It is often important to consider how well-established the product is. The more well-established the software is, the more likely its creators will be around in the future. A larger and more well-established project will also likely have better community support and reliability. You do not want to invest a lot of time into a product that is likely to go away. In this regard, open source software does well. The netfilter project started in 1998; m0n0wall has been around since 2004, and PF, the packet filtering software on top of which pfSense is built, has been part of OpenBSD since 2001.

Even a security product like a firewall involves security implications, which should be an important factor in your choice. Is the product secure, and will it be handling secure data? You want to consider whether it will be opening any security risks, as well as what type of auditing and logging it can produce.

Finally, you will want to review the license agreement closely. Often the free software is not free if you are a business, or there are special restrictions on the number of installations or other criteria. If your company has a legal department or if you have legal counsel, it might not be a bad idea to have them review the license agreement.


It may just be my bias as the owner of a blog devoted to a particular piece of open source software, but I am inclined to think that in many if not most circumstances, you will find open source software to be the more cost-effective and efficient solution. At one end of the spectrum, commercial consumer-grade routers provide a lot of functionality at a low price. At the other end of the spectrum, enterprise-level firewalls often provide a greater level of management control and logging capabilities, which a mid-sized or large company may require. These capabilities often justify the higher cost. But for those who fall in between these two extremes, often open source software provides the better alternative.

External Links:

The True Cost of Open Source – web site devoted to explaining how you can cut development costs and improve performance with open source software.

Open Source Applications: Benefits and Risks at

10 Reasons Open Source Is Good for Business at

Failover with CARP in PF: Part One

Failover with CARP in PF

FailoverCommon Address Redundancy Protocol (CARP) is a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy. It was developed as a non-patent-encumbered alternative to Virtual Router Redundancy Protocol (VRRP), which is defined in RFC 2281 and 3768 and was quite far along towards becoming an IETF-sanctioned standard. It is also an alternative to the Hot Standby Router Protocol (HSRP). It manages failover at the intersection of the link layer and IP layer of the OSI model. Each CARP group has a virtual MAC address, and the CARP advertisements are sent out with this as the source address, which helps switches determine which port the virtual MAC address is currently at.

One of the main purposes of CARP is to ensure that the network will keep functioning even when a firewall goes down because of errors or planned maintenance activities such as upgrades (failover). CARP works by allowing a group of hosts on the same network segment to share an IP address. This group of hosts is referred to as a “redundancy group”. The redundancy group is assigned an IP address that is shared among the group members. Within the group, one host is designated as the master and the other as backups. The master host is the one that currently holds the shared IP; it responds to any traffic or ARP requests directed at it. If the master goes down, one of the backups will inherit the IP address. The handover from one CARP host to another may be authenticated, essentially by setting a shared secret, much like a password. The master then sends out CARP advertisement messages via multicast using the CARP protocol (IP Protocol 112) on a regular basis, and the backup hosts listen for this advertisement. If the advertisements stop, the backup hosts will begin advertising. The advertisement frequency is configurable, and the host which advertises the most frequently is the one most likely to become master in the event of a failure.

CARP is rather similar to VRRP, with a few significant differences:

  • The CARP protocol is address family independent, with the OpenBSD implementation supporting both IPv4 and IPv6.
  • CARP has an “arpbalance” feature that allows multiple hosts to share a single IP address simultaneously (in this configuration, there is a virtual MAC address for each host, but only one IP address).
  • CARP uses a cryptographically strong SHA-1 keyed-hash message authentication code (HMAC) to protect each advertisement.

Some synchronization is required, an at least in the case of PF firewalls, pfsync can handle it. If it is done properly, active connections will be handed over without noticeable interruption. The purpose of pfsync in this context is to act as a virtual network interface specially designed to synchronize state information between PF firewalls. In order to ensure that pfsync meets the packet volume and latency requirements, the initial implementation has no built-in authentication. An attacker who has local link layer access to the subnet used for pfsync traffic can add, change, or remove states from the firewalls. Therefore, it is strongly recommended that a dedicated, trusted network be used for pfsync. This can be as simple as a crossover cable between interfaces on two firewalls.

Failover with CARP: Configuration

Here is a simple example CARP configuration:

sysctl -w net.inet.card.allow=1
ifconfig carp1 create
ifconfig carp1 vhid 1 pass password carpdev em0 \
advskew 100 netmask

This does the following:

  • Enales receipt of CARP packets (the default setting)
  • Creates a carp(4) interface (carp1)
  • Configures carp1 for virtual host #1, enables a password, sets em0 as the interface belonging to the group, and makes the host a backup die to the advskew of 100 (assuming the master has an advskew less than 100). The shared IP assigned to this group is

In the next article, I will cover failover CARP configuration in BSD with some real world scenarios.

External Links:

Firewall Redundancy with CARP and pfsync at

Firewall Failover with pfsync and CARP at

Packet Filter: The Engine of pfSense

Packet FilterpfSense is, as most users know, a specialized version of FreeBSD. It can be configured an upgraded through a web-based interface and often runs on embedded systems; it requires no knowledge of the underlying FreeBSD system. Those curious enough to find out, however, will be interested to know that pfSense is based on OpenBSD’s powerful pf (Packet Filter) software, which was released in late 2001 and has since been ported to many other operating systems including FreeBSD, NetBSD, DragonFly BSD, Debian GNU/Free BSD, and Mac OS X 10.7 “Lion” and later.

OpenBSD and the other BSD variants are direct descendants of BSD Unix. BSD, sometimes called Berkeley Unix, is a Unix operating system derivative developed and distributed by the Computer Systems Research Group (CSRG) of the University of California, Berkeley, from 1977 to 1995. The final release from Berkely was 1995’s 4.4BSD-Lite Release 2, after which the CSRG was dissolved and development of BSD at Berkeley ceased. In the meantime, as CSRG was winding down, small groups of enthusiasts around the world began working on further development of the code. Several different variants of BSD Unix came into existence. The OpenBSD group became known as the most security-oriented of the BSDs. For its packet filtering needs, it used a program called IPFilter, written by Darren Reed.

The packet filter’s main function is to filter network packets by matching the properties of individual packets and the network connections build from those packets agains the filtering criteria defined in its configuration files. The packet filter is responsible for deciding what to do with those packets, which could mean passing them through or rejecting them, or triggering events that other parts of the operating system or external applications are set up to handle.

The IPFilter subsystem performed this function within OpenBSD, but in May 2001, IPFilter was removed from the OpenBSD source tree due to licensing issues. The OpenBSD version of IPFilter contained several changes and customizations that, as it turned out, were not allowed under the licensing agreement. For a few weeks, the development version of OpenBSD did not include any firewalling software.

Enter Packet Filter

However, Daniel Hartmeier had already begun work on his own packet filtering software, called PF, and after a few months of development, it was ready to be added to OpenBSD. PF was added as a default part of the OpenBSD 3.0 base system in December 2001. Migrating from IPFilter to PF sense did not pose major problems, as their configuration languages were similar. Moreover, PF has done well in performance tests, performing equally well or better under stress on OpenBSD 3.1 than either IPFilter on OpenBSD 3.1 (or iptables on Linux). PF’s overhead is relatively low, and is capable of running effectively on rather modest hardware.

Future installments of this series of articles will go into greater depth on how to configure and run PF. For now, it should be mentioned that in order to run PF, you need to install and run a BSD system such as OpenBSD, FreeBSD, NetBSD, or DragonFly BSD. OpenBSD is the BSD variant of choice for many, as this is where PF was first introduced and where essentially all PF development happens. Moreover, the newest and most-up-to-date PF code is always to be found on OpenBSD. If you are planning to run PF on FreeBSD, NetBSD, DragonFly BSD, or another system, you should check your system’s release notes and other documentation about which version of PF is included.

External Links:

PF documentation in the OpenBSD FAQ

© 2013 David Zientara. All rights reserved. Privacy Policy