Best Firewall Solutions for FreeBSD in 2026

FreeBSD ships with two production-grade firewalls built directly into the kernel: PF and IPFW. On top of these, two major FreeBSD-based distributions -- OPNsense and pfSense -- turn the operating system into a dedicated firewall appliance with a web interface, plugin ecosystem, and enterprise support.

Choosing the right firewall depends on whether you are securing a single server, building a network perimeter, or deploying a full-featured gateway. This guide compares all four options with FreeBSD-specific detail that generic comparisons skip.

Quick Recommendation

If you want a short answer:

PF is the best firewall for most FreeBSD servers. Its syntax is readable, its feature set covers NAT, stateful filtering, tables, anchors, and traffic normalization in a single coherent ruleset. If you are running a FreeBSD server and need a firewall, start with PF.
IPFW is the right choice when you need deep integration with FreeBSD-specific features like dummynet for traffic shaping and QoS, or when you prefer numbered rule ordering and granular per-rule control.
OPNsense is the best option for dedicated firewall appliances. It provides a polished web UI, frequent security updates, a plugin system, and an active open-source community.
pfSense is the established alternative when you need Netgate commercial support, TAC-level service contracts, or compatibility with existing pfSense deployments.

The rest of this article explains why, with configuration examples and a detailed feature comparison.

PF (Packet Filter) on FreeBSD

PF originated in the OpenBSD project and was ported to FreeBSD starting with FreeBSD 5.3. It has been a first-class citizen in the FreeBSD kernel for over two decades and is the firewall most FreeBSD administrators reach for first.

For a full walkthrough of PF configuration, see our PF firewall guide.

How PF Works

PF evaluates rules from top to bottom and applies the last matching rule by default. This "last match wins" behavior is fundamental to PF's design -- it means you write your general policies first and your exceptions afterward. You can override this with the quick keyword to stop evaluation at the first match, which is useful for early-exit deny rules.

PF operates as a stateful firewall. When a rule matches and creates a state entry, subsequent packets belonging to the same connection are handled by the state table without re-evaluating the ruleset. This makes PF efficient at high connection rates.

Key Features

Tables. PF tables hold sets of IP addresses and are optimized for fast lookups even with millions of entries. They are the standard way to implement blocklists, allowlists, and dynamic address sets. Tables can be manipulated at runtime with pfctl without reloading the ruleset.

Anchors. Anchors let you load sub-rulesets dynamically at runtime. This is useful for delegation -- a jail manager can control firewall rules for its jails without touching the main ruleset, or an intrusion detection system can inject block rules into a dedicated anchor.

NAT and Redirection. PF handles NAT, port forwarding, and binat (bidirectional NAT) directly in the ruleset using nat-to, rdr-to, and binat-to directives. There is no separate NAT configuration file or tool.

Traffic Normalization. The scrub directive reassembles fragmented packets, clears unusual flag combinations, and normalizes TTL values. This hardens the host against evasion techniques that rely on ambiguous packet interpretation.

Logging. PF logs packets to the pflog0 interface, which you can capture with tcpdump in real time or feed into a logging pipeline. You log per-rule by adding the log keyword.

SYN Proxy. PF can proxy TCP handshakes on behalf of backend servers, completing the three-way handshake at the firewall before forwarding the connection. This protects against SYN flood attacks without dedicated hardware.

Pros

Clean, readable syntax that is well-documented in the FreeBSD Handbook and the OpenBSD PF FAQ.
Last-match-wins evaluation makes complex rulesets easier to reason about.
Tables provide O(1) lookups for large address sets.
Anchors allow modular, runtime-modifiable rulesets.
Active development on both the OpenBSD and FreeBSD sides.

Cons

The FreeBSD port sometimes lags behind OpenBSD PF features. Not every OpenBSD PF improvement lands immediately.
Multi-threaded performance has improved significantly in recent FreeBSD releases but was historically a concern compared to IPFW on SMP systems.
No built-in layer 7 application filtering. For deep packet inspection you need a proxy or IDS.

IPFW (IP Firewall) on FreeBSD

IPFW is the native FreeBSD firewall. It has been part of the FreeBSD kernel since the early 1990s and is developed entirely within the FreeBSD project. Unlike PF, which was imported from OpenBSD, IPFW is FreeBSD-native code maintained by FreeBSD committers.

How IPFW Works

IPFW uses numbered rules evaluated from lowest to highest number. The first matching rule wins and processing stops (unless the rule is a skipto or count action). Every IPFW ruleset has an implicit rule 65535 at the end -- its default action (allow or deny) depends on the kernel configuration.

This first-match-wins, numbered-rule model gives you explicit control over evaluation order. You can insert rules at specific positions, leave gaps between rule numbers for future additions, and reorganize without rewriting the entire ruleset.

Key Features

Dummynet Traffic Shaping. This is IPFW's standout feature. Dummynet lets you create pipes and queues that simulate bandwidth limits, latency, packet loss, and jitter. It is used in production for WAN emulation, QoS enforcement, and bandwidth management. No other FreeBSD firewall has equivalent built-in traffic shaping.

Stateful Filtering. IPFW supports dynamic rules via keep-state and check-state. When a packet matches a rule with keep-state, IPFW creates a dynamic rule entry that matches return traffic. This provides stateful connection tracking similar to PF's state table.

In-Kernel NAT. IPFW includes ipfw nat for in-kernel NAT, as well as integration with natd for more complex NAT scenarios. The in-kernel NAT is faster since it avoids context switches to userspace.

Lookup Tables. IPFW supports tables for address lookups, similar to PF tables. Tables can hold IP addresses, network prefixes, interface names, and other key types with associated values.

Sets. IPFW rules can be organized into numbered sets (0-31) that can be enabled or disabled atomically. This lets you swap between ruleset configurations without a gap in filtering.

Logging. IPFW logs via syslog or the ipfw log facility. You can set per-rule log limits to prevent log flooding.

Pros

Native FreeBSD code with deep kernel integration.
Dummynet is unmatched for QoS and traffic shaping.
First-match-wins numbered rules give explicit control over evaluation order.
Rule sets allow atomic ruleset swapping.
Mature and stable -- IPFW has been in production use for over 30 years.

Cons

Syntax is more verbose and less readable than PF for complex rulesets.
No equivalent to PF anchors for dynamic sub-rulesets.
Smaller community and less online documentation than PF.
Configuration files tend to be shell scripts that call ipfw add commands, which is less structured than PF's declarative ruleset file.

OPNsense

OPNsense is a FreeBSD-based firewall distribution that turns commodity hardware or a virtual machine into a dedicated security appliance. It forked from pfSense in 2015 and has developed independently since, with a focus on code quality, security updates, and an open development process.

For a head-to-head comparison, see our OPNsense vs pfSense guide.

What OPNsense Provides

OPNsense runs on HardenedBSD (a security-enhanced FreeBSD fork) and uses PF as its underlying packet filter. On top of this, it adds:

Web UI. A modern, responsive web interface for all firewall management. You can configure rules, NAT, VPN, DHCP, DNS, and intrusion detection without touching the command line.
Plugin System. OPNsense has a growing plugin ecosystem that includes WireGuard, HAProxy, Nginx reverse proxy, CrowdSec, Zenarmor (formerly Sensei) for application-layer filtering, and dozens of other packages.
Frequent Updates. OPNsense follows a regular release cadence with weekly security updates and major releases roughly twice per year.
API. A REST API for automation and integration with configuration management tools.
Intrusion Detection. Built-in Suricata IDS/IPS integration with downloadable rulesets.
Multi-WAN and Failover. Gateway groups with health checks, failover, and load balancing across multiple internet connections.

Pros

Clean, modern web interface that does not require CLI expertise.
Active open-source development with transparent decision-making.
HardenedBSD base provides additional exploit mitigations (ASLR, SafeStack, PIE by default).
Plugin architecture makes it extensible without bloating the base system.
Good documentation and an active community forum.

Cons

Running a full distribution is heavier than a bare PF or IPFW ruleset on an existing server.
Not suitable for protecting a single application server -- it is designed as a dedicated gateway.
Some advanced PF features are abstracted away by the web UI, which can limit power users.
Hardware requirements are higher than a minimal FreeBSD install (2 GB RAM minimum, 4 GB recommended).

pfSense

pfSense is the older FreeBSD-based firewall distribution, first released in 2004. It is developed by Netgate and has a large installed base in both home labs and enterprise environments.

What pfSense Provides

pfSense runs on FreeBSD and uses PF as its packet filter. Its feature set is similar to OPNsense at the core:

Web UI. A mature web interface for managing firewall rules, NAT, VPN (OpenVPN and IPsec), DHCP, and DNS.
Package Manager. Packages for Snort/Suricata IDS, Squid proxy, pfBlockerNG (ad/malware blocking and GeoIP filtering), and other tools.
Commercial Support. Netgate offers paid support subscriptions (TAC), hardware appliances, and pfSense Plus (a proprietary version) for enterprise customers.
High Availability. CARP-based failover for active/passive HA configurations.
VPN. Built-in support for OpenVPN, IPsec, and WireGuard.

Pros

Large installed base with extensive community knowledge, tutorials, and forum posts.
Commercial support from Netgate for organizations that need SLA-backed contracts.
Proven in enterprise environments with years of production history.
pfBlockerNG is a powerful tool for DNS-level and IP-level threat blocking.

Cons

The Community Edition (CE) receives updates less frequently than OPNsense.
Netgate's licensing model has shifted toward pfSense Plus as the primary product, creating uncertainty about the long-term future of the open-source CE version.
The web UI, while functional, has not been modernized as aggressively as OPNsense's interface.
Development process is less transparent than OPNsense's fully open model.

PF vs IPFW: Detailed Comparison

Since PF and IPFW are the two firewalls you will choose between on a standard FreeBSD server, here is a deeper comparison.

Syntax Philosophy

PF uses a declarative ruleset file (/etc/pf.conf) that is loaded atomically. You edit the file, then run pfctl -f /etc/pf.conf to load the entire ruleset at once. The syntax is designed to be readable:

shell
pass in on egress proto tcp to port { 80 443 } keep state

IPFW uses imperative commands that add rules one at a time, typically from a shell script. Rules are numbered and evaluated in order:

shell
ipfw add 100 allow tcp from any to me dst-port 80,443 in setup keep-state

PF's declarative approach is easier to audit because you can read the entire policy in one file. IPFW's imperative approach gives you finer control over rule insertion and modification at runtime.

Rule Evaluation

| Aspect | PF | IPFW |

|--------|-----|------|

| Default behavior | Last matching rule wins | First matching rule wins |

| Short-circuit | quick keyword | Default (every rule) |

| Rule ordering | Top to bottom, position by line | Numbered, 1-65535 |

PF's last-match-wins default is unusual but powerful. It lets you write a general "pass all" policy at the top and progressively add restrictions below. The quick keyword converts any rule to first-match behavior when you need it.

IPFW's first-match-wins is more intuitive for administrators coming from other firewalls (iptables, Cisco ACLs). Each rule is explicitly numbered, so you always know the evaluation order.

Performance

Both firewalls handle gigabit-speed traffic without issues on modern hardware. At 10 Gbps and above, differences start to matter:

IPFW has historically been better optimized for SMP (symmetric multiprocessing) on FreeBSD because it was designed for the FreeBSD kernel's threading model from the start.
PF's SMP performance has improved substantially in FreeBSD 13 and 14 with work on reducing lock contention in the state table.
For stateless rules (no connection tracking), both firewalls are fast enough that the NIC is the bottleneck before the firewall.
For stateful filtering at very high packet rates, benchmarking your specific workload is the only reliable way to compare.

Traffic Shaping

IPFW wins here. Dummynet is built into IPFW and provides bandwidth pipes, weighted queues, delay simulation, and packet loss control. It is used by Netflix for WAN emulation testing and by ISPs for bandwidth management.

PF has no built-in traffic shaping on FreeBSD. The ALTQ framework that PF uses on OpenBSD is available but less commonly deployed on FreeBSD and has received less development attention.

NAT

Both firewalls handle NAT well. PF integrates NAT directly into the ruleset syntax with nat-to and rdr-to, which keeps everything in one file. IPFW uses ipfw nat with separate configuration parameters, or the natd daemon for complex scenarios.

PF's NAT syntax is generally considered cleaner and easier to read.

Feature Comparison Table

|---------|-----|------|----------|---------|

| Underlying filter | PF | IPFW | PF | PF |

| Web UI | No | No | Yes | Yes |

| Stateful filtering | Yes | Yes | Yes | Yes |

| Plugin ecosystem | No | No | Yes | Yes (packages) |

Basic Configuration Examples

Here are minimal but functional configurations for PF and IPFW that accomplish the same goal: allow SSH and HTTP/HTTPS inbound, allow all outbound, and block everything else.

PF Configuration (`/etc/pf.conf`)

shell
# Define macros
ext_if = "vtnet0"
tcp_services = "{ ssh, http, https }"

# Options
set skip on lo0
set block-policy drop

# Normalization
scrub in all

# Block everything by default
block all

# Allow outbound traffic
pass out on $ext_if proto { tcp udp icmp } from ($ext_if) keep state

# Allow inbound services
pass in on $ext_if proto tcp to ($ext_if) port $tcp_services keep state

# Allow ping
pass in on $ext_if proto icmp icmp-type echoreq keep state

Enable and start PF:

sh
sysrc pf_enable=YES
sysrc pflog_enable=YES
service pf start
service pflog start

Reload the ruleset after editing:

sh
pfctl -f /etc/pf.conf

Check loaded rules:

sh
pfctl -sr

IPFW Configuration (`/etc/ipfw.rules`)

sh
#!/bin/sh

# Flush existing rules
ipfw -q flush

# Define variables
ext_if="vtnet0"

# Allow loopback
ipfw -q add 10 allow all from any to any via lo0

# Deny spoofed loopback traffic
ipfw -q add 20 deny all from any to 127.0.0.0/8
ipfw -q add 30 deny all from 127.0.0.0/8 to any

# Check state for established connections
ipfw -q add 50 check-state

# Allow outbound traffic and create state
ipfw -q add 100 allow tcp from me to any out via $ext_if setup keep-state
ipfw -q add 110 allow udp from me to any out via $ext_if keep-state
ipfw -q add 120 allow icmp from me to any out via $ext_if keep-state

# Allow inbound SSH, HTTP, HTTPS
ipfw -q add 200 allow tcp from any to me dst-port 22 in via $ext_if setup keep-state
ipfw -q add 210 allow tcp from any to me dst-port 80,443 in via $ext_if setup keep-state

# Allow inbound ping
ipfw -q add 300 allow icmp from any to me icmptype 8 in via $ext_if keep-state

# Deny everything else
ipfw -q add 65000 deny all from any to any

Enable and start IPFW:

sh
sysrc firewall_enable=YES
sysrc firewall_script="/etc/ipfw.rules"
service ipfw start

List active rules:

sh
ipfw list

Both configurations achieve the same result. Notice how PF's declarative style fits in fewer lines, while IPFW's numbered rules make the evaluation order explicit.

For a deeper dive into PF configuration including advanced NAT, anchors, and table management, see our PF firewall guide.

Decision Guide

Use PF if...

You are securing a FreeBSD server (web server, database, application server).
You want a single, readable configuration file for all firewall rules and NAT.
You need tables for large blocklists or dynamic address sets.
You want anchors for modular rulesets (e.g., per-jail rules).
You are coming from OpenBSD or have PF experience.

Use IPFW if...

You need traffic shaping or QoS via dummynet.
You prefer explicit numbered rule ordering.
You need atomic ruleset swapping with IPFW sets.
You are building a network testing or WAN emulation environment.
You want the firewall most deeply integrated with the FreeBSD kernel.

Use OPNsense if...

You are building a dedicated firewall, router, or gateway appliance.
You want a web UI and do not want to manage firewall rules from the command line.
You need built-in VPN, IDS/IPS, DNS filtering, or reverse proxy.
You prefer open-source development with transparent governance.
You want the security benefits of HardenedBSD as the base.

Use pfSense if...

You need commercial support with an SLA from Netgate.
You have existing pfSense deployments and need consistency.
Your organization requires vendor-backed enterprise support.
You want pfBlockerNG for DNS-level and GeoIP-based threat blocking.

Combining Firewalls

You cannot run PF and IPFW simultaneously on the same system -- they are mutually exclusive in practice. Choose one for each host.

However, you can absolutely run PF on your servers and OPNsense (which uses PF internally) as your network perimeter firewall. This is a common and sound architecture: OPNsense handles the gateway, VPN termination, and IDS at the network edge, while PF on each server provides host-level defense in depth.

For a broader approach to FreeBSD security beyond firewalls, see our FreeBSD hardening guide.

Frequently Asked Questions

Which FreeBSD firewall is best for beginners?

PF has the most readable syntax and the best documentation for newcomers. The FreeBSD Handbook PF chapter and the OpenBSD PF FAQ are both excellent learning resources. If you prefer a graphical interface, OPNsense eliminates the need to write firewall rules by hand entirely.

Can I use PF and IPFW at the same time?

No. While it is technically possible to load both into the kernel, running them simultaneously causes unpredictable behavior because both hook into the same packet processing path. Choose one per system.

Is PF on FreeBSD the same as PF on OpenBSD?

No. FreeBSD ported PF from OpenBSD, but the two implementations have diverged over time. FreeBSD's PF has its own SMP optimizations and may not support every feature added to OpenBSD PF immediately. The core syntax and concepts are the same, but advanced features and internal behavior can differ. Always consult the FreeBSD pf.conf(5) man page, not only the OpenBSD documentation.

Does OPNsense use PF or IPFW?

OPNsense uses PF as its underlying packet filter. When you create rules in the OPNsense web UI, it generates PF rules behind the scenes. You can view the generated PF ruleset from the OPNsense diagnostics menu.

How do I block a list of IPs with PF?

Use a PF table. Create a file with one IP or CIDR per line (e.g., /etc/pf.blocklist), then reference it in your ruleset:

shell
table <blocklist> persist file "/etc/pf.blocklist"
block drop in quick on $ext_if from <blocklist>

You can add or remove addresses at runtime without reloading the ruleset:

sh
pfctl -t blocklist -T add 192.0.2.1
pfctl -t blocklist -T delete 192.0.2.1

Tables handle millions of entries efficiently.

How does dummynet traffic shaping work in IPFW?

Dummynet creates virtual "pipes" with configurable bandwidth, delay, and packet loss. You direct traffic through a pipe with an IPFW rule:

sh
ipfw pipe 1 config bw 10Mbit/s delay 20ms
ipfw add 500 pipe 1 tcp from any to any dst-port 80 out

This limits all outbound HTTP traffic to 10 Mbps with 20 ms of added latency. You can combine pipes with weighted fair queuing for more sophisticated QoS policies.

Is pfSense still open source?

pfSense CE (Community Edition) remains open source under the Apache 2.0 license. However, Netgate's primary product is now pfSense Plus, which is proprietary. The community edition receives updates less frequently than it once did. If open-source governance matters to you, OPNsense's development model is more transparent.

Conclusion

FreeBSD gives you genuinely strong options for firewalling at every level. PF is the best default choice for server-level packet filtering -- its syntax is clean, its feature set is complete, and it is well-documented. IPFW is the right tool when you need dummynet traffic shaping or prefer explicit numbered rule control. OPNsense and pfSense turn FreeBSD into a dedicated firewall appliance with a web UI, and between the two, OPNsense is the stronger open-source choice in 2026 while pfSense remains relevant for organizations that need Netgate's commercial backing.

Pick the tool that matches your deployment: PF for servers, IPFW for QoS, OPNsense for appliances. Then configure it properly, keep it updated, and it will do its job.